Update contribution docs

--
MOS_MIGRATED_REVID=96016544

2 files changed, 14 insertions, 15 deletions

diff --git a/site/contributing.md b/site/contributing.md
index 5adf8321d8..39c9c3ac92 100644
--- a/site/contributing.md
+++ b/site/contributing.md
@@ -4,20 +4,21 @@ layout: community
 
 # Contributing to Bazel
 
-If you wish to contribute, prefer using Gerrit over GitHub pull request. We
-might redirect you to Gerrit if you send us a non-trivial change in a GitHub
-Pull Request.
+We welcome contributions! This page covers setting up your machine to develop
+Bazel and, when you've made a patch, how to submit it.
 
 ## How can I contribute to Bazel?
 
-You should first read the [Bazel governance plan](governance.html). Then you can
-read this page that explains how to submit a patch to Bazel, as well as how to set-up
-and work on the Bazel code.
+In general, we prefer contributions that fix bugs or add features (as opposed to
+stylistic, refactoring, or "cleanup" changes). Please check with us on the
+[dev list](https://groups.google.com/forum/#!forum/bazel-dev) before investing
+a lot of time in a patch.
 
 ## Patch Acceptance Process
 
 <!-- Our markdown parser doesn't support nested lists. -->
 <ol>
+<li>Read the [Bazel governance plan](governance.html).</li>
 <li>Discuss your plan and design, and get agreement on our <a href="https://groups.google.com/forum/#!forum/bazel-dev">mailing list</a>.
 <li>Prepare a git commit that implements the feature. Don't forget to add tests.
 <li>Create a new code review on <a href="https://bazel-review.googlesource.com">Gerrit</a>
diff --git a/site/governance.md b/site/governance.md
index 133664e671..548952ad7a 100644
--- a/site/governance.md
+++ b/site/governance.md
@@ -29,29 +29,27 @@ list), but this will hopefully change over time.
    [Skylark](docs/skylark/concepts.html), in a `contrib/` directory or similar with clearly documented
    support policies.
 
-3. We accept well-written, well-tested cleanup and refactoring changes.
+3. We accept well-written, well-tested bug fixes to built-in rules.
 
-4. We accept well-written, well-tested bug fixes to built-in rules.
-
-5. We accept well-written, well-tested feature contributions if a core contributor assumes support
+4. We accept well-written, well-tested feature contributions if a core contributor assumes support
    responsibilities, i.e., readily answers support questions and works on bugs. This includes
    feature contributions from external contributors. If there is no core contributor to support a
    feature, then we will deprecate and subsequently delete the feature - we will give three months'
    notice in such cases.
 
-6. We will not accept untested changes, except in very rare cases.
+5. We will not accept untested changes, except in very rare cases.
 
-7. We require a pre-commit code review from a core contributor for all changes. For the time being,
+6. We require a pre-commit code review from a core contributor for all changes. For the time being,
    we will have to continue making changes across the internal and external code bases, which will
    be reviewed internal to Google.
 
-8. We will roll back changes if they break the internal development processes of any of the core
+7. We will roll back changes if they break the internal development processes of any of the core
    contributors.
 
-9. We will move towards an open governance model where multiple parties have commit access,
+8. We will move towards an open governance model where multiple parties have commit access,
    roll-back rights, and can provide explicit support for features or rules.
 
-10. We will work with interested parties to improve existing extension points and to establish new
+9. We will work with interested parties to improve existing extension points and to establish new
     extension points if they do not run counter to the internal requirements of any of the core
     contributors.