[FAB-18487] Update broken link in 2.2 branch

Signed-off-by: Nikhil Gupta <ngupta@symbridge.com>

docs/source/advice_for_writers.md

@@ -67,9 +67,9 @@ Each workgroup has a list of members and their contact information.
 
 Hyperledger Fabric has many other collaboration mechanisms such as mailing
 lists, contributor meetings and maintainer meetings. Find out about these and
-more [here](./contributing.html).
+more [here](./CONTRIBUTING.html).
 
 Good luck getting started and thanks for your contribution.
 
 <!--- Licensed under Creative Commons Attribution 4.0 International License
-https://creativecommons.org/licenses/by/4.0/ -->
+https://creativecommons.org/licenses/by/4.0/ -->

docs/source/config_update.md

@@ -9,7 +9,7 @@ Like many complex systems, Hyperledger Fabric networks are comprised of both **s
 * **Structure**: encompassing users (like admins), organizations, peers, ordering nodes, CAs, smart contracts, and applications.
 * **Process**: the way these structures interact. Most important of these are [Policies](./policies/policies.html), the rules that govern which users can do what, and under what conditions.
 
-Information identifying the structure of blockchain networks and the processes governing how structures interact are contained in **channel configurations**. These configurations are collectively decided upon by the members of channels and are contained in blocks that are committed to the ledger of a channel. Channel configurations can be built using a tool called `configtxgen`, which uses a `configtx.yaml` file as its input. You can look at a [sample `configtx.yaml` file here](http://github.com/hyperledger/fabric/blob/release-2.0/sampleconfig/configtx.yaml).
+Information identifying the structure of blockchain networks and the processes governing how structures interact are contained in **channel configurations**. These configurations are collectively decided upon by the members of channels and are contained in blocks that are committed to the ledger of a channel. Channel configurations can be built using a tool called `configtxgen`, which uses a `configtx.yaml` file as its input. You can look at a [sample `configtx.yaml` file here](http://github.com/hyperledger/fabric/blob/release-2.2/sampleconfig/configtx.yaml).
 
 Because configurations are contained in blocks (the first of these is known as the genesis block with the latest representing the current configuration of the channel), the process for updating a channel configuration (changing the structure by adding members, for example, or processes by modifying channel policies) is known as a **configuration update transaction**.
 
@@ -951,7 +951,7 @@ However, as you'll see, this conceptual simplicity is wrapped in a somewhat conv
 We have two tutorials that deal specifically with editing a channel configuration to achieve a specific end:
 
 * [Adding an Org to a Channel](./channel_update_tutorial.html): shows the process for adding an additional organization to an existing channel.
-* [Updating channel capabilities](./updating_a_channel.html): shows how to update channel capabilities.
+* [Updating channel capabilities](./updating_capabilities.html): shows how to update channel capabilities.
 
 In this topic, we'll show the process of editing a channel configuration independent of the end goal of the configuration update.
 

docs/source/create_channel/create_channel.md

@@ -63,7 +63,7 @@ You can find the `configtx.yaml` file that is used to deploy the test network in
 
   The `configtxgen` tool uses `configtx.yaml` file to create a complete genesis block for the system channel. As a result, the system channel profile needs to specify the full system channel configuration. The channel profile used to create the channel creation transaction only needs to contain the additional configuration information required to create an application channel.
 
-You can visit the [Using configtx.yaml to create a channel genesis block](create_channel_genesis.html) tutorial to learn more about this file. For now, we will return to the operational aspects of creating the channel, though we will reference parts of this file in future steps.
+You can visit the [Using configtx.yaml to build a channel configuration](create_channel_config.html) tutorial to learn more about this file. For now, we will return to the operational aspects of creating the channel, though we will reference parts of this file in future steps.
 
 ## Start the network
 

docs/source/developapps/gateway.md

@@ -39,7 +39,7 @@ A gateway can be used by an application in two different ways:
   these roles in the connection profile [topic](./connectionprofile.html).
 
   The SDK will use this static topology, in conjunction with gateway
-  [connection options](./connectionoptions), to manage the transaction
+  [connection options](./connectionoptions.html), to manage the transaction
   submission and notification processes. The connection profile must contain
   enough of the network topology to allow a gateway to interact with the
   network on behalf of the application; this includes the network channels,

docs/source/developapps/transactionhandler.md

@@ -85,7 +85,7 @@ shows you the exact form of these handlers.
 
 Once a handler has been added to the smart contract, it will be invoked during
 transaction processing. During processing, the handler receives `ctx`, the
-[transaction context](./transationcontext.md), performs some processing, and
+[transaction context](transationcontext.html), performs some processing, and
 returns control as it completes. Processing continues as follows:
 
 * **Before handler**: If the handler completes successfully, the transaction is

docs/source/kafka_raft_migration.md

@@ -185,7 +185,7 @@ channel, and elect a leader on each channel.
 **Note**: Since the Raft-based ordering service uses client and server TLS certificates for
 authentication between orderer nodes, **additional configurations** are required before
 you start them again, see
-[Section: Local Configuration](./raft_configuration.md#local-configuration) for more details.
+[Section: Local Configuration](raft_configuration.html#local-configuration) for more details.
 
 After restart process finished, make sure to **validate** that a
 leader has been elected on each channel by inspecting the node logs (you can see

docs/source/policies/policies.md

@@ -235,7 +235,7 @@ are satisfied, that ALL are satisfied, or that a MAJORITY are satisfied. This
 format lends itself to much better, more natural defaults, so that each
 organization can decide what it means for a valid endorsement.
 
-Further granularity and control can be achieved if you include [`NodeOUs`](msp.html#organizational-units) in your
+Further granularity and control can be achieved if you include [`NodeOUs`](../msp.html#organizational-units) in your
 organization definition. Organization Units (OUs) are defined in the Fabric CA
 client configuration file and can be associated with an identity when it is
 created. In Fabric, `NodeOUs` provide a way to classify identities in a digital

docs/source/secured_asset_transfer/secured_private_asset_transfer_tutorial.md

@@ -4,7 +4,7 @@ This tutorial will demonstrate how an asset can be represented and traded betwee
 Each on-chain asset is a non-fungible token (NFT) that represents a specific asset having certain immutable metadata properties (such as size and color) with a unique owner. When the owner wants to sell the asset, both parties need to agree to the same price before the asset is transferred. The private asset transfer smart contract enforces that only the owner of the asset can transfer the asset. In the course of this tutorial, you will learn how Fabric features such as state based endorsement, private data, and access control come together to provide secured transactions that are both private and verifiable.
 
 This tutorial will deploy the [secured asset transfer sample](https://github.com/hyperledger/fabric-samples/tree/master/asset-transfer-secured-agreement/chaincode-go) to demonstrate how to transfer a private asset between two organizations without publicly sharing data. You should have completed the task
-[Install Samples, Binaries, and Docker Images](./install.html#install-samples-binaries-and-docker-images).
+[Install Samples, Binaries, and Docker Images](../install.html#install-samples-binaries-and-docker-images).
 
 
 ## Scenario requirements

docs/source/tutorial/commercial_paper.md

@@ -404,7 +404,7 @@ and approve the chaincode as administrators of both MagnetoCorp and DigiBank.
 administrator installs a copy of the `papercontract` onto a MagnetoCorp peer.*
 
 Smart contracts are the focus of application development, and are contained
-within a Hyperledger Fabric artifact called [chaincode](../chaincode.html). One
+within a Hyperledger Fabric artifact called [chaincode](../chaincode4ade.html). One
 or more smart contracts can be defined within a single chaincode, and installing
 a chaincode will allow them to be consumed by the different organizations in
 PaperNet. It means that only administrators need to worry about chaincode;
@@ -854,7 +854,7 @@ All the time, the underlying Fabric SDK handles the transaction endorsement,
 ordering and notification process, making the application's logic
 straightforward; the SDK uses a [gateway](../developapps/gateway.html) to
 abstract away network details and
-[connectionOptions](../developapps/connectoptions.html) to declare more advanced
+[connectionOptions](../developapps/connectionoptions.html) to declare more advanced
 processing strategies such as transaction retry.
 
 Let's now follow the lifecycle of MagnetoCorp 00001 by switching our emphasis