Skip to content

Add v26 to Cosmos Hub folder #214

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dasanchez wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add v26 to Cosmos Hub folder #214

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
119 changes: 119 additions & 0 deletions docs.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4942,6 +4942,125 @@
]
}
]
},
{
"version": "v26",
"tabs": [
{
"tab": "Documentation",
"groups": [
{
"group": "Cosmos Hub",
"pages": [
"hub/v26/index",
{
"group": "Getting Started",
"pages": [
"hub/v26/getting-started/README",
"hub/v26/getting-started/what-is-gaia",
"hub/v26/getting-started/installation",
"hub/v26/getting-started/quickstart",
"hub/v26/getting-started/system-requirements"
]
},
{
"group": "Hub Tutorials",
"pages": [
"hub/v26/hub-tutorials/gaiad",
"hub/v26/hub-tutorials/join-mainnet",
"hub/v26/hub-tutorials/join-testnet",
"hub/v26/hub-tutorials/live-upgrade-tutorial",
"hub/v26/hub-tutorials/README",
"hub/v26/hub-tutorials/upgrade-node"
]
},
{
"group": "Validators",
"pages": [
"hub/v26/validators/overview",
"hub/v26/validators/README",
"hub/v26/validators/security",
"hub/v26/validators/validator-faq",
"hub/v26/validators/validator-setup",
"hub/v26/validators/kms/kms_ledger",
"hub/v26/validators/kms/kms"
]
},
{
"group": "Delegators",
"pages": [
"hub/v26/delegators/delegator-faq",
"hub/v26/delegators/delegator-guide-cli",
"hub/v26/delegators/delegator-security",
"hub/v26/delegators/README"
]
},
{
"group": "Governance",
"pages": [
"hub/v26/governance/best-practices",
"hub/v26/governance/formatting",
"hub/v26/governance/process",
"hub/v26/governance/README",
"hub/v26/governance/submitting",
"hub/v26/governance/proposal-types/community-pool-spend",
"hub/v26/governance/proposal-types/param-change",
"hub/v26/governance/proposal-types/README",
"hub/v26/governance/proposal-types/software-upgrade",
"hub/v26/governance/proposal-types/text-prop"
]
},
{
"group": "Interchain Security",
"pages": [
"hub/v26/interchain-security/README"
]
},
{
"group": "Modules",
"pages": [
"hub/v26/modules/liquid",
"hub/v26/modules/metaprotocols",
"hub/v26/modules/tokenfactory",
"hub/v26/modules/README"
]
},
{
"group": "Architecture",
"pages": [
"hub/v26/architecture/PROCESS",
"hub/v26/architecture/README",
"hub/v26/architecture/adr/adr-001-interchain-accounts",
"hub/v26/architecture/templates/adr-template",
"hub/v26/architecture/adr/adr-002-globalfee",
"hub/v26/architecture/adr/adr-003-ica-controller",
"hub/v26/architecture/adr/PROCESS",
"hub/v26/architecture/adr/README"
]
},
{
"group": "Resources",
"pages": [
"hub/v26/resources/archives",
"hub/v26/resources/genesis",
"hub/v26/resources/hd-wallets",
"hub/v26/resources/ledger",
"hub/v26/resources/README",
"hub/v26/resources/reproducible-builds",
"hub/v26/resources/service-providers"
]
},
{
"group": "Telemetry",
"pages": [
"hub/v26/telemetry/telemetry"
]
}
]
}
]
}
]
}
]
}
Expand Down
58 changes: 58 additions & 0 deletions hub/v26/architecture/PROCESS.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
---
title: 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](/hub/v26/architecture/README#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.
65 changes: 65 additions & 0 deletions hub/v26/architecture/README.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
---
title: Architecture Decision Records (ADR)
description: >-
This is a location to record all high-level architecture decisions for new
feature and module proposals in the Cosmos Hub.
---
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](/hub/v26/architecture/PROCESS).

### 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

* n/a

### Proposed

* n/a

### Draft

* n/a

### Rejected

* [ADR 001: Interchain Accounts](/hub/v26/architecture/adr/adr-001-interchain-accounts)

### Deprecated

* [ADR 002: Globalfee Module](/hub/v26/architecture/adr/adr-002-globalfee)
58 changes: 58 additions & 0 deletions hub/v26/architecture/adr/PROCESS.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
---
title: 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](/hub/v26/architecture/adr/README#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.
64 changes: 64 additions & 0 deletions hub/v26/architecture/adr/README.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
---
title: Architecture Decision Records (ADR)
---
{/* order: 1 parent: title: Architecture Decision Records (ADR) order: 10 */}

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](/hub/v26/architecture/adr/PROCESS).

### 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

* n/a

### Proposed

* [ADR 003: Interchain Accounts Controller Module](/hub/v26/architecture/adr/adr-003-ica-controller)

### Draft

* n/a

### Rejected

* [ADR 001: Interchain Accounts](/hub/v26/architecture/adr/adr-001-interchain-accounts)

### Deprecated

* [ADR 002: Globalfee Module](/hub/v26/architecture/adr/adr-002-globalfee)
Loading