-
Notifications
You must be signed in to change notification settings - Fork 318
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Rework CIP-0001 to reflect reality. (#331)
This is the first step in a broader work aiming at pushing the CIP in the forefront of _every_ Cardano changes. Before addressing current shortcomings of the process, it is necessary to capture what the process _actually is_ at present. This rework will serve as a base for a retrospective discussion amongst the editors and, shall be proposed to the community for approval and review.
- Loading branch information
Showing
6 changed files
with
220 additions
and
300 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,26 @@ | ||
--- | ||
CIP: ? | ||
Title: ? | ||
Authors: John Doe <[email protected]> | ||
Status: Draft | ||
Type: Core | Process | Informational | ||
Created: YYYY-MM-DD | ||
License: CC-BY-4.0 | ||
--- | ||
|
||
## Abstract <!-- A short (~200 word) description of the technical issue being addressed and the proposed solution --> | ||
|
||
## Motivation <!-- A clear and short explanation introducing the reason behind a proposal. When changing an established design, it must outlines issues in the design that motivates a rework. --> | ||
|
||
## Specification <!-- The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations. --> | ||
|
||
## 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. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. When applicable, it must also explain how the proposal affects backward-compatibility of existing solutions. --> | ||
|
||
## Path to Active <!-- A reference implementation, observable metrics or anything showing the acceptance of the proposal in the community. It must be completed before any CIP is given status “Active”, but it need not be completed before the CIP is accepted. It acts as a high-level roadmap for the proposal. --> | ||
|
||
## Copyright <!-- The CIP must be explicitly licensed under acceptable copyright terms (see below). --> | ||
|
||
This CIP is licensed under [CC-BY-4.0][]. | ||
|
||
[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode | ||
[Apache-2.0]: http://www.apache.org/licenses/LICENSE-2.0 |
Binary file not shown.
Oops, something went wrong.