Problem: Current shortnames weird/hard-to-remember

Solution: Switch to shortnames like BEP-2, as suggested in issue bigchaindb#32
ttmc · Jun 14, 2018 · ecdeca1 · ecdeca1
1 parent 4b61a57
commit ecdeca1
Show file tree

Hide file tree

Showing 14 changed files with 42 additions and 41 deletions.
diff --git a/1/README.md b/1/README.md
@@ -1,5 +1,5 @@
 ```
-shortname: 1/C4
+shortname: BEP-1
 name: Collective Code Construction Contract
 type: Meta
 status: Draft

diff --git a/10/README.md b/10/README.md
@@ -1,5 +1,5 @@
 ```
-shortname: 10/SAAR
+shortname: BEP-10
 Name: A Strangler Application Approach to Rewriting Some Code in Go
 type: Informational
 status: Raw

diff --git a/12/README.md b/12/README.md
@@ -1,5 +1,5 @@
 ```
-shortname: 12/TX-SPEC-1
+shortname: BEP-12
 name: BigchainDB Transactions Spec v1
 type: Standard
 status: Stable
@@ -26,7 +26,7 @@ It was also implemented by several BigchainDB drivers. We may make a complete li
 
 # Change Process
 
-The process to change this document is [2/COSS](../2/README.md) (COSS).
+The process to change this document is [BEP-2 (COSS)](../2/README.md).
 
 # Specification
 

diff --git a/13/README.md b/13/README.md
@@ -1,5 +1,5 @@
 ```
-shortname: 13/TX-SPEC-2
+shortname: BEP-13
 name: BigchainDB Transactions Spec v2
 type: Standard
 status: Stable
@@ -54,7 +54,7 @@ For the reasoning, see [bigchaindb/bigchaindb#1937](https://github.com/bigchaind
 
 # Change Process
 
-The process to change this document is [2/COSS](../2/README.md) (COSS).
+The process to change this document is [BEP-2 (COSS)](../2/README.md).
 
 # Specification
 

diff --git a/14/README.md b/14/README.md
@@ -1,5 +1,5 @@
 ```
-shortname: 14/GIDR
+shortname: BEP-14
 name: Guidelines to Improve Drivers Reliability
 type: standard
 status: raw

diff --git a/17/README.md b/17/README.md
@@ -1,5 +1,5 @@
 ```
-shortname: 17/AZURE-1
+shortname: BEP-17
 name: Listing BigchainDB in Azure Marketplace, Phase 1
 type: Standard
 status: Raw

diff --git a/2/README.md b/2/README.md
@@ -1,5 +1,5 @@
 ```
-shortname: 2/COSS
+shortname: BEP-2
 name: Consensus-Oriented Specification System
 type: Meta
 status: Draft
@@ -12,7 +12,7 @@ This document describes a consensus-oriented specification system (COSS) for bui
 This specification is based on [unprotocols.org 2/COSS](https://rfc.unprotocols.org/spec:2/COSS/) and on [EIP1 - EIP Purpose and Guidelines](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1.md).
 
 ## Change Process
-This document is governed by the [2/COSS](../2/README.md) (COSS).
+This document is governed by the [BEP-2 (COSS)](../2/README.md) (COSS).
 
 ## Language
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://tools.ietf.org/html/bcp14) \[[RFC2119](https://tools.ietf.org/html/rfc2119)\] \[[RFC8174](https://tools.ietf.org/html/rfc8174)\] when, and only when, they appear in all capitals, as shown here.
@@ -48,7 +48,7 @@ There are three types of BEPs:
 * A **Meta BEP** describes a process surrounding BigchainDB or proposes a change to a process.
 
 ### BEP Format
-A BEP is a set of Markdown documents (the main file SHOULD be called `README.md`), together with comments, attached files, and other resources. A BEP is identified by its number and short name (e.g. this BEP is **2/COSS**). The number of the BEP is also the name of the directory where its files are stored.
+A BEP is a set of Markdown documents (the main file SHOULD be called `README.md`), together with comments, attached files, and other resources. A BEP is identified by its number (e.g. this BEP is **BEP-2**). The number of the BEP is also the name of the directory where its files are stored.
 
 Every BEP (including branches) carries a different number. New versions of the same BEP have new numbers.
 
@@ -82,7 +82,7 @@ Each BEP SHOULD include the following sections:
 
 1. **Implementation**. The implementations must be completed before any BEP is given status "stable", but it need not be completed before the BEP is accepted. While there is merit to the approach of reaching consensus on the BEP and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.
 
-1. **Copyright Waiver**. Except for 1/C4 and 2/COSS, all BEPs MUST be released to the public domain. The following waiver SHOULD be used: _To the extent possible under law, the person who associated CC0 with this work has waived all copyright and related or neighboring rights to this work._
+1. **Copyright Waiver**. Except for BEP-1 (C4) and BEP-2 (COSS), all BEPs MUST be released to the public domain. The following waiver SHOULD be used: _To the extent possible under law, the person who associated CC0 with this work has waived all copyright and related or neighboring rights to this work._
 
 The first 4 sections above are based on the [Leslie Lamport's note about describing solutions](https://lamport.azurewebsites.net/pubs/state-the-problem.pdf).
 

diff --git a/3/README.md b/3/README.md
@@ -1,5 +1,5 @@
 ```
-shortname: 3/UPSERT-VALIDATORS
+shortname: BEP-3
 name: Dynamically add/update/remove validators at runtime
 type: standard
 status: stable

diff --git a/4/README.md b/4/README.md
@@ -1,5 +1,5 @@
 ```
-shortname: 4/STANDARDIZE-DC
+shortname: BEP-4
 name: Standard process to set up a local node for development & testing, using Docker Compose
 type: standard
 status: raw

diff --git a/5/README.md b/5/README.md
@@ -1,5 +1,5 @@
 ```
-shortname: 5/IDRP
+shortname: BEP-5
 name: Illegal Data Response Plan
 type: Informational
 status: raw
@@ -200,7 +200,7 @@ So we dropped it. Maybe we are too nice. Dogmatism got in the way of pragmatism.
 
 ## Can I Suggest an Improvement to This BEP?
 
-BigchainDB GmbH has a process to improve BEPs like this one. Please see [BEP-1/C4](https://github.com/bigchaindb/BEPs/blob/master/1) and [BEP-2/COSS](https://github.com/bigchaindb/BEPs/blob/master/2).
+BigchainDB GmbH has a process to improve BEPs like this one. Please see [BEP-1 (C4)](https://github.com/bigchaindb/BEPs/blob/master/1) and [BEP-2 (COSS)](https://github.com/bigchaindb/BEPs/blob/master/2).
 
 Your consortium might have a variation of the IDRP. Your consortium can modify its variant using it's own governance processes.
 

diff --git a/6/README.md b/6/README.md
@@ -1,6 +1,6 @@
 # Shared Workspace Protocol
 ```
-shortname: 6/SWP
+shortname: BEP-6
 name: Shared Workspace Protocol
 type: Meta
 status: Draft

diff --git a/7/README.md b/7/README.md
@@ -1,5 +1,5 @@
 ```
-shortname: 7/PUBLIC-API
+shortname: BEP-7
 name: Definition of the BigchainDB Public API
 type: Informational
 status: raw

diff --git a/8/README.md b/8/README.md
@@ -1,5 +1,5 @@
 ```
-shortname: 8/CRASH-RECOVERY
+shortname: BEP-8
 name: Restore system state after crash
 type: standard
 status: raw

diff --git a/README.md b/README.md
@@ -3,36 +3,37 @@
 This is the BigchainDB Enhancement Proposal project. We collect BEPs for APIs, protocols, and processes.
 
 The process to add or change a BEP is the following:
-- A BEP is created and modified by pull requests according to [C4](./1).
-- BEP lifecycle SHOULD follow the lifecycle defined in [COSS](./2).
+
+- A BEP is created and modified by pull requests according to [BEP-1 (our variant of C4)](./1).
+- The BEP life-cycle SHOULD follow the life-cycle defined in [BEP-2 (our variant of COSS)](./2).
 - Non-cosmetic changes are allowed only on [Raw](./2#raw-beps) and [Draft](./2#draft-beps) specifications.
 
-# Current BEPs
+## Current BEPs
 
-Short Name  | Title | Type | Status | Editor
---------------|--------------------------------------------------------------|----------|------------|-------
-[1/C4](1)  | Collective Code Construction Contract | Meta | Draft | Alberto Granzotto
-[2/COSS](2) | Consensus-Oriented Specification System | Meta | Draft | Alberto Granzotto
-[3/UPSERT-VALIDATORS](3) | Dynamically add/update/remove validators at runtime | Standard | Stable | Vanshdeep Singh
-[4/STANDARDIZE-DC](4) | Standard process to set up a local node for development & testing, using Docker Compose | Standard | Raw | Muawia Khan
-[5/IDRP](5) | Illegal Data Response Plan | Informational | Raw | Troy McConaghy
-[6/SWP](6)  | Shared Workspace Protocol | Meta | Draft | Alberto Granzotto
-[7/PUBLIC-API](7) | Definition of the BigchainDB Public API | Informational | Raw | Troy McConaghy
-[8/CRASH-RECOVERY](8) | Restore system state after crash | Standard | Raw | Vanshdeep Singh
-[10/SAAR](10)  | A Strangler Application Approach to Rewriting Some Code in Go | Informational | Raw | Alberto Granzotto
-[12/TX-SPEC-1](12) | BigchainDB Transaction Spec v1 | Standard | Stable | Troy McConaghy
-[13/TX-SPEC-2](13) | BigchainDB Transaction Spec v2 | Standard | Stable | Troy McConaghy
-[14/GIDR](14) | Guidelines to Improve Drivers Reliability | Standard | Raw | Alberto Granzotto
-[17/AZURE-1](17) | Listing BigchainDB in Azure Marketplace, Phase 1 | Standard | Raw | Troy McConaghy
+Short Name | Title  | Type | Status | Editor
+-------------|---------------------------------------------------------------|----------|------------|-------
+[BEP-1](1) | Collective Code Construction Contract  | Meta | Draft | Alberto Granzotto
+[BEP-2](2) | Consensus-Oriented Specification System  | Meta | Draft | Alberto Granzotto
+[BEP-3](3)  | Dynamically add/update/remove validators at runtime  | Standard | Stable | Vanshdeep Singh
+[BEP-4](4)  | Standard process to set up a local node for development & testing, using Docker Compose | Standard | Raw | Muawia Khan
+[BEP-5](5) | Illegal Data Response Plan  | Informational | Raw | Troy McConaghy
+[BEP-6](6) | Shared Workspace Protocol  | Meta | Draft | Alberto Granzotto
+[BEP-7](7)  | Definition of the BigchainDB Public API  | Informational | Raw | Troy McConaghy
+[BEP-8](8)  | Restore system state after crash  | Standard | Raw | Vanshdeep Singh
+[BEP-10](10) | A Strangler Application Approach to Rewriting Some Code in Go | Informational | Raw | Alberto Granzotto
+[BEP-12](12) | BigchainDB Transaction Spec v1  | Standard | Stable | Troy McConaghy
+[BEP-13](13) | BigchainDB Transaction Spec v2  | Standard | Stable | Troy McConaghy
+[BEP-14](14) | Guidelines to Improve Drivers Reliability  | Standard | Raw | Alberto Granzotto
+[BEP-17](17) | Listing BigchainDB in Azure Marketplace, Phase 1  | Standard | Raw | Troy McConaghy
 
-# Current Participants
+## Current Participants
 
-## Contributors
+### Contributors
 
 - Anyone who wants to contribute
 - The whole [BigchainDB Team in Berlin](https://github.com/orgs/bigchaindb/people)
 
-## Maintainers
+### Maintainers
 
 Everyone with the ability to merge pull requests. Today that is mainly BigchainDB employees.
 
@@ -46,7 +47,7 @@ Some people have specializations:
 - Docker, Kubernetes, NGINX: Shahbaz, Muawia
 - Docs: Troy
 
-## Administrators (Founders and Others)
+### Administrators (Founders and Others)
 
 - Kamal - @GataKamsky
 - Gautaum - @gautamdhameja