What is considered a major change that needs an OEP?

Any of the following should be considered a major change:

...

What are the "public interfaces" of the project? All of the following are examples of public interfaces that people build around:

...

• Major (possible backwards incompatible breaking) changes to MMS REST Endpoints

• A brand new authentication mechanism

• Major changes to the core MMS data model

• Fundamental changes to OpenMBEE clients e.g., View Editor layout/aesthetics, Cameo comparability/interoperability, etc.

• Entire OpenMBEE website redesign

Proposal lifecycle

Image Added

Step 1 - 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 draft OEP template below to provide details on your proposal.

Step 2 - Draft

Anyone is welcome to propose a new improvement to OpenMBEE. You will need to request edit access to the Confluence page in order to create your OEP document. You can do so by sending an email with details to openmbee [at] gmail [dot] com and request permission.

...

Step 3 - 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.

Step 4 - Accepted

🥳 Congratulations! 🥳

Your proposal has been accepted. Next up is breaking down tasks. You should break down tasks on one or more of the OpenMBEE repository issue trackers. You are strongly advised to group the tasks together in a Github Project if it consists of multiple steps and you want to be able to track progress for its implementation or share the progress with others. Once issues are created, it helps if you can tag them with the relevant OEP-Xlabel for your OEP. If you need help with this then you can contact an existing OpenMBEE developer.

Now you can start contributing and - more importantly - you can , and probably should, encourage others to contribute to your project. However this is optional and up to your discretion. Again, you OEP. You can learn how to contribute and communicate  by communicate by reading the Contributing guide in the OpenMBEE GitHub Organization. Use your imagination and various communication channels for ways to encourage people if you do not already have contributors following your idea. It is advisable that several people work on the OEP so that the knowledge is shared.

Step 5 - Completed

You should move your OEP to complete after you consider the main bulk of work has been merged to the repository. It is okay to leave open issues for minor follow up tasks like adding additional capabilities or similar. 

Step 6 - Abandoned

An OEP may be moved to abandoned if there has been no owner or

• the original proposer(s) decide to abandon it, or

• there is no intention of developing it further for

...

• no more than 3 months.

Either of these can happen if the creator decides proposer(s) decide to refactor one OEP into a new OEP for example or i.e., if there is a proposal that supersedes the original OEP.

Acknowledgements/Credits

This guide is adapted from the https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals created by the Apache Airflow community. Kudos!

OEP Maintenance

This documents relevance, utility and maintenance is a responsibility shared by all OpenMBEE community members. If you see something wrong, or you wish to propose changes, then please do so by getting in touch with the community.