Skip to content

Commit

Permalink
Merge pull request #97 from celestiaorg/ebuchman-patch-1
Browse files Browse the repository at this point in the history
Update cip-template.md with parameter section
  • Loading branch information
jcstein authored Mar 14, 2024
2 parents e0275fb + 63b681c commit 0892ba7
Show file tree
Hide file tree
Showing 2 changed files with 21 additions and 0 deletions.
1 change: 1 addition & 0 deletions cips/cip-1.md
Original file line number Diff line number Diff line change
Expand Up @@ -274,6 +274,7 @@ the following parts:
and semantics of any new feature. The specification should be detailed
enough to enable competing, interoperable implementations for any of the
current Celestia platforms.
* **Parameters**: Summary of any parameters introduced by or changed by the CIP.
* **Rationale**: The rationale elaborates on the specification by explaining
the reasoning behind the design and the choices made during the design process.
It should discuss alternative designs that were considered and any related work.
Expand Down
20 changes: 20 additions & 0 deletions cips/cip-template.md
Original file line number Diff line number Diff line change
Expand Up @@ -42,6 +42,26 @@ It is recommended to follow RFC 2119 and RFC 8170. Do not remove the key word de

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

## Parameters

The parameters section should summarize any changes to global or module parameters, including any new parameters, introduced by the CIP. All mainnet parameters are tracked in [CIP-13](./cip-13.md). Once a CIP is accepted and deployed to mainnet, CIP-13 MUST be updated with these parameter changes. If there are no parameter changes in the CIP, this section can be omitted.

**TODO: Remove the previous comments and update the following table before submitting**

| Parameter | Proposed value | Description | Changeable via Governance |
|---------------|---------|------------------------------------------------------------------------------------------------------------------------|---------------------------|
| module1.Name1 | ProposedValue1 | Description1 | bool |
| module2.Name2 | ProposedValue2 | Description2 | bool |

For changes to existing parameters, use the following table:

| Parameter | Current value | Proposed value | Description | Changeable via Governance |
|---------------|---------------|----------------|--------------|---------------------------|
| module1.Name1 | CurrentValue1 | ProposedValue1 | Description1 | bool |
| module2.Name1 | CurrentValue2 | ProposedValue2 | Description2 | bool |

For new parameters the Current value column can be omitted.

## Rationale

The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.
Expand Down

0 comments on commit 0892ba7

Please sign in to comment.