Updated Docusarus files, without the deployment

docs/.gitignore

@@ -0,0 +1,20 @@
+# Dependencies
+/node_modules
+
+# Production
+/build
+
+# Generated files
+.docusaurus
+.cache-loader
+
+# Misc
+.DS_Store
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*

docs/DOCS_README.md

@@ -9,10 +9,9 @@ If you want to open a PR on Gaia to update the documentation, please follow the
 
 ## Internationalization
 
-- Translations for documentation live in a `docs/<locale>/` folder, where `<locale>` is the language code for a specific language. For example, `zh` for Chinese, `ko` for Korean, `es` for Spanish, etc.
-- Each `docs/<locale>/` folder must follow the same folder structure within `docs/`, but only content in the following folders needs to be translated and included in the respective `docs/<locale>/` folder
-- Each `docs/<locale>/` folder must also have a `README.md` that includes a translated version of both the layout and content within the root-level [`README.md`](https://github.com/cosmos/cosmos-sdk/tree/master/docs/README.md). The layout defined in the `README.md` is used to build the homepage.
-- For additional configuration options, please see [VuePress Internationalization](https://vuepress.vuejs.org/guide/i18n.html).
+- Translations for documentation live in a `docs/translations/<locale>/` folder, where `<locale>` is the language code for a specific language. For example, `zh` for Chinese, `ko` for Korean, `es` for Spanish, etc.
+- Each `docs/translations/<locale>/` folder must follow the same folder structure within `docs/`, but only content in the following folders needs to be translated and included in the respective `docs/translations/<locale>/` folder
+- Each `docs/translations/<locale>/` folder must also have a `README.md` that includes a translated version of both the layout and content within the root-level [`README.md`](https://github.com/cosmos/cosmos-sdk/tree/master/docs/README.md). The layout defined in the `README.md` is used to build the homepage.
 
 ## Docs Build Workflow
 
@@ -86,19 +85,14 @@ Serve the app
 npm run serve
 ```
 
-then navigate to `localhost:8080` in your browser.
+then navigate to `localhost:3000` in your browser.
 
-To build documentation as a static website run `npm run build`. You will find the website in `.vuepress/dist` directory.
+To build documentation as a static website run `npm run build`. You will find the website in `build` directory.
 
 ## Search
 
 We are using [Algolia](https://www.algolia.com) to power full-text search. This uses a public API search-only key in the `config.js` as well as a [cosmos_network.json](https://github.com/algolia/docsearch-configs/blob/master/configs/cosmos_network.json) configuration file that we can update with PRs.
 
-## Consistency
-
-Because the build processes are identical (as is the information contained herein), this file should be kept in sync as
-much as possible with its [counterpart in the Tendermint Core repo](https://github.com/tendermint/tendermint/blob/master/docs/DOCS_README.md).
-
 ### Update and Build the RPC docs
 
 1. Execute the following command at the root directory to install the swagger-ui generate tool.

docs/README copy.md

@@ -0,0 +1,40 @@
+<!--
+parent:
+  order: false
+layout: home
+-->
+
+# Cosmos Hub Documentation
+
+Welcome to the documentation of the **Cosmos Hub application: `gaia`**.
+
+## What is Gaia?
+
+- [Intro to the `gaia` software](./getting-started/what-is-gaia.md)
+- [Interacting with the `gaiad` binary](./hub-tutorials/gaiad.md)
+
+## Join the Cosmos Hub Mainnet
+
+- [Install the `gaia` application](./getting-started/installation.md)
+- [Set up a full node and join the mainnet](./hub-tutorials/join-mainnet.md)
+- [Upgrade to a validator node](./validators/validator-setup.md)
+
+## Join the Cosmos Hub Public Testnet
+
+- [Join the testnet](./hub-tutorials/join-testnet.md)
+
+## Setup Your Own `gaia` Testnet
+
+- [Setup your own `gaia` testnet](https://github.com/cosmos/testnets/tree/master/local/previous-local-testnets/v7-theta)
+
+## Additional Resources
+
+- [Validator Resources](./validators/README.md): Contains documentation for `gaia` validators.
+- [Delegator Resources](./delegators/README.md): Contains documentation for delegators.
+- [Other Resources](./resources/README.md): Contains documentation on `gaiad`, genesis file, service providers, ledger wallets, ...
+- [Cosmos Hub Archives](./resources/archives.md): State archives of past iteration of the Cosmos Hub.
+
+# Contribute
+
+See [this file](./DOCS_README.md) for details of the build process and
+considerations when making changes.

docs/README.md

@@ -1,40 +1,41 @@
-<!--
-parent:
-  order: false
-layout: home
--->
+# Website
 
-# Cosmos Hub Documentation
+This website is built using [Docusaurus 2](https://docusaurus.io/), a modern static website generator.
 
-Welcome to the documentation of the **Cosmos Hub application: `gaia`**.
+### Installation
 
-## What is Gaia?
+```
+$ yarn
+```
 
-- [Intro to the `gaia` software](./getting-started/what-is-gaia.md)
-- [Interacting with the `gaiad` binary](./hub-tutorials/gaiad.md)
+### Local Development
 
-## Join the Cosmos Hub Mainnet
+```
+$ yarn start
+```
 
-- [Install the `gaia` application](./getting-started/installation.md)
-- [Set up a full node and join the mainnet](./hub-tutorials/join-mainnet.md)
-- [Upgrade to a validator node](./validators/validator-setup.md)
+This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.
 
-## Join the Cosmos Hub Public Testnet
+### Build
 
-- [Join the testnet](./hub-tutorials/join-testnet.md)
+```
+$ yarn build
+```
 
-## Setup Your Own `gaia` Testnet
+This command generates static content into the `build` directory and can be served using any static contents hosting service.
 
-- [Setup your own `gaia` testnet](https://github.com/cosmos/testnets/tree/master/local/previous-local-testnets/theta)
+### Deployment
 
-## Additional Resources
+Using SSH:
 
-- [Validator Resources](./validators/README.md): Contains documentation for `gaia` validators.
-- [Delegator Resources](./delegators/README.md): Contains documentation for delegators.
-- [Other Resources](./resources/README.md): Contains documentation on `gaiad`, genesis file, service providers, ledger wallets, ...
-- [Cosmos Hub Archives](./resources/archives.md): State archives of past iteration of the Cosmos Hub.
+```
+$ USE_SSH=true yarn deploy
+```
 
-# Contribute
+Not using SSH:
 
-See [this file](./DOCS_README.md) for details of the build process and
-considerations when making changes.
+```
+$ GIT_USER=<Your GitHub username> yarn deploy
+```
+
+If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the `gh-pages` branch.

docs/babel.config.js

@@ -1,3 +1,3 @@
 module.exports = {
   presets: [require.resolve('@docusaurus/core/lib/babel/preset')],
-};
+};

docs/docs/architecture/PROCESS.md

@@ -0,0 +1,57 @@
+# ADR Creation Process
+
+1. Copy the `adr-template.md` file. Use the following filename pattern: `adr-next_number-title.md`
+2. Create a draft Pull Request and solicit input from the stewarding team, if you want to get an early feedback.
+3. Make sure that the problem, the context and a recommended solution is clear and well documented. Be sure to document alternate solution spaces and give reasons why they have been discarded.
+4. Add an entry to a list in the README file [Table of Contents](./README.md#adr-table-of-contents).
+5. Create a Pull Request to propose a new ADR.
+
+## ADR life cycle
+
+ADR creation is an **iterative** process. Instead of trying to solve all decisions in a single ADR pull request, we MUST firstly understand the problem and collect feedback through a GitHub Issue.
+
+1. Every proposal SHOULD start with a new GitHub Issue or be a result of existing Issues. The Issue should contain just a brief proposal summary.
+
+2. Once the motivation is validated, a GitHub Pull Request (PR) is created with a new document based on the `adr-template.md`.
+
+3. An ADR doesn't have to arrive to `main` with an _accepted_ status in a single PR. If the motivation is clear and the solution is sound, we SHOULD be able to merge it and keep a _proposed_ status. It's preferable to have an iterative approach rather than long, not merged Pull Requests.
+
+4. If a _proposed_ ADR is merged, then it should clearly document outstanding issues either in ADR document notes or in a GitHub Issue.
+
+5. The PR SHOULD always be merged. In the case of a faulty ADR, we still prefer to merge it with a _rejected_ status. The only time the ADR SHOULD NOT be merged is if the author abandons it.
+
+6. Merged ADRs SHOULD NOT be deleted.
+
+### ADR status
+
+Status has two components:
+
+```text
+{CONSENSUS STATUS} {IMPLEMENTATION STATUS}
+```
+
+IMPLEMENTATION STATUS is either `Implemented` or `Not Implemented`.
+
+#### Consensus Status
+
+```mermaid
+flowchart TD
+    A[DRAFT] --> B[PROPOSED]
+    B --> C[LAST CALL YYYY-MM-DD]
+    B --> D[ABANDONED]
+    C --> E[ACCEPTED or REJECTED]
+    E --> F[SUPERSEDED by ADR-xxx]
+```
+
+* `DRAFT`: [optional] an ADR which is work in progress, not being ready for a general review. This is to present an early work and get an early feedback in a Draft Pull Request form.
+* `PROPOSED`: an ADR covering a full solution architecture and still in the review - project stakeholders haven't reached an agreement yet.
+* `LAST CALL <date for the last call>`: [optional] clear notify that we are close to accept updates. Changing a status to `LAST CALL` means that social consensus (of Cosmos SDK maintainers) has been reached and we still want to give it a time to let the community react or analyze.
+* `ACCEPTED`: ADR which will represent a currently implemented or to be implemented architecture design.
+* `REJECTED`: ADR can go from PROPOSED or ACCEPTED to rejected if the consensus among project stakeholders will decide so.
+* `SUPERSEEDED by ADR-xxx`: ADR which has been superseded by a new ADR.
+* `ABANDONED`: the ADR is no longer pursued by the original authors.
+
+## Language used in ADR
+
+* The context/background should be written in the present tense.
+* Avoid using a first, personal form.

docs/docs/architecture/README.md

@@ -0,0 +1,64 @@
+<!--
+order: 1
+parent:
+  title: Architecture Decision Records (ADR)
+  order: 10
+-->
+
+# Architecture Decision Records (ADR)
+
+This is a location to record all high-level architecture decisions for new feature and module proposals in the Cosmos Hub.
+
+An Architectural Decision (**AD**) is a software design choice that addresses a functional or non-functional requirement that is architecturally significant.
+An Architecturally Significant Requirement (**ASR**) is a requirement that has a measurable effect on a software system’s architecture and quality.
+An Architectural Decision Record (**ADR**) captures a single AD, such as often done when writing personal notes or meeting minutes; the collection of ADRs created and maintained in a project constitute its decision log. All these are within the topic of Architectural Knowledge Management (AKM).
+
+You can read more about the ADR concept [here](https://adr.github.io/).
+
+## Rationale
+
+ADRs are intended to be the primary mechanism for proposing new feature designs and new processes, for collecting community input on an issue, and for documenting the design decisions.
+An ADR should provide:
+
+- Context on the relevant goals and the current state
+- Proposed changes to achieve the goals
+- Summary of pros and cons
+- Discarded solution spaces and why they were discarded
+- References
+- Changelog
+
+Note the distinction between an ADR and a spec. The ADR provides the context, intuition, reasoning, and
+justification for a change in architecture, or for the architecture of something
+new. The spec is much more compressed and streamlined summary of everything as
+it stands today.
+
+If recorded decisions turn out to be lacking, convene a discussion, record the new decisions here, and then modify the code to match.
+
+## Creating new ADR
+
+Read about the [PROCESS](./PROCESS.md).
+
+### Use RFC 2119 Keywords
+
+When writing ADRs, follow the same best practices for writing RFCs. 
+When writing RFCs, key words are used to signify the requirements in the specification. 
+These words are often capitalized: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL. 
+They are to be interpreted as described in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119).
+
+## ADR Table of Contents
+
+### Accepted
+
+- [ADR 002: Globalfee Module](./adr-002-globalfee.md)
+
+### Proposed
+
+- n/a
+
+### Draft
+
+- n/a
+
+### Rejected
+
+- [ADR 001: Interchain Accounts](./adr-001-interchain-accounts.md)

docs/docs/architecture/_category_.json

@@ -0,0 +1,5 @@
+{
+    "label": "ADRs",
+    "position": 10,
+    "link": null
+}

docs/readiness/adr-001-interchain-accounts.md → docs/docs/architecture/adr-001-interchain-accounts.md

@@ -2,26 +2,19 @@
 order: 2
 -->
 
----
-
-ADR: 001
-Title: Interchain Accounts
-Status: Draft Implements
-Category: Feature
-Author: Sean King & Damian Nolan
-Created: 2022-01-19
-Mdified: 2022-01-19
-Requires: Cosmos-SDK, go-ibc
-Required-By: mauth
-Implements: Interchain Accounts
----
-
 # ADR 001: Interchain Accounts
 
 ## Changelog
 
 - 2022-02-04: added content
 - 2022-01-19: init
+- 2023-06-28: mark as rejected
+
+## Status
+
+REJECTED Not Implemented
+
+**Reason:** The IBC team decided to integrate this functionality directly into their codebase and maintain it, because multiple users require it. 
 
 ## Abstract
 
@@ -98,4 +91,4 @@ There are future releases of Interchain Accounts which are expected to be backwa
 ## Additional Research & References
 
 - [Why Interchain Accounts Change Everything for Cosmos Interoperability](https://medium.com/chainapsis/why-interchain-accounts-change-everything-for-cosmos-interoperability-59c19032bf11)
-- [Interchain Account Auth Module Demo Repo](https://github.com/cosmos/interchain-accounts)
+- [Interchain Account Auth Module Demo Repo](https://github.com/cosmos/interchain-accounts)