This is an old revision of the document!
Table of Contents
The OpenChain Specification is available for everyone to review, adopt and to submit suggestions for improvement. You can send questions and feedback to the mailing list or directly the Specification Team Chair, Mark Gisi (Mark.Gisi@WindRiver.com) if you prefer to provide comments anonymously.
The specification Frequently Asked Questions (FAQs) can be found here: Spec FAQs. Answers to the FAQs can help understanding how to interpret the specification.
Past Versions of the Specification
Version 2.0 Changes Over Previous Version 1.2
We recently completed the release of version 2.0 of the specification. You can find the draft with mark up over the previous version (1.2) here:
Contributing to the Specification
Please read the Spec FAQs before contributing. This will provide insight into the principles that have guided past decisions: Spec FAQs. You can join the Specification mailing list and, review and record feedback on the current version of the specification using github issue tracking.
Specification Development/Release Process
For a given version of the specification the development process steps include:
- Hold a kickoff meeting and revisit the Specification Guiding Principles.
- We accept and discuss feedback from anyone who wants to participate either at the working group meetings or on the spec mailing list.
- Currently an annual release cadence is followed (which may change for a given release). Any cadence changes will be announced on the spec mailing list.
- Suggestions are tracked in the specification's github issue tracking list.
- A draft of the accepted modifications and additions are published monthly in an updated draft document.
- Public Comments Period - Six weeks prior to the target release date we circulate a near final version seeking public comments for 30 days. During this period we accept only minor updates such as typos, grammar corrections and wordsmith recommendations that do not change the semantics of the content. We do not accept any material changes during this period. All other feedback and recommendations are queue for consideration during the next version release cycle.
- Freeze Period - Two weeks prior to release we freeze the draft and allow one last review for 14 days. This is to enable everyone to review any changes made during the Public Comments period.
- If a consensus expresses concerns over any changes made during the Public Comments period we would i) make changes to accommodate those concerns followed by ii) an additional 14 day Public Comments period; followed by iii) another 14 day Freeze period. Anyone with significant reservations on the final draft should state their position/concerns via the spec mailing list. The changes will be accepted once we achieve consensus for the final draft.
- In the event we do not have consensus on the final version - we would repeat the following cycle until we have consensus: i) accommodate changes to address majority concerns; ii) 14 day Public Comments period; followed by iii) a 14 day Freeze period cycle.
Translations
Multiple language translations of the specification greatly facilitate adoption. We have a policy document describing the process needed to i) facilitate the creation of official translations and ii) preserve the accuracy and completeness of the specification. Details of of the policy and process are available on the following wiki page
