Distinction Final/Accepted/Draft

This commit is contained in:
Fabian Schuh 2016-01-29 12:39:37 +01:00
parent 6a31de24d0
commit 858c935d7a

View file

@ -39,21 +39,28 @@ There are two kinds of BSIPs:
# Contributing # Contributing
People wishing to submit BSIPs first should propose their idea as issue or People wishing to submit BSIPs first should propose their idea as github
document as pull request. After discussion it will be published here. We are issue first. After discussion you will be assigned a number for the bsip
fairly liberal with listing BSIP drafts here since the final decision of its and can send a pull request for your *draft*. Once consensus among
actual implementation is made solely by BitShares shareholders via approval discussion particpants is reached, the status can be switched to
voting. *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* If the proposal requires a protocol upgrade, the proposal is considered
only if shareholders have approved a corresponding worker or hard fork proposal. *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 We are fairly liberal with listing BSIP drafts here since the
that a single BSIP contain a single key proposal or new idea. Small enhancements final decision of its actual implementation is made solely by BitShares
or patches often don't need a BSIP and can be injected into the BitShares shareholders via approval voting.
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 It is highly recommended that a single BSIP contain a single key
reserves the right to reject BSIP proposals if they appear too unfocused or too 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. 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 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 represent a net improvement. The proposed implementation, if applicable, must be
solid and must not complicate the protocol unduly. solid and must not complicate the protocol unduly.
Once a BSIP has been accepted, the reference implementation must be completed. Once a BSIP has been published, the reference implementation must be
When the reference implementation is complete and accepted by the shareholders completed. When the reference implementation is complete and accepted
via approval voting, the status will be changed to "Final". A BSIP can also be by the shareholders via approval voting, the status will be changed to
"Rejected" by shareholders. "Accepted". A BSIP can also be "Rejected" by shareholders.
Furthermore, a BSIP can be assigned status "Deferred". The BSIP author or editor 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 can assign the BSIP this status when no progress is being made on the BSIP. Once