From 276a8949f5967e39055320affa9b9933771d1b6c Mon Sep 17 00:00:00 2001 From: Yurii Rashkovskii Date: Fri, 3 Jun 2016 10:19:25 +0700 Subject: [PATCH] Problem: hard to quickly identify the status of a specification Solution: specify color-coded badges --- 1/README.md | 4 +++- 2/README.md | 12 ++++++++++++ 2/deprecated.svg | 1 + 2/draft.svg | 1 + 2/raw.svg | 1 + 2/retired.svg | 1 + 2/stable.svg | 1 + 7 files changed, 20 insertions(+), 1 deletion(-) create mode 100644 2/deprecated.svg create mode 100644 2/draft.svg create mode 100644 2/raw.svg create mode 100644 2/retired.svg create mode 100644 2/stable.svg diff --git a/1/README.md b/1/README.md index 9cb37be..fbc880e 100644 --- a/1/README.md +++ b/1/README.md @@ -1,8 +1,10 @@ +![stable](../2/stable.svg) + The Collective Code Construction Contract (C4) is an evolution of the github.com [Fork + Pull Model](http://help.github.com/send-pull-requests/), aimed at providing an optimal collaboration model for free software projects. This is revision 2 of the C4 specification. * Name: rfc.unprotocols.org/spec:1/C4 (1/C4) * Editor: Pieter Hintjens -* State: stable +* Status: stable This RFC is equivalent (with the exception of minor cosmetic changes) to [ZeroMQ RFC 42/C4](http://rfc.zeromq.org/spec:42) diff --git a/2/README.md b/2/README.md index bf85e18..b6b2d9f 100644 --- a/2/README.md +++ b/2/README.md @@ -1,3 +1,5 @@ +![draft](draft.svg) + This document describes a consensus-oriented specification system (COSS) for building interoperable technical specifications. COSS is based on a lightweight editorial process that seeks to engage the widest possible range of interested parties and move rapidly to consensus through working code. * Name: rfc.unprotocols.org/spec:2/COSS (2/COSS) @@ -135,3 +137,13 @@ Where possible editors and contributors are encouraged to: * Refer to and build on existing work when possible, especially IETF specifications. * Contribute to existing specifications rather than reinvent their own. * Use collaborative branching and merging as a tool for experimentation. + +## Appendix A. Color Coding + +It is RECOMMENDED to use color coding to indicate specification's status. Color coded specifications SHOULD use the following color scheme: + +* ![raw](raw.svg) +* ![draft](draft.svg) +* ![stable](stable.svg) +* ![deprecated](deprecated.svg) +* ![retired](retired.svg) diff --git a/2/deprecated.svg b/2/deprecated.svg new file mode 100644 index 0000000..9009ecf --- /dev/null +++ b/2/deprecated.svg @@ -0,0 +1 @@ +statusdeprecated \ No newline at end of file diff --git a/2/draft.svg b/2/draft.svg new file mode 100644 index 0000000..52c7a6c --- /dev/null +++ b/2/draft.svg @@ -0,0 +1 @@ +statusdraft \ No newline at end of file diff --git a/2/raw.svg b/2/raw.svg new file mode 100644 index 0000000..4c2eb79 --- /dev/null +++ b/2/raw.svg @@ -0,0 +1 @@ +statusraw \ No newline at end of file diff --git a/2/retired.svg b/2/retired.svg new file mode 100644 index 0000000..ce3e470 --- /dev/null +++ b/2/retired.svg @@ -0,0 +1 @@ +statusretired \ No newline at end of file diff --git a/2/stable.svg b/2/stable.svg new file mode 100644 index 0000000..1148cd1 --- /dev/null +++ b/2/stable.svg @@ -0,0 +1 @@ +statusstable \ No newline at end of file