Merge branch 'master' into cip-editor-meeting-59-chores

.github/CIP-TEMPLATE.md

@@ -1,26 +1,42 @@
 ---
 CIP: ?
 Title: ?
-Authors: John Doe <john.doe@email.domain>
-Status: Draft
-Type: Core | Process | Informational
+Category: ?
+Status: Proposed
+Authors:
+    - John Doe <john.doe@email.domain>
+Implementors: []
+Discussions:
+    - https://github.com/cardano-foundation/cips/pulls/?
 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 -->
+## Abstract
+<!-- A short (\~200 word) description of the proposed solution and the technical issue being addressed. -->
 
-## 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. -->
+## Motivation: why is this CIP necessary?
+<!-- A clear explanation that introduces the reason for a proposal, its use cases and stakeholders. If the CIP changes an established design then 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 and link to it as the `Motivation`. -->
 
-## 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. -->
+## 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 on the basis of the design in the CIP. This is necessary to facilitate multiple, 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. -->
+## 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.
 
-## 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. -->
+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.
+-->
 
-## Copyright <!-- The CIP must be explicitly licensed under acceptable copyright terms (see below). -->
+## Path to Active
 
-This CIP is licensed under [CC-BY-4.0][].
+### Acceptance Criteria
+<!-- Describes what are the acceptance criteria whereby a proposal becomes 'Active' -->
+
+### Implementation Plan
+<!-- A plan to meet those criteria. Or `N/A` if not applicable. -->
+
+## Copyright
+<!-- The CIP must be explicitly licensed under acceptable copyright terms. -->
 
 [CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode
 [Apache-2.0]: http://www.apache.org/licenses/LICENSE-2.0

.github/CPS-TEMPLATE.md

@@ -0,0 +1,31 @@
+---
+CPS: ?
+Title: ?
+Status: Open
+Category: ?
+Authors:
+    - John Doe <john.doe@email.domain>
+Proposed Solutions: []
+Discussions:
+    - https://github.com/cardano-foundation/cips/pulls/?
+Created: YYYY-MM-DD
+---
+
+## Abstract
+<!-- A short (\~200 word) description of the target goals and the technical obstacles to those goals. -->
+
+## Problem
+<!-- A more elaborate description of the problem and its context. This section should explain what motivates the writing of the CPS document. -->
+
+## Use cases
+<!-- A concrete set of examples written from a user's perspective, describing what and why they are trying to do. When they exist, this section should give a sense of the current alternatives and highlight why they are not suitable. -->
+
+## Goals
+<!-- A list of goals and non-goals a project is pursuing, ranked by importance. These goals should help understand the design space for the solution and what the underlying project is ultimately trying to achieve.
+
+Goals may also contain requirements for the project. For example, they may include anything from a deadline to a budget (in terms of complexity or time) to security concerns.
+
+Finally, goals may also serve as evaluation metrics to assess how good a proposed solution is. -->
+
+## Open Questions
+<!-- A set of questions to which any proposed solution should find an answer. Questions should help guide solutions design by highlighting some foreseen vulnerabilities or design flaws. Solutions in the form of CIP should thereby include these questions as part of their 'Rationale' section and provide an argued answer to each. -->