This documents two things: * The recommended way to go about adding a new pass. * The criteria for enabling a pass. RFC: https://discourse.llvm.org/t/rfc-guidelines-for-adding-enabling-new-passes/88290
Related to: https://discourse.llvm.org/t/forbidding-username-in-commits/86997 **Context:** When we merge a commit including tag to another username (e.g. `@<someUser>`), that account will receive an email / notification every time that PR is cherry-picked and pushed to a fork, generating _a lot_ of spam in the user's inbox. As of today, there's no way of disabling this on GitHub settings. **This PR** documents this error in our developer policy, and reminds contributors to avoid it. **Next steps:** I'm a big believer that any policy that is not enforced via automation is not enforced at all, so I'd love to see some kind of check to prevent this error. However, there does not seem to be an agreement to do that _yet_. I'll see if I can gather support for doing that. --------- Co-authored-by: Jakub Kuderski <kubakuderski@gmail.com>
I split these edits out of PR #154441
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.