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