[Start Here] OBIP Issue Guide #10
Description
Introduction
The OpenBazaar protocol can adopt new features via the OpenBazaar Improvement Proposal (OBIP) process. It allows anyone in the community to create a proposal for a new feature.
To get started, please read OBIP-0001 carefully to familiarise yourself with how to create an OBIP. It should be clear that OBIPs aren't a simple feature request [1], rather it is a place to submit a detailed specification that - if accepted - will be adopted into the protocol and implemented into code.
Feedback Phase
After an OBIP is accepted as a 'draft', the author of the OBIP will need to oversee the collection feedback from the community. To facilitate this, the 'issues' section of the OBIPs repo will be the central place to discuss draft OBIPs.
The author will create an issue for their OBIP (i.e. OBIP-XXXX: [Insert title here]). Members of the community will have a reasonable timeframe (at least 2 weeks) to comment, suggest changes, or raise objections. The author can interact with the community, make their case, and present changes based on feedback.
The author is fully expected to drive this process. Any OBIPs that have stalled in discussion due to the lack of the author's initiative will be gracefully retired.
Members of the community are expected to participate. It is the individual responsibility for anyone involved in OpenBazaar to leave feedback and participate in forming rough consensus. Failure to participate will be counted as an abstention. Moreover, the feedback phase at least 2 weeks (sometimes more depending on revisions), which is ample time to participate.
Rough Consensus
Rough consensus will be measured according to the following criteria:
- Accept. The proposal is accepted.
- Minor revisions. The proposal requires minor revisions before it can be accepted, but the concept is accepted.
- Reject and resubmit. This should be resubmitted as a new proposal after significant revisions.
- Reject. The proposal is rejected; no amount of revisions will be satisfactory as the concept is fundamentally rejected.
The author should keep a running tally of participant's opinions in the initial post, and edit the post to update it.
Contentious OBIPs
If there is some warm or hot disagreement regarding an OBIP, the discussion should immediately be paused in the issue and an online chat scheduled between both points of view (or representatives of both points of view).
More often than not, issues can be quickly and calmly resolved via a Google Hangout. However, if a compromise solution cannot be reached, a tie-breaking decision will be made by @hoffmabc.
OBIP Acceptance
If an OBIP has found rough consensus for acceptance, then a PR with working and testable code should be made to the openbazaar-go server repo with a title matching the corresponding OBIP for review.
Clients are under no obligation to immediately implement any new features in the protocol, unless it is a coordinated and critical upgrade.
Backwards Compatibility
It is critical that all OBIPs clearly delineate the impact its changes will have on the protocol, server, and clients (desktop, mobile, browser) - if any.
Conclusion
The OBIP process is designed to: 1) bring clarity to how changes in the protocol will be approached going forward, and 2) encourage developers to get involved to expand the utility of OpenBazaar for all users.
The OBIP process will continue to evolve as we learn what works, and what doesn't. Finally, at all times you must communicate with your peers respectfully and objectively. Abuse or assholism will not be tolerated.
[1] An issue will be created to collect simple feature requests that community members can turn into OBIPs.