From 95c008392ae9540119c845ec5f43be58129a8624 Mon Sep 17 00:00:00 2001 From: "mergify[bot]" <37929162+mergify[bot]@users.noreply.github.com> Date: Tue, 10 Oct 2023 09:51:59 +0200 Subject: [PATCH] docs: fix typos (backport #18028) (#18031) Co-authored-by: vuittont60 <81072379+vuittont60@users.noreply.github.com> --- docs/architecture/adr-018-extendable-voting-period.md | 2 +- docs/architecture/adr-020-protobuf-transaction-encoding.md | 2 +- docs/architecture/adr-023-protobuf-naming.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/architecture/adr-018-extendable-voting-period.md b/docs/architecture/adr-018-extendable-voting-period.md index ee238fc35ae8..5e8f058d12fa 100644 --- a/docs/architecture/adr-018-extendable-voting-period.md +++ b/docs/architecture/adr-018-extendable-voting-period.md @@ -6,7 +6,7 @@ ## Context -Currently the voting period for all governance proposals is the same. However, this is suboptimal as all governance proposals do not require the same time period. For more non-contentious proposals, they can be dealt with more efficently with a faster period, while more contentious or complex proposals may need a longer period for extended discussion/consideration. +Currently the voting period for all governance proposals is the same. However, this is suboptimal as all governance proposals do not require the same time period. For more non-contentious proposals, they can be dealt with more efficiently with a faster period, while more contentious or complex proposals may need a longer period for extended discussion/consideration. ## Decision diff --git a/docs/architecture/adr-020-protobuf-transaction-encoding.md b/docs/architecture/adr-020-protobuf-transaction-encoding.md index 4c30bb9ebe3d..b26f394bd5d8 100644 --- a/docs/architecture/adr-020-protobuf-transaction-encoding.md +++ b/docs/architecture/adr-020-protobuf-transaction-encoding.md @@ -277,7 +277,7 @@ We propose that field numbers with bit 11 set (for most use cases this is the range of 1024-2047) be considered non-critical fields that can safely be ignored if unknown. -To handle this we will need a unknown field filter that: +To handle this we will need an unknown field filter that: * always rejects unknown fields in unsigned content (i.e. top-level `Tx` and unsigned parts of `AuthInfo` if present based on the signing mode) diff --git a/docs/architecture/adr-023-protobuf-naming.md b/docs/architecture/adr-023-protobuf-naming.md index 4360befded06..a192dfce3264 100644 --- a/docs/architecture/adr-023-protobuf-naming.md +++ b/docs/architecture/adr-023-protobuf-naming.md @@ -191,7 +191,7 @@ is used in source code to denote modules, this is often unnecessary for .proto files as modules are the primary thing sub-packages are used for. Only items which are known to be used infrequently should have deep sub-package depths. -For the Cosmos SDK, it is recommended that that we simply write `cosmos.bank`, +For the Cosmos SDK, it is recommended that we simply write `cosmos.bank`, `cosmos.gov`, etc. rather than `cosmos.x.bank`. In practice, most non-module types can go straight in the `cosmos` package or we can introduce a `cosmos.base` package if needed. Note that this naming _will not_ change