From ecdeca1135903a29045af597b49f046d9919ea37 Mon Sep 17 00:00:00 2001 From: Troy McConaghy Date: Thu, 14 Jun 2018 16:08:02 +0200 Subject: [PATCH] Problem: Current shortnames weird/hard-to-remember Solution: Switch to shortnames like BEP-2, as suggested in issue #32 --- 1/README.md | 2 +- 10/README.md | 2 +- 12/README.md | 4 ++-- 13/README.md | 4 ++-- 14/README.md | 2 +- 17/README.md | 2 +- 2/README.md | 8 ++++---- 3/README.md | 2 +- 4/README.md | 2 +- 5/README.md | 4 ++-- 6/README.md | 2 +- 7/README.md | 2 +- 8/README.md | 2 +- README.md | 45 +++++++++++++++++++++++---------------------- 14 files changed, 42 insertions(+), 41 deletions(-) diff --git a/1/README.md b/1/README.md index f54fc4a..0d30903 100644 --- 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 index 53d9ccf..67d742c 100644 --- 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 index 3eb3ec7..df18e9b 100644 --- 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 index 7e3c610..70455f0 100644 --- 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 index 24012dd..10c2325 100644 --- 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 index b966fbe..79b7bf2 100644 --- 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 index 01649bd..3767123 100644 --- 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 index 4d2daa6..1a2d036 100644 --- 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 index 587124e..6a621da 100644 --- 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 index d4d812a..9b79b7f 100644 --- 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 index 8be83bc..3bb6824 100644 --- 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 index 3a8c8b1..9cc6adf 100644 --- 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 index 4f38397..500cb6d 100644 --- 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 index 4e55e17..27b0f49 100644 --- 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