[FAB-17115] Update doc for GitHub migration

This change removes Gerrit doc and replaces
gerrit-related verbiage with GitHub terminology

Signed-off-by: Brett Logan <Brett.T.Logan@ibm.com>
Change-Id: Icfb87c5583067fd0ecc7da96bf73f50dde33c494

docs/source/CONTRIBUTING.rst

@@ -1,21 +1,12 @@
-.. note::
+.. note:: Users who are migrating from Gerrit to GitHub: You can follow simple
+          Git workflows to move your development from Gerrit to GitHub. After
+          forking the Fabric repo, simply push the branches you want to save from
+          your current Gerrit-based local repo to your remote forked repository.
+          Once you've pushed the changes you want to save, simply delete your
+          local Gerrit-based repository and clone your fork.
 
-   The following repositories now use GitHub for source control.
-   Please see the :doc:`GitHub Contributions <github/github>` page for
-   contribution guidelines for these repositories:
-
-   - `Fabric-CA <https://github.com/hyperledger/fabric-ca>`_
-   - `Fabric-Chaincode-EVM <https://github.com/hyperledger/fabric-chaincode-evm>`_
-   - `Fabric-Chaincode-Go <https://github.com/hyperledger/fabric-chaincode-go>`_
-   - `Fabric-Chaincode-Java <https://github.com/hyperledger/fabric-chaincode-java>`_
-   - `Fabric-Chaincode-Node <https://github.com/hyperledger/fabric-chaincode-node>`_
-   - `Fabric-Gateway-Java <https://github.com/hyperledger/fabric-gateway-java>`_
-   - `Fabric-Protos <https://github.com/hyperledger/fabric-protos>`_
-   - `Fabric-Samples <https://github.com/hyperledger/fabric-samples>`_
-   - `Fabric-SDK-Go <https://github.com/hyperledger/fabric-sdk-go>`_
-   - `Fabric-SDK-Java <https://github.com/hyperledger/fabric-sdk-java>`_
-
-=====================
+          For a basic Git workflow recommendation please see our doc at
+          :doc:`github/github`.
 
 Contributions Welcome!
 ======================
@@ -60,7 +51,6 @@ In order to participate in the development of the Hyperledger Fabric
 project, you will need a Linux Foundation
 account. Once you have a LF ID you will be able to
 access all the Hyperledger community tools, including
-`Gerrit code review <https://gerrit.hyperledger.org>`__,
 `Jira issue management <https://jira.hyperledger.org>`__,
 `RocketChat <https://chat.hyperledger.org/>`__, and the
 `Wiki <https://wiki.hyperledger.org/display/fabric/Hyperledger+Fabric>`__ (for editing, only).
@@ -82,8 +72,7 @@ already have one.
 5. Verify that your browser displays the message
    ``You have successfully validated your e-mail address``.
 
-6. Access `Gerrit code review <https://gerrit.hyperledger.org>`__,
-   `Jira issue management <https://jira.hyperledger.org>`__, or
+6. Access `Jira issue management <https://jira.hyperledger.org>`__, or
    `RocketChat <https://chat.hyperledger.org/>`__.
 
 Project Governance
@@ -153,7 +142,7 @@ design discussion.
 
 Getting the support of three or more of the Hyperledger Fabric maintainers for
 the new feature will greatly enhance the probability that the feature's related
-CRs will be included in a subsequent release.
+PRs will be included in a subsequent release.
 
 Maintainers meeting
 ~~~~~~~~~~~~~~~~~~~
@@ -224,7 +213,7 @@ the defect fixed.
 .. note:: If the defect is security-related, please follow the Hyperledger
           `security bug reporting process <https://wiki.hyperledger.org/display/HYP/Defect+Response>`__.
 
-If it has not been previously reported, you may either submit a CR with a
+If it has not been previously reported, you may either submit a PR with a
 well documented commit message describing the defect and the fix, or you 
 may create a new JIRA. Please try to provide
 sufficient information for someone else to reproduce the
@@ -240,10 +229,7 @@ Submitting your fix
 
 If you just submitted a JIRA for a bug you've discovered, and would like to
 provide a fix, we would welcome that gladly! Please assign the JIRA issue to
-yourself, then you can submit a change request (CR).
-
-.. note:: If you need help with submitting your first CR, we have created a
-          brief :doc:`tutorial <submit_cr>` for you.
+yourself, then you can submit a pull request (PR).
 
 Fixing issues and working stories
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -259,47 +245,47 @@ assignment if you cannot finish in a reasonable time, or add a comment
 saying that you are still actively working the issue if you need a
 little more time.
 
-Reviewing submitted Change Requests (CRs)
+Reviewing submitted Pull Requests (PRs)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Another way to contribute and learn about Hyperledger Fabric is to help the
-maintainers with the review of the CRs that are open. Indeed
-maintainers have the difficult role of having to review all the CRs
+maintainers with the review of the PRs that are open. Indeed
+maintainers have the difficult role of having to review all the PRs
 that are being submitted and evaluate whether they should be merged or
 not. You can review the code and/or documentation changes, test the
 changes, and tell the submitters and maintainers what you think. Once
-your review and/or test is complete just reply to the CR with your
+your review and/or test is complete just reply to the PR with your
 findings, by adding comments and/or voting. A comment saying something
 like "I tried it on system X and it works" or possibly "I got an error
 on system X: xxx " will help the maintainers in their evaluation. As a
-result, maintainers will be able to process CRs faster and everybody
+result, maintainers will be able to process PRs faster and everybody
 will gain from it.
 
-Just browse through `the open CRs on Gerrit
-<https://gerrit.hyperledger.org/r/#/q/status:open>`__ to get started.
+Just browse through `the open PRs on GitHub
+<https://github.com/hyperledger/fabric/pulls>`__ to get started.
 
-CR Aging
+PR Aging
 ~~~~~~~~
 
-As the Fabric project has grown, so too has the backlog of open CRs. One
+As the Fabric project has grown, so too has the backlog of open PRs. One
 problem that nearly all projects face is effectively managing that backlog
 and Fabric is no exception. In an effort to keep the backlog of Fabric and
-related project CRs manageable, we are introducing an aging policy which
+related project PRs manageable, we are introducing an aging policy which
 will be enforced by bots.  This is consistent with how other large projects
-manage their CR backlog.
+manage their PR backlog.
 
-CR Aging Policy
+PR Aging Policy
 ~~~~~~~~~~~~~~~
 
-The Fabric project maintainers will automatically monitor all CR activity for
-delinquency. If a CR has not been updated in 2 weeks, a reminder comment will be
-added requesting that the CR either be updated to address any outstanding
-comments or abandoned if it is to be withdrawn. If a delinquent CR goes another
-2 weeks without an update, it will be automatically abandoned. If a CR has aged
+The Fabric project maintainers will automatically monitor all PR activity for
+delinquency. If a PR has not been updated in 2 weeks, a reminder comment will be
+added requesting that the PR either be updated to address any outstanding
+comments or abandoned if it is to be withdrawn. If a delinquent PR goes another
+2 weeks without an update, it will be automatically abandoned. If a PR has aged
 more than 2 months since it was originally submitted, even if it has activity,
 it will be flagged for maintainer review.
 
-If a submitted CR has passed all validation but has not been reviewed in 72
+If a submitted PR has passed all validation but has not been reviewed in 72
 hours (3 days), it will be flagged to the #fabric-pr-review channel daily until
 it receives a review comment(s).
 
@@ -314,7 +300,7 @@ Setting up development environment
 Next, try :doc:`building the project <dev-setup/build>` in your local
 development environment to ensure that everything is set up correctly.
 
-What makes a good change request?
+What makes a good pull request?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 -  One change at a time. Not five, not three, not ten. One and only one.
@@ -350,7 +336,7 @@ What makes a good change request?
    of unit testing for a good set of criteria to keep in mind for writing
    effective unit tests.
 
--  Minimize the lines of code per CR. Why? Maintainers have day jobs,
+-  Minimize the lines of code per PR. Why? Maintainers have day jobs,
    too. If you send a 1,000 or 2,000 LOC change, how long do you think
    it takes to review all of that code? Keep your changes to < 200-300
    LOC, if possible. If you have a larger change, decompose it into
@@ -363,26 +349,17 @@ What makes a good change request?
    bunch of generated code (protobufs, etc.). Again, there can be
    exceptions.
 
-.. note:: Large change requests, e.g. those with more than 300 LOC are more likely
-          than not going to receive a -2, and you'll be asked to refactor the
-          change to conform with this guidance.
-
--  Do not stack change requests (e.g. submit a CR from the same local branch
-   as your previous CR) unless they are related. This will minimize merge
-   conflicts and allow changes to be merged more quickly. If you stack requests
-   your subsequent requests may be held up because of review comments in the
-   preceding requests.
+.. note:: Large pull requests, e.g. those with more than 300 LOC are more than likely
+          not going to receive an approval, and you'll be asked to refactor
+          the change to conform with this guidance.
 
 -  Write a meaningful commit message. Include a meaningful 55 (or less)
    character title, followed by a blank line, followed by a more
    comprehensive description of the change. Each change MUST include the JIRA
    identifier corresponding to the change (e.g. [FAB-1234]). This can be
-   in the title but should also be in the body of the commit message. See the
-   :doc:`complete requirements <Gerrit/changes>` for an acceptable change
-   request.
+   in the title but should also be in the body of the commit message.
 
-.. note:: That Gerrit will automatically create a hyperlink to the JIRA item.
-          e.g.
+.. note:: Example commit message:
 
           ::
 
@@ -391,7 +368,7 @@ What makes a good change request?
               Fix [FAB-1234] added a check to ensure that when foobar(foo string)
               is called, that there is a non-empty string argument.
 
-Finally, be responsive. Don't let a change request fester with review
+Finally, be responsive. Don't let a pull request fester with review
 comments such that it gets to a point that it requires a rebase. It only
 further delays getting it merged and adds more work for you - to
 remediate the merge conflicts.
@@ -433,10 +410,6 @@ Related Topics
    jira_navigation
    dev-setup/devenv
    dev-setup/build
-   Gerrit/gerrit
-   Gerrit/changes
-   Gerrit/reviewing
-   Gerrit/best-practices
    testing
    style-guides/go-style