all: rename go module to evmos/ethermint (#1137)

2022-06-19 11:43:41 +02:00
parent a8d3805ddf
commit ec8e93b319
190 changed files with 1137 additions and 1506 deletions
@@ -14,11 +14,11 @@ ADR creation is an **iterative** process. Instead of trying to solve all decisio

 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.
+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.
+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.
+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.

@@ -53,4 +53,4 @@ DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEDED b
 ## Language used in ADR

 + The context/background should be written in the present tense.
-+ Avoid using a first, personal form.
+ Avoid using a first, personal form.