...
| # | Stage | Activity | Exit Criteria |
|---|---|---|---|
| 1 | Initiation | Introduce members; agree on vision, mission, scope, process, tools, and schedule | Consensus on vision, mission, scope, process, tools, and schedule |
| 2 | Problem Definition | Stakeholders propose use cases to build a map of what problems they need to solve for whom | Consensus on the problem map |
| 3 | Requirements | Extract and enumerate specific requirements from the problem map | Consensus on requirements |
| 4 | Design Principles | Develop the principles that should guide/govern design of the solution | Consensus on design principles |
| 5 | Proposals | Members submit proposed solution designs | No further proposals |
| 6 | Consolidation | Members identify common elements and seek to develop a consolidated proposal | Consensus on contents of first Working Draft |
| 7 | Working Drafts † | A cycle of publishing Working Drafts, raising and resolving issues, and agreeing on revisions | Consensus on first Implementers Draft or Public Review Draft |
| 8 | Implementers Drafts | OPTIONAL for technical specifications where implementation feedback is desired prior to finalization. | Sufficient Consensus that sufficient implementation feedback has been received |
| 9 | Public Review Drafts | Same as Working Draft stage except with public review | Consensus (or vote) on WG Approved Draft |
| 10 | WG Approved Draft † | WG decision to submit for SC approval | Consensus (or vote) to submit for SC approval |
| 11 | ToIP Approved Draft † | SC decision to approve as ToIP Deliverable | Consensus (or vote) to approve |
...
It is understandable that many WGs or TFs (collectively, "groups") may want to get " right to work", i.e., pick up the pen and start drafting. Some may even be have been started based on a contributed document or specification. However we strongly recommend that the group still take the time to deliberately go through stages 1 through 6 in order to make sure all group members are aligned and working from the same conclusions about the mission, scope, problem definition, and requirements. It is also highly recommended that all group members have the opportunity to present their own proposed solutions. This is the best way to build towards consensus in the Consolidation stage prior to formally commencing Working Drafts.
...
<TODO: description or pointer to another wiki pages page which explains which templates to use for Google docs/MS Word and GitHub and how to set them up>
...
If a deliverable is a technical specification, it is recommended to follow the IETF dictum of "rough consensus and running code", i.e., to provide evidence of completeness by demonstrating multiple interoperable implementations. The best way to do this is to publish at least one Implementers Draft that developers can actively use follow to implement and provide feedback on. Depending on the complexity of the spec, more than one version of the Implementers Draft may be published, and the cycle will typically last at least few months, or even a year or more.
...
If a deliverable is not a technical specification—or if the working group (or task force - Working Group or Task Force (either can trigger a public review draft) feels it has received sufficient implementation feedback—then the working group (or task force) Working Group or Task Force MUST hold a public review of at least 15 days (30 to 60 days is RECOMMENDED) before the deliverable can be submitted for Working Group approval. During this public review period:
...
Once the public review is complete and the groups Working Group or Task Force has responded to all issues raised, the deliverable is ready to be submitted to the Working Group for approval as a Working Group Approved Draft. This approval MUST be given either via:
- A formal call for consensus at a regularly scheduled meeting of the Working Group at for which at least one week's notice has been given of the planned vote, OR
- An email call for consensus sent to the Working Group's mailing list that allows at least seven days for any WG member to reply with an objection.
If no objections are received via either method of calling for consensus, the deliverable is approved. If either a call for consensus receives an objection which cannot be resolved via discussion, then the Working Group must hold a formal ballot ( following the same rules above. To be approved at a meeting of the Working Group, a majority (51%) of Working Group members present MUST vote in favor of approving the deliverable. To be approved via an email ballot, a majority (51%) of Working Group members on the mailing list MUST vote in favor of approving the deliverable.
...
Once a deliverable is approved as a Working Group Approved Draft, the Working Group MAY elect to submit it the deliverable to the ToIP Steering Committee for approval as a ToIP Approved Draft.
...
If consensus is not achieved, the Steering Committee MUST hold a formal ballot. To be approved, a majority of Steering Committee members MUST vote in favor of approving the deliverableFormal ballot rules for an SC vote follow the same rules as for a WG vote.