diff options
| author | Bryan Newbold <bnewbold@robocracy.org> | 2018-01-24 22:45:45 -0800 |
|---|---|---|
| committer | Bryan Newbold <bnewbold@robocracy.org> | 2018-01-24 22:45:45 -0800 |
| commit | 792b681d3633af9ad17a351b6957fcf5cbab5796 (patch) | |
| tree | 6464b2aabf852f28aad0d1a528984cfe6a678f46 | |
| parent | a641c5f30b8f1a82d6486bb03ec05b03cad8ab30 (diff) | |
| download | dat-deps-792b681d3633af9ad17a351b6957fcf5cbab5796.tar.gz dat-deps-792b681d3633af9ad17a351b6957fcf5cbab5796.zip | |
small tweaks to template
| -rw-r--r-- | 0000-template.md | 11 |
1 files changed, 11 insertions, 0 deletions
diff --git a/0000-template.md b/0000-template.md index b269b1c..bea1fae 100644 --- a/0000-template.md +++ b/0000-template.md @@ -11,21 +11,25 @@ Github PR: (add HTTPS link here after PR is opened) Authors: TBD + # Summary [summary]: #summary One paragraph explanation of what this is about. + # Motivation [motivation]: #motivation Why are we doing this? What use cases does it support? What is the expected outcome? + # Usage Documentation [usage-documentation]: #usage-documentation Document new features or processes as if this proposal has already been accepted and implemented. This section should introduce new concepts and terms, describe use cases or situations, and provide examples. If a user-facing feature is added, this should also include user-accessible documentation. + # Reference Documentation [reference-documentation]: #reference-documentation @@ -33,11 +37,15 @@ This section is a more formal description of the proposal, written as if it was It should be unambiguous and cover all known corner-cases. Formal language (such as protobuf schemas or binary header diagrams) are appropriate here. +"Standards" proposals should include a section addressing security and privacy implications. + + # Drawbacks [drawbacks]: #drawbacks Why should we *not* do this? + # Rationale and alternatives [alternatives]: #alternatives @@ -45,6 +53,7 @@ Why should we *not* do this? - What other designs have been considered and what is the rationale for not choosing them? - What is the impact of not doing this? + # Unresolved questions [unresolved]: #unresolved-questions @@ -52,6 +61,7 @@ Why should we *not* do this? - What parts of the design do you expect to resolve through implementation and code review, or are left to independent library or application developers? - What related issues do you consider out of scope for this DEP that could be addressed in the future independently of the solution that comes out of this DEP? + # Changelog [changelog]: #changelog @@ -59,3 +69,4 @@ A brief statemnt about current status can go here, follow by a list of dates when the status line of this DEP changed (in most-recent-last order). - YYYY-MM-DD: First complete draft submitted for review + |