[FAB-3201] Fix many of the broken links in the doc

This change fixes most broken links.

Commit #1 and #2
Fixes several broken links.

Commit #3
Remove note linking to document that no longer exists in reponse to Tracy's
comment.

Commit #4
Do the above for good.

Commit #5 and #6
Fixes many of the remaining broken links, based on the w3c and xenu link
checkers.

Before this change, with Xenu we have:
25 broken link(s) reported
3 bad local link(s) reported

After this change, we have:
4 broken link(s) reported
0 bad local link(s) reported

Commit #7
Fixes Tracy's comments on latest commit.

[ci-skip]

Change-Id: I57d942c19f0904548fc6298408c459940c5d33a8
Signed-off-by: Arnaud J Le Hors <lehors@us.ibm.com>

Author: lehors

docs/source/CONTRIBUTING.rst

@@ -12,8 +12,8 @@ Getting a Linux Foundation account
 ----------------------------------
 
 In order to participate in the development of the Hyperledger Fabric
-project, you will need a `Linux Foundation
-account <Gerrit/lf-account.rst>`__. You will need to use your LF ID to
+project, you will need a :doc:`Linux Foundation
+account <Gerrit/lf-account>`. You will need to use your LF ID to
 access to all the Hyperledger community development tools, including
 `Gerrit <https://gerrit.hyperledger.org>`__,
 `Jira <https://jira.hyperledger.org>`__ and the
@@ -25,7 +25,7 @@ Setting up your SSH key
 For Gerrit, before you can submit any change set for review, you will
 need to register your public SSH key. Login to
 `Gerrit <https://gerrit.hyperledger.org>`__ with your
-`LFID <Gerrit/lf-account.rst>`__, and click on your name in the upper
+:doc:`LFID <Gerrit/lf-account>`, and click on your name in the upper
 right-hand corner of your browser window and then click 'Settings'. In
 the left-hand margin, you should see a link for 'SSH Public Keys'.
 Copy-n-paste your `public SSH
@@ -87,21 +87,21 @@ Working with a local clone and Gerrit
 We are using
 `Gerrit <https://gerrit.hyperledger.org/r/#/admin/projects/fabric>`__ to
 manage code contributions. If you are unfamiliar, please review this
-`document <Gerrit/gerrit.rst>`__ before proceeding.
+:doc:`document <Gerrit/gerrit>` before proceeding.
 
 After you have familiarized yourself with ``Gerrit``, and maybe played
 around with the ``lf-sandbox``
 `project <https://gerrit.hyperledger.org/r/#/admin/projects/lf-sandbox,branches>`__,
 you should be ready to set up your local development
-`environment <dev-setup/devenv.rst>`__.
+:doc:`environment <dev-setup/devenv>`.
 
-Next, try `building the project <dev-setup/build.rst>`__ in your local
+Next, try :doc:`building the project <dev-setup/build>` in your local
 development environment to ensure that everything is set up correctly.
 
-`Logging control <Setup/logging-control.rst>`__ describes how to tweak
+:doc:`Logging control <Setup/logging-control>` describes how to tweak
 the logging levels of various components within the Fabric. Finally,
-every source file needs to include a `license
-header <dev-setup/headers.txt>`__: modified to include a copyright
+every source file needs to include a `license header
+<https://github.com/hyperledger/fabric/blob/master/docs/source/dev-setup/headers.txt>`__: modified to include a copyright
 statement for the principle author(s).
 
 What makes a good change request?
@@ -185,8 +185,8 @@ remediate the merge conflicts.
 Coding guidelines
 -----------------
 
-Be sure to check out the language-specific `style
-guides <Style-guides/go-style.rst>`__ before making any changes. This
+Be sure to check out the language-specific :doc:`style
+guides <Style-guides/go-style>` before making any changes. This
 will ensure a smoother review.
 
 Communication
@@ -202,7 +202,7 @@ list <http://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric>`__.
 Maintainers
 -----------
 
-The project's `maintainers <MAINTAINERS.rst>`__ are responsible for
+The project's :doc:`maintainers <MAINTAINERS>` are responsible for
 reviewing and merging all patches submitted for review and they guide
 the over-all technical direction of the project within the guidelines
 established by the Hyperledger Project's Technical Steering Committee
@@ -218,7 +218,7 @@ designate an initial set of maintainers that will be approved by the
 top-level project's existing maintainers when the project is first
 approved. The project's maintainers will, from time-to-time, consider
 adding or removing a maintainer. An existing maintainer can submit a
-change set to the `MAINTAINERS.rst <MAINTAINERS.rst>`__ file. If there are
+change set to the :doc:`MAINTAINERS.rst <MAINTAINERS>` file. If there are
 less than eight maintainers, a majority of the existing maintainers on
 that project are required to merge the change set. If there are more
 than eight existing maintainers, then if five or more of the maintainers
@@ -232,13 +232,13 @@ Legal stuff
 -----------
 
 **Note:** Each source file must include a license header for the Apache
-Software License 2.0. A template of that header can be found
-`here <https://github.com/hyperledger/fabric/blob/master/docs/dev-setup/headers.txt>`__.
+Software License 2.0. See the template of the `license header
+<https://github.com/hyperledger/fabric/blob/master/docs/source/dev-setup/headers.txt>`__.
 
 We have tried to make it as easy as possible to make contributions. This
 applies to how we handle the legal aspects of contribution. We use the
 same approach—the `Developer's Certificate of Origin 1.1
-(DCO) <docs/biz/DCO1.1.txt>`__—that the Linux® Kernel
+(DCO) <https://github.com/hyperledger/fabric/blob/master/docs/source/biz/DCO1.1.txt>`__—that the Linux® Kernel
 `community <http://elinux.org/Developer_Certificate_Of_Origin>`__ uses
 to manage code contributions.
 

docs/source/Gerrit/best-practices.rst

@@ -41,7 +41,7 @@ text at 72 chars/line.
 
 | Jira: FAB-100
 | Change-Id: LONGHEXHASH
-| Signed-off-by: Your Name your.email@example.org
+| Signed-off-by: Your Name your.email\@example.org
 | AnotherExampleHeader: An Example of another Value
 
 The Gerrit server provides a precommit hook to autogenerate the
@@ -148,7 +148,7 @@ Finding Available Topics
        $ ssh -p 29418 gerrit.hyperledger.org gerrit query \ status:open project:fabric branch:master \
        | grep topic: | sort -u
 
--  `gerrit.hyperledger.org <>`__ Is the current URL where the project is
+-  `gerrit.hyperledger.org <https://gerrit.hyperledger.org>`__ Is the current URL where the project is
    hosted.
 -  *status* Indicates the topic's current status: open , merged,
    abandoned, draft, merge conflict.

docs/source/Gerrit/changes.rst

@@ -10,7 +10,7 @@ Change Requirements
 
 This section contains guidelines for submitting code changes for review.
 For more information on how to submit a change using Gerrit, please see
-`Gerrit <gerrit.md>`__.
+:doc:`Gerrit <gerrit>`.
 
 Changes are submitted as Git commits. Each commit must contain:
 
@@ -31,7 +31,7 @@ Informationally, ``commit messages`` must include:
 -  **why** you chose that approach, and
 -  **how** you know it works -- for example, which tests you ran.
 
-Commits must `build cleanly <../dev-setup/build.md>`__ when applied in
+Commits must :doc:`build cleanly <../dev-setup/build>` when applied in
 top of each other, thus avoiding breaking bisectability. Each commit
 must address a single identifiable issue and must be logically
 self-contained.

docs/source/Gerrit/gerrit.rst

@@ -19,8 +19,8 @@ Gerrit assigns the following roles to users:
 -  **Builders**: (e.g. Jenkins) May use the build automation
    infrastructure to verify the change.
 
-Maintainers should be familiar with the `review
-process <reviewing.md>`__. However, anyone is welcome to (and
+Maintainers should be familiar with the :doc:`review
+process <reviewing>`. However, anyone is welcome to (and
 encouraged!) review changes, and hence may find that document of value.
 
 Git-review
@@ -48,7 +48,7 @@ A comprehensive walk-through of Gerrit is beyond the scope of this
 document. There are plenty of resources available on the Internet. A
 good summary can be found
 `here <https://www.mediawiki.org/wiki/Gerrit/Tutorial>`__. We have also
-provided a set of `Best Practices <best-practices.md>`__ that you may
+provided a set of :doc:`Best Practices <best-practices>` that you may
 find helpful.
 
 Working with a local clone of the repository
@@ -72,7 +72,7 @@ To work on something, whether a new feature or a bugfix:
 **Note:** if you are cloning the fabric project repository, you will
 want to clone it to the ``$GOPATH/src/github.com/hyperledger`` directory
 so that it will build, and so that you can use it with the Vagrant
-`development environment <../dev-setup/devenv.md>`__.
+:doc:`development environment <../dev-setup/devenv>`.
 
 4. Create a descriptively-named branch off of your cloned repository
 
@@ -82,7 +82,7 @@ so that it will build, and so that you can use it with the Vagrant
     git checkout -b issue-nnnn
 
 5. Commit your code. For an in-depth discussion of creating an effective
-   commit, please read `this document <changes.md>`__.
+   commit, please read :doc:`this document on submitting changes <changes>`.
 
 ::
 
@@ -99,8 +99,9 @@ Submitting a Change
 -------------------
 
 Currently, Gerrit is the only method to submit a change for review.
-**Please review the `guidelines <changes.md>`__ for making and
-submitting a change**.
+
+**Note:** Please review the :doc:`guidelines <changes>` for making and
+submitting a change.
 
 Use git review
 ~~~~~~~~~~~~~~
@@ -130,8 +131,7 @@ and then repeat the ``git review`` command.
 Not Use git review
 ~~~~~~~~~~~~~~~~~~
 
-Directions for building the source code can be found
-`here <../dev-setup/build.md>`__.
+See the :doc:`directions for building the source code <../dev-setup/build>`.
 
 When a change is ready for submission, Gerrit requires that the change
 be pushed to a special branch. The name of this special branch contains

docs/source/Setup/Chaincode-setup.rst

@@ -15,22 +15,18 @@ chaincode as a Docker container.
 
 The following instructions apply to *developing* chaincode in Go or
 Java. They do not apply to running in a production environment. However,
-if *developing* chaincode in Java, please see the `Java chaincode
-setup <https://github.com/hyperledger/fabric/blob/master/docs/Setup/JAVAChaincode.md>`__
+if *developing* chaincode in Java, please see the :doc:`Java chaincode
+setup <JAVAChaincode>`
 instructions first, to be sure your environment is properly configured.
 
-**Note:** We have added support for `System
-chaincode <https://github.com/hyperledger/fabric/blob/master/docs/SystemChaincode-noop.md>`__.
-
 Choices
 -------
 
 Once again, you have the choice of using one of the following
 approaches:
 
 -  `Option 1 <#option-1-vagrant-development-environment>`__ using the
-   **Vagrant** `development
-   environment <https://github.com/hyperledger/fabric/blob/master/docs/dev-setup/devenv.md>`__
+   **Vagrant** :doc:`development environment <../dev-setup/devenv>`
    that is used for developing the fabric itself
 -  `Option 2 <#option-2-docker-for-mac-or-windows>`__ using Docker for
    Mac or Windows
@@ -328,8 +324,7 @@ when security is
 enabled <#removing-temporary-files-when-security-is-enabled>`__ to learn
 how to clean up the temporary files.
 
-See the `logging
-control <https://github.com/hyperledger/fabric/blob/master/docs/Setup/logging-control.md>`__
+See the :doc:`logging control <logging-control>`
 reference for information on controlling logging output from the
 ``peer`` and chaincodes.
 

docs/source/Setup/JAVAChaincode.rst

@@ -1,9 +1,8 @@
 Java chaincode
 --------------
 
-Note: This guide generally assumes you have followed the Chaincode
-development environment setup tutorial
-`here <https://github.com/hyperledger/fabric/blob/master/docs/Setup/Chaincode-setup.md>`__.
+Note: This guide generally assumes you have followed the :doc:`Chaincode
+development environment setup tutorial <Chaincode-setup>`.
 
 To get started developing Java chaincode
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

docs/source/Setup/ca-setup.rst

@@ -50,7 +50,7 @@ Table of Contents
 
 6. `Fabric CA Client`_
 
-   1. `Enrolling the bootstrap user`_
+   1. `Enrolling the bootstrap identity`_
    2. `Registering a new identity`_
    3. `Enrolling a peer identity`_
    4. `Reenrolling an identity`_

docs/source/architecture.rst

@@ -4,16 +4,16 @@ delivering accountability, transparency, and efficiencies unmatched by
 other blockchain or DLT technology.
 
 Hyperledger Fabric implements a specific type of
-`permissioned <glossary.md#permissioned-network>`__ `blockchain
-network <glossary.md#blockchain-network>`__ on which members can track,
+:doc:`permissioned <glossary#permissioned-network>` :doc:`blockchain
+network <glossary#blockchain-network>` on which members can track,
 exchange and interact with digitized assets using
-`transactions <glossary.md#transactions>`__ that are governed by smart
-contracts - what we call `chaincode <glossary.md#chaincode>`__ - in a
+:doc:`transactions <glossary#transactions>` that are governed by smart
+contracts - what we call :doc:`chaincode <glossary#chaincode>` - in a
 secure and robust manner while enabling
-`participants <glossary.md#participants>`__ in the network to interact
+:doc:`participants <glossary#participants>` in the network to interact
 in a manner that ensures that their transactions and data can be
 restricted to an identified subset of network participants - something
-we call a `channel <glossary.md#channel>`__.
+we call a :doc:`channel <glossary#channel>`.
 
 The blockchain network supports the ability for members to establish
 shared ledgers that contain the source of truth about those digitized
@@ -28,31 +28,31 @@ Hyperledger Fabric also offers a certificate authority service,
 *fabric-ca* but, you may substitute that with your own.
 
 All peer nodes maintain the ledger/state by committing transactions. In
-that role, the peer is called a `committer <glossary.md#committer>`__.
+that role, the peer is called a :doc:`committer <glossary#commitment>`.
 Some peers are also responsible for simulating transactions by executing
 chaincodes (smart contracts) and endorsing the result. In that role the
-peer is called an `endorser <glossary.md#endorser>`__. A peer may be an
+peer is called an :doc:`endorser <glossary#endorsement>`. A peer may be an
 endorser for certain types of transactions and just a ledger maintainer
 (committer) for others.
 
-The `orderers <glossary.md#orderer>`__ consent on the order of
+The :doc:`orderers <glossary#ordering-service>` consent on the order of
 transactions in a block to be committed to the ledger. In common
 blockchain architectures (including earlier versions of the Hyperledger
 Fabric) the roles played by the peer and orderer nodes were unified (cf.
 validating peer in Hyperledger Fabric v0.6). The orderers also play a
 fundamental role in the creation and management of channels.
 
-Two or more `participants <glossary.md#participant>`__ may create and
+Two or more :doc:`participants <glossary#participant>` may create and
 join a channel, and begin to interact. Among other things, the policies
 governing the channel membership and chaincode lifecycle are specified
 at the time of channel creation. Initially, the members in a channel
 agree on the terms of the chaincode that will govern the transactions.
-When consensus is reached on the `proposal <glossary.md#proposal>`__ to
+When consensus is reached on the :doc:`proposal <glossary#proposal>` to
 deploy a given chaincode (as governed by the life cycle policy for the
 channel), it is committed to the ledger.
 
-Once the chaincode is deployed to the peer nodes in the channel, `end
-users <glossary.md#end-users>`__ with the right privileges can propose
+Once the chaincode is deployed to the peer nodes in the channel, :doc:`end
+users <glossary#end-users>` with the right privileges can propose
 transactions on the channel by using one of the language-specific client
 SDKs to invoke functions on the deployed chaincode.
 
@@ -100,5 +100,5 @@ Some key capabilities of Hyperledger Fabric include:
    required levels of trust and verification across nodes for
    optimization.
 
-For a deeper dive into the details, please visit `this
-document <arch-deep-dive.md>`__.
+For a deeper dive into the details, please visit :doc:`this
+document <arch-deep-dive>`.

docs/source/configtx.rst

@@ -71,9 +71,9 @@ policies. It is defined as follows:
         string mod_policy = 5;
     }
 
-Because ``ConfigGroup`` is a recursive structure, consider an example
-hierarchical arrangement of ``ConfigGroup``s (expressed for clarity in
-golang notation).
+Because ``ConfigGroup`` is a recursive structure, it has hierarchical
+arrangement. The following example is expressed for clarity in golang
+notation.
 
 ::
 

docs/source/license.rst

@@ -2,4 +2,5 @@ License
 ========
 
 The Hyperledger Project uses the `Apache License Version
-2.0 <LICENSE>`__ software license.
+2.0 <https://github.com/hyperledger/fabric/blob/master/LICENSE>`__ software
+license.