Template
A Feature Design document template shall be published in a prominent location available to the community (the Feature Requests section of the project wiki). This template shall contain at least the following fields: Title, Author(s) and Affiliation(s), Date Submitted, Feature Scope and signoff, Current Status, User Outcome(s), Sponsor User, Proposed Design, References, and Dependencies. The author(s) shall complete the identified fields in the template, and thus also identify and obtain permission and approval from a Sponsor User, before obtaining sign-off and submitting the proposed Feature Candidate.
...
Before formal submission, the author(s) shall discuss with the TSC Chair or designee to identify the appropriate WG (or the TSC itself for cross-cutting submissions). The author(s) shall meet with the relevant Chair or designee to obtain formal signoff. Once sign-off.
As shown in the flow to the right, this review process is meant to be iterative. The Chair may propose changes, the Author makes updates, and then review begins again. It is possible that this review iteration could take an hour or even a month. The Author should not expect that their job is done once they submit the initial Feature Design document.
Once signoff is obtained, the Chair shall post the Feature Design submission as a Feature Candidate and schedule a presentation for the author(s). The author(s) shall prepare the presentation.
...
All votes shall be held as specified by OH’s Technical Charter. If the Candidate is rejected, the reason(s) for the rejection shall be specified along with any potential remediation efforts that may result in future approval. The Candidate document may be adjusted by the author(s) according to the guidance they received and re-submitted after an interval of no less than three months from the date of the initial rejection. If the Candidate is approved, the Feature Candidate shall be promoted to Feature Design and enter the scope WG’s Feature backlog as an Epic.
...