From 858c935d7ade2858190da00f5bacb2dd466a915d Mon Sep 17 00:00:00 2001 From: Fabian Schuh Date: Fri, 29 Jan 2016 12:39:37 +0100 Subject: [PATCH] Distinction Final/Accepted/Draft --- bsip-0001.md | 41 ++++++++++++++++++++++++----------------- 1 file changed, 24 insertions(+), 17 deletions(-) diff --git a/bsip-0001.md b/bsip-0001.md index b9a33e1..9fc0a49 100644 --- a/bsip-0001.md +++ b/bsip-0001.md @@ -39,21 +39,28 @@ There are two kinds of BSIPs: # Contributing -People wishing to submit BSIPs first should propose their idea as issue or -document as pull request. After discussion it will be published here. We are -fairly liberal with listing BSIP drafts here since the final decision of its -actual implementation is made solely by BitShares shareholders via approval -voting. +People wishing to submit BSIPs first should propose their idea as github +issue first. After discussion you will be assigned a number for the bsip +and can send a pull request for your *draft*. Once consensus among +discussion particpants is reached, the status can be switched to +*final*. From this time on, major changes of the document will not be +permitted. -If the proposal requires a protocol upgrade, the proposal is considered *final* -only if shareholders have approved a corresponding worker or hard fork proposal. +If the proposal requires a protocol upgrade, the proposal is considered +*accepted* only if shareholders have approved a corresponding worker or +hard fork proposal. Informational BSIPs can only reach the *final* +state since their implementation is not enforced by the blockchain. -The BSIP process begins with a new idea for BitShares. It is highly recommended -that a single BSIP contain a single key proposal or new idea. Small enhancements -or patches often don't need a BSIP and can be injected into the BitShares -development work flow with a patch submission to the BitShares issue tracker. -The more focused the BSIP, the more successful it tends to be. The BSIP editor -reserves the right to reject BSIP proposals if they appear too unfocused or too +We are fairly liberal with listing BSIP drafts here since the +final decision of its actual implementation is made solely by BitShares +shareholders via approval voting. + +It is highly recommended that a single BSIP contain a single key +proposal or new idea. Small enhancements or patches often don't need a +BSIP and can be injected into the BitShares development work flow with a +patch submission to the BitShares issue tracker. The more focused the +BSIP, the more successful it tends to be. The BSIP editor reserves the +right to reject BSIP proposals if they appear too unfocused or too broad. If in doubt, split your BSIP into several well-focused ones. Vetting an idea publicly before going as far as writing a BSIP is meant to save @@ -86,10 +93,10 @@ clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. -Once a BSIP has been accepted, the reference implementation must be completed. -When the reference implementation is complete and accepted by the shareholders -via approval voting, the status will be changed to "Final". A BSIP can also be -"Rejected" by shareholders. +Once a BSIP has been published, the reference implementation must be +completed. When the reference implementation is complete and accepted +by the shareholders via approval voting, the status will be changed to +"Accepted". A BSIP can also be "Rejected" by shareholders. Furthermore, a BSIP can be assigned status "Deferred". The BSIP author or editor can assign the BSIP this status when no progress is being made on the BSIP. Once