Clarify lots of existing practice. Expand on the "major change" section, which is the closest thing we have on how to run an RFC. --------- Co-authored-by: Oleksandr "Alex" Zinenko <azinenko@amd.com> Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
This is the implicit process but useful to spell it out I think. To give folks more confidence in asking. Inspired by https://discourse.llvm.org/t/request-github-issue-triage-permission-for-labeling-clang-issues/87126/1
Co-authored-by: Matt Arsenault <arsenm2@gmail.com>
This documents what the Code of Conduct committee has decided to do when an attempt to evade a ban is detected.
There should be no substantial policy change here. I reordered the breaking change docs after the major change docs, since that flow made sense to me. I smoothed out some of the incremental development policy wording to be a bit less black and white, and talk about "preferred" and "discouraged" approaches.
See current live website: https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access  Building locally, it appears correctly:  Feel free to merge immediately.
See https://discourse.llvm.org/t/rfc-commit-access-criteria/84073
This makes it more clear what you the author must do, and what reviewers can expect you to do, before an approved PR can be merged. Spliting out the email bit into a section also means we can link directly to it in discussions. This relies on one of those parties actually reading this, but I plan to tackle the case where they don't with some new automation.
This updates the developer policy to align with established community norms for copyright notices in source code contributed to LLVM. The updates clearly state that we do not accept code contianing explicit copyright notices in source except where such code is a pre-existing part of an external dependency that is being vendored into LLVM. Explicit copyright notices in source add no value to the project since copyright ownership is well tracked through git. Our policy already requires that contributions made not by the original author have appropriate attribution in git commit messsages or metadata. Further, explicit copyright notices in code can easily get out of date as the code is refactored, updated by additional authors or otherwise changed over time. This leads to misleading out-of-date copyright notices which do more harm than good. This change should be viewed as a clarification and statement of existing established policy, not a change in policy since it represents the way the project has been operating.
Fixes some typos in the documentation