OFEP0: OpenFlexure Enhancement Proposals

OFEP	0
Author	Julian Stirling
Created	14-Nov-2020
Status	Approved
Type of OFEP	Governance
Approved date	2-Dec-2020
Requires implementation	No
Implemented date	N/A
Updated dates (post-approval)	N/A

Following the model of Python where important changes are first proposed as Python Enhancement Proposals (PEPs). This is designed to provide a concise technical description of enhancements and the rationale for the feature.

1. Why OFEPs?

As we move forward from an purely academic project to a project that manufacturers can build into a product we need to layout design rationale more clearly. This does not replace good commit messages, this does not replace issue and merge request discussions, these are all important parts of the project history. The OFEPs, however, will provide more detailed clarity on important changes and will remain as technical documentation for those who wish to understand a specific aspect of the project.

2. Process

1. New OFEPs, or amendments to existing OFEPs, should be proposed (by anyone) as merge requests using the template in the templates folder. Copy this into a new folder named OFEP9999 and leave the number as 9999 in the document until merge is approved. A merge can be opened partially formed to allow others to participate in its formation.
2. Discussion will happen in this merge request thread.
3. A meeting date will be set with at least 1 weeks notice given. All members of the core development team and steering committee will be invited.
4. The core development team and steering committee will meet to decide whether to approve the changes. If there is significant interest in the OFEP from those external to the core team they will be invited to this meeting.
5. The meeting will be deemed quorate if there are at least two members of the steering committee in attendance and at least 2 members of the core development team in attendance. Any members of the core development team or steering committee who cannot attend are able to submit a vote by appointing another member as a proxy to vote on their behalf.
6. Any votes taken during the meeting are deemed to have passed by a simple majority of both the core development team and the steering committee. Tied votes don't pass. Any governance OFEPs such as this OFEP require a two-thirds majority of the steering committee for approval.
7. During the meeting a vote can be called to either
   • Approve the OFEP
   • Reject the OFEP
   • Delay the OFEP pending changes.
8. If approved, any final minor edits will be applied to the text.
9. The OFEP number will then be assigned and the Status will be changed to Approved, and the approval date set.
10. If the OFEP requires specific code changes (some may be simply informative, or guidance for future direction). The status will be changed to Approved, not implemented
11. Once implemented in the relevant repository a new merge request can be opened. This should set the implemented date and change the status to Approved and implemented
12. This merge request will be discussed on GitLab before merging. Unless there is significant disagreement on the implementation this should not need a meeting for approval.