From 06516f7eb3ada942f2642c0adc0e578198a000c5 Mon Sep 17 00:00:00 2001 From: Prajjwol Gautam Date: Wed, 6 Oct 2021 12:51:23 -0700 Subject: [PATCH] docs: fix broken links in markdown files (#631) --- docs/architecture/PROCESS.md | 56 ++++++++++++++++++++++++++ docs/architecture/adr-002-evm-hooks.md | 2 +- 2 files changed, 57 insertions(+), 1 deletion(-) create mode 100644 docs/architecture/PROCESS.md diff --git a/docs/architecture/PROCESS.md b/docs/architecture/PROCESS.md new file mode 100644 index 00000000..ca905672 --- /dev/null +++ b/docs/architecture/PROCESS.md @@ -0,0 +1,56 @@ +# 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 if you want to get an early feedback. +3. Make sure the context and a solution is clear and well documented. +4. Add an entry to a list in the [README](./README.md) file. +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 `master` 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 pruned. + +### ADR status + +Status has two components: + +``` +{CONSENSUS STATUS} {IMPLEMENTATION STATUS} +``` + +IMPLEMENTATION STATUS is either `Implemented` or `Not Implemented`. + +#### Consensus Status + +``` +DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEDED by ADR-xxx + \ | + \ | + v v + ABANDONED +``` + ++ `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 agreed yet. ++ `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. \ No newline at end of file diff --git a/docs/architecture/adr-002-evm-hooks.md b/docs/architecture/adr-002-evm-hooks.md index be2ef242..2326f582 100644 --- a/docs/architecture/adr-002-evm-hooks.md +++ b/docs/architecture/adr-002-evm-hooks.md @@ -210,4 +210,4 @@ Later, this section can optionally list ideas or improvements the author or revi -- [Hooks in staking module](https://docs.cosmos.network/v0.43/modules/staking/06_hooks.html) +- [Hooks in staking module](https://docs.cosmos.network/master/modules/staking/06_hooks.html)