agorise/bsips
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Distinction Final/Accepted/Draft

Browse source
This commit is contained in:
Fabian Schuh 2016-01-29 12:39:37 +01:00
parent 6a31de24d0
commit 858c935d7a
1 changed files with 24 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

41
bsip-0001.md
View file

@ -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