| Table of Contents |
|---|
| Info |
|---|
The purpose of an OpenMBEE Enhancement Proposal (OEP) is to introduce manage the process of introducing any major change to OpenMBEE. This is required in order to balance the need to support new features, use cases, while avoiding accidentally introducing half thought-out interfaces that cause needless problems when changedand system engineering requirements surrounding product direction. |
What is considered a major change that needs an OEP?
...
What are the "public interfaces" of the project? All of the following are examples of public interfaces that people build around:
TODO
Proposal lifecycle
| Info |
|---|
Prerequisites
If you have trouble accessing any of the above, please contact openmbee [at] gmail [dot] com |
Discuss
Most proposals start with an idea. If you have an idea of how OpenMBEE could improve, we encourage you to send an email to openmbee [at] googlegroups [dot] com with a subject starting with [OEP DISCUSS]. This email thread will allow you to gather early feedback. We encourage you to start a Draft document on this wiki or share a Google Document with the mailing list detailing your proposal. Use the OEP template to provide details on your proposal.
...
| Info |
|---|
For an example of a well documented proposal, see https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-44+Airflow+Internal+API |
...
Review
Once you or someone else feels like there’s a rough consensus on the idea and there’s no strong opposition, you can move your proposal to the Vote review phase. For this you will send a new email to openmbee [at] googlegroups [dot] com with the subject starting with [VOTEOEP REVIEW REQUEST]. In your [VOTEOEP REVIEW REQUEST] email please include links to
the original [OEP DISCUSS] Google Group thread, and
the Draft OEP wiki page you created above
The voting review period has to last at least 72 hours and it’s a good practice to extend this time if most of this period is a weekend. Whole community is encouraged to give +1 or -1 votes. There’s also fractional votes (0.5, -0.99) that allow you to express your view on the discussion without giving an explicit approval/block signal. This means that any vote thumbs up or thumbs down. Any review requires at least 3 , +1 binding votes thumbs up to be recognized as passed. In addition, any -1 binding vote if there are more thumbs down (than thumbs up) then the OEP author(s) will move the proposal OEP Draft back to the Discuss phase in order to address changes. The vote is a consensus-seeking process, “the goal is not to *win* votes or come to a unanimous agreement, but rather to ensure that there’s a forum for people to raise and discuss their concerns, and that nobody feels strongly enough to block the group from moving forward. Consensus-seeking emphasizes discussion over enumeration: *Rough consensus is achieved when all issues are addressed, but not necessarily accommodated.*” (quote from Working in Public: The Making and Maintenance of Open Source Software by Nadia Eghbal)
If you want to introduce significant changes to your proposal after it has been accepted you can do so following the same procedure.
...