From 489c14f0b7267c4da26fa8fd865bc61f3d462d1a Mon Sep 17 00:00:00 2001 From: Ryan Williams Date: Wed, 26 Jul 2023 11:27:16 +0100 Subject: [PATCH 1/5] Add versioning + other small details --- CIP-0001/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CIP-0001/README.md b/CIP-0001/README.md index f61b44f63..f6820f113 100644 --- a/CIP-0001/README.md +++ b/CIP-0001/README.md @@ -78,7 +78,7 @@ Name | Description Preamble | Headers containing metadata about the CIP ([see below](#header-preamble)). Abstract | A short (\~200 word) description of the proposed solution and the technical issue being addressed. Motivation: why is this CIP necessary? | A clear explanation that introduces a proposal's purpose, use cases, and stakeholders. If the CIP changes an established design, it must outline design issues that motivate a rework. For complex proposals, authors must write a [Cardano Problem Statement (CPS) as defined in CIP-9999][CPS] and link to it as the `Motivation`. -Specification | The technical specification should describe the proposed improvement in sufficient technical detail. In particular, it should provide enough information that an implementation can be performed solely based on the design outlined in the CIP. A complete and unambiguous design is necessary to facilitate multiple interoperable implementations. +Specification | The technical specification should describe the proposed improvement in sufficient technical detail. In particular, it should provide enough information that an implementation can be performed solely based on the design outlined in the CIP. A complete and unambiguous design is necessary to facilitate multiple interoperable implementations.

This must include how the CIP should be versioned. Having stipulation that the proposal must be superseded by another is valid versioning. Adequate description must be given to allow versioned alterations to be added without author oversight.

If a proposal defines structure of on-chain data it must include a CDDL schema. Rationale: how does this CIP achieve its goals? | The rationale fleshes out the specification by describing what motivated the design and what led to particular design decisions. It should describe alternate designs considered and related work. The rationale should provide evidence of consensus within the community and discuss significant objections or concerns raised during the discussion.

It must also explain how the proposal affects the backward compatibility of existing solutions when applicable. If the proposal responds to a [CPS][], the 'Rationale' section should explain how it addresses the CPS and answer any questions that the CPS poses for potential solutions. Path to Active | Organised in two sub-sections (see [Path to Active](#path-to-active) for detail):
Acceptance Criteria
Describes what are the acceptance criteria whereby a proposal becomes _'Active'_.
Implementation Plan
Either a plan to meet those criteria or `N/A` if not applicable. Copyright | The CIP must be explicitly licensed under acceptable copyright terms ([see below](#licensing)). @@ -127,7 +127,7 @@ License: CC-BY-4.0 ##### Repository Organization -A CIP must be stored in a specific folder named after its number (4-digit, left-padded with `0`) and in a file called `README.md`. Before a number is assigned, use `????` as a placeholder number (thus naming new folders as `CIP-????`). After a number has been assigned, rename the folder. +A CIP must be stored in a specific folder named after its number (4-digit, left-padded with `0`) and in a file called `README.md`. Before a number is assigned, use `????` or `XXXX` as a placeholder number (thus naming new folders as `CIP-????` or `CIP-XXXX`). After a number has been assigned, rename the folder. Additional supporting files (such as diagrams, binary specifications, dialect grammars, JSON schemas etc.) may be added to the CIP's folder under freely chosen names. From a9b4c2e5296b87b96c06bab797da86ccdcda72d0 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Fri, 28 Jul 2023 15:23:40 +0530 Subject: [PATCH 2/5] re-introducing 4877c07 - clobbered in force push --- CIP-0001/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-0001/README.md b/CIP-0001/README.md index f6820f113..78445512c 100644 --- a/CIP-0001/README.md +++ b/CIP-0001/README.md @@ -127,7 +127,7 @@ License: CC-BY-4.0 ##### Repository Organization -A CIP must be stored in a specific folder named after its number (4-digit, left-padded with `0`) and in a file called `README.md`. Before a number is assigned, use `????` or `XXXX` as a placeholder number (thus naming new folders as `CIP-????` or `CIP-XXXX`). After a number has been assigned, rename the folder. +A CIP must be stored in a specific folder named after its number (4-digit, left-padded with `0`) and in a file called `README.md`. Before a number is assigned, use `????` or `XXXX` as a placeholder number (thus naming new folders as `CIP-????` or `CIP-XXXX`) or a brief, descriptive text string (e.g. `CIP-my-new-feature`). After a number has been assigned, rename the folder. Additional supporting files (such as diagrams, binary specifications, dialect grammars, JSON schemas etc.) may be added to the CIP's folder under freely chosen names. From ca69d1de58afd6cb5f921b4740d025b6831df357 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Fri, 28 Jul 2023 15:25:01 +0530 Subject: [PATCH 3/5] grammar correction --- CIP-0001/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-0001/README.md b/CIP-0001/README.md index 78445512c..62223d177 100644 --- a/CIP-0001/README.md +++ b/CIP-0001/README.md @@ -78,7 +78,7 @@ Name | Description Preamble | Headers containing metadata about the CIP ([see below](#header-preamble)). Abstract | A short (\~200 word) description of the proposed solution and the technical issue being addressed. Motivation: why is this CIP necessary? | A clear explanation that introduces a proposal's purpose, use cases, and stakeholders. If the CIP changes an established design, it must outline design issues that motivate a rework. For complex proposals, authors must write a [Cardano Problem Statement (CPS) as defined in CIP-9999][CPS] and link to it as the `Motivation`. -Specification | The technical specification should describe the proposed improvement in sufficient technical detail. In particular, it should provide enough information that an implementation can be performed solely based on the design outlined in the CIP. A complete and unambiguous design is necessary to facilitate multiple interoperable implementations.

This must include how the CIP should be versioned. Having stipulation that the proposal must be superseded by another is valid versioning. Adequate description must be given to allow versioned alterations to be added without author oversight.

If a proposal defines structure of on-chain data it must include a CDDL schema. +Specification | The technical specification should describe the proposed improvement in sufficient technical detail. In particular, it should provide enough information that an implementation can be performed solely based on the design outlined in the CIP. A complete and unambiguous design is necessary to facilitate multiple interoperable implementations.

This must include how the CIP should be versioned. Stipulating that the proposal must be superseded by another is valid versioning. Adequate description must be given to allow versioned alterations to be added without author oversight.

If a proposal defines structure of on-chain data it must include a CDDL schema. Rationale: how does this CIP achieve its goals? | The rationale fleshes out the specification by describing what motivated the design and what led to particular design decisions. It should describe alternate designs considered and related work. The rationale should provide evidence of consensus within the community and discuss significant objections or concerns raised during the discussion.

It must also explain how the proposal affects the backward compatibility of existing solutions when applicable. If the proposal responds to a [CPS][], the 'Rationale' section should explain how it addresses the CPS and answer any questions that the CPS poses for potential solutions. Path to Active | Organised in two sub-sections (see [Path to Active](#path-to-active) for detail):
Acceptance Criteria
Describes what are the acceptance criteria whereby a proposal becomes _'Active'_.
Implementation Plan
Either a plan to meet those criteria or `N/A` if not applicable. Copyright | The CIP must be explicitly licensed under acceptable copyright terms ([see below](#licensing)). From c63a8a868894f372cc6481e92b85122916330c52 Mon Sep 17 00:00:00 2001 From: Ryan Williams Date: Wed, 9 Aug 2023 18:51:11 +0100 Subject: [PATCH 4/5] Added details to CIP template to match CIP-01 --- .github/CIP-TEMPLATE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/CIP-TEMPLATE.md b/.github/CIP-TEMPLATE.md index 92709c87e..a9b25a7d0 100644 --- a/.github/CIP-TEMPLATE.md +++ b/.github/CIP-TEMPLATE.md @@ -32,7 +32,7 @@ License: CC-BY-4.0 ## Specification - + ## Rationale: how does this CIP achieve its goals?