...

† Stages officially recognized in the Linux Foundation Joint Development Foundation process: "Pre-Draft", "Draft", "Working Group Approved", and "ToIP Approved" deliverable. 

Stages 1 thru 6 (Prior to Working Drafts)

...

1. Contact your Working Group chair(s) or Michelle Janata, ToIP Program Manager ,or Judith Fleenor, ToIP Executive Director, for assistance in setting up the GitHub repo you will need for managing your deliverable.
2. See <TODO—add link>these instructions<end-link> which explain how to set up your repo and begin using the ToIP Markdown Template for your deliverable.

Working Draft Subtitle and Versioning

Regardless of whether Google Docs or GitHub Markdown is used, the document should carry the subtitle "Working Draft" followed by a two-digit number representing the Working Draft version, starting with 01. For example: "Working Draft 01", "Working Draft 02", "Working Draft 03", etc.

Stage 8: Implementers Drafts (Optional)

...

Note that explicitly labeling a specification as an Implementers Draft sends a clear signal that the spec is ready for implementation feedback—and that the group values that feedback before the spec goes final.

Implementers Draft Subtitle and Versioning

The document should carry the subtitle "Implementers Draft" followed by a two-digit number representing the Implementers Draft version, starting with 01. For example: "Implementers Draft 01", "Implementers Draft 02", "Implementers Draft 03", etc. The Implementers Draft version numbering is entirely independent of the Working Draft version number. For example, your group could transition from "Working Draft 07" to "Implementers Draft 01".

Stage 9: Public Review Drafts

Before a Working Draft or Implementers Draft can be submitted for approval as a Working Group Approved Draft, it MUST be subject to at least one public review of at least 15 days (30 to 60 days is RECOMMENDED). Either a Working Group or Task Force can trigger a public review draft. If the deliverable is a technical specification, it is RECOMMENDED to wait until the group has received sufficient implementation feedback. For any other deliverable, it is up to the group to decide when the deliverable is ready for public review.

Guidelines:

1. The document MUST carry the subtitle "Public Review Draft" followed by a two-digit number representing the Public Review Draft version, starting with 01. For example: "Public Review Draft 01", "Public Review Draft 02", "Public Review Draft 03", etc. The Public Review Draft version numbering is entirely independent of the Working Draft or Implementers Draft version number. For example, your group could transition from "Working Draft 11" to "Implementers Draft 02" to "Public Review Draft 01".
2. The deliverable MUST be posted to a ToIP GitHub repo (even if it is a PDF of a Google doc or Word doc).
3. The public review process MUST use GitHub Issues.
4. All feedback from non-ToIP members MUST use the Feedback license as specified by the Joint Development Foundation.
5. The group MUST publish a ToIP blog post announcing the public review, explaining the background and purpose of the deliverable, and providing instructions on how anyone (both ToIP members and non-members) can provide feedback during the public review period. See this wiki page for guidance on writing the blog post.
6. The ToIP Working Group Chair or Executive Director MUST send a notice of the public review, including a synopsis of the deliverable and a link to the blog post, to the ToIP All-Members mailing list and to the ToIP Steering Committee.
7. The official Public Review period MUST begin no earlier than the day the blog post is published and the email is sent.
8. The group MUST process all feedback received by either incorporating it into the deliverable or explaining why it was not incorporated by posting one or more responses to the GitHub issue.
9. If feedback is incorporated into the deliverable, the group MAY decide to hold one or more additional rounds of public review. If so, those additional rounds MUST follow the same rules as the first one.

...

1. A meeting of the Working Group for which at least one week's notice has been given of the planned call for consensus, OR
2. An email sent to the Working Group's mailing list that allows at least seven days for any WG member to reply with an objection. This email MUST state:
   1. The formal name for the deliverable which MUST conform to these requirements.
   2. A link to the final Working Public Review Draft to be approved. This MUST be a link to the WG or TF GitHub repo. If the deliverable is a Google doc or Word doc, that doc MUST be posted to the repo as a PDF. Otherwise, it MUST be a link to the Markdown document.
   3. A synopsis of the deliverable (which can be the same as the synopsis for the public review).
   4. A link to the blog post announcing the public review.
   5. A link to a GitHub issue that summarizes the resolution of all feedback received during the public review process.
   6. A link to this wiki page explaining the deliverable process.
   7. A call for consensus stating: "This is a formal call for consensus of the members of the <name of WG> for approval of <name of deliverable> at <link to final Working Public Review Draft> as a Working Draft Approved Deliverable."
   8. Instructions stating that any WG member who wishes to object MUST respond to the email publicly stating their objection, and that if no objections are received in seven calendar days, the deliverable shall be approved.

...

If consensus is not achieved, the Steering Committee MUST hold a formal ballot. Formal ballot rules for an SC vote follow the same rules as for a WG vote.

Key Process Flows

The following diagrams are intended to help understand the process by which the various deliverables move through the JDF and ToIP deliverable processes.

High-Level

The LF/JDF system recognizes the following deliverables:

• Draft Deliverable
• Working Group Approved Deliverable 
• ToIP Approved Deliverable

The "Pre-Draft" stage does not form a deliverable yet, but the stage is critical in forming a deliverable. 

Image Added

Draft to Working Group Approved

This is the workflow that has the longest period of work - both technically and socially.

Workflow Diagram

It is all about getting the deliverable into a formal state. Depending on the deliverable type this process may be relatively lightweight (e.g. whitepaper) or very heavyweight (e.g. specification). 

Image Added

Working Group Approved to ToIP Approved

Image AddedImage Removed