Refresh CONTRIBUTING.md to reflect GitHub Actions CI. (#11767)
* Adjusted language for "project members" / "collaborators" /
"maintainers"
* Mention that squash merge messages now default to the PR description
(we set that repository setting)
* Remove reference to "kokoro:run" label and link to GitHub docs for
approving workflow runs
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index a62bddf..afdd2b0 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -24,7 +24,7 @@
consistently across the project. Most of the code style is derived from the
[Google Style Guides](http://google.github.io/styleguide/) for the appropriate
language and is generally not something we accept changes on (as clang-format
-and clang-tidy handle that for us). The compiler portion of the project follows
+and other linters set that for us). The compiler portion of the project follows
[MLIR style](https://mlir.llvm.org/getting_started/DeveloperGuide/#style-guide).
Improvements to code structure and clarity are welcome but please file issues to
track such work first.
@@ -39,29 +39,31 @@
## Code reviews
-All submissions, including submissions by project members, require review. We
+All submissions, including submissions by maintainers, require review. We
use GitHub pull requests (PRs) for this purpose. Consult
[GitHub Help](https://help.github.com/articles/about-pull-requests/) for more
information on using pull requests.
## Presubmits
-Several of our presubmit builds will only run automatically if you are a project
-collaborator. Otherwise a collaborator must label the PR with "kokoro:run". If
-you are sending code changes to the project, please ask to be added as a
+Most of our presubmit workflows will only run automatically on PRs if you are a
+project collaborator. Otherwise a maintainer must
+[approve workflow runs](https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks).
+If you are sending code changes to the project, please ask to be added as a
collaborator, so that these can run automatically. It is generally expected that
-PRs will only be merged when all presubmit checks are passing. In some cases,
-pre-existing failures may be ignored.
+PRs will only be merged when all checks are passing. In some cases, pre-existing
+failures may be ignored by a maintainer or admin.
## Merging
After review and presubmit checks, PRs should be merged with a "squash and
merge". The squashed commit summary should match the PR title and the commit
-description should match the PR body. Accordingly, please write these as you
-would a helpful commit message. Please also keep PRs small (focused on a single
-issue) to streamline review and ease later culprit-finding. It is assumed that
-the PR author will merge their change unless they ask someone else to merge it
-for them (e.g. because they don't have write access).
+description should match the PR body (this is the default behavior).
+Accordingly, please write these as you would a helpful commit message. Please
+also keep PRs small (focused on a single issue) to streamline review and ease
+later culprit-finding. It is assumed that the PR author will merge their change
+unless they ask someone else to merge it for them (e.g. because they don't have
+write access).
## Peculiarities
