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.

OpenChain Specification 2.0

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

Next Draft Version 2.1

You can find the current draft version here:

Contributing to the Specification

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 Process

For a given version of the specification the development process steps include:

  1. Hold a kickoff meeting and revisit the Specification Guiding Principles.
  2. We accept and discuss feedback from anyone who wants to participate either at the working group meetings or on the spec mailing list.
  3. 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.
  4. Suggestions are tracked in the specification’s github issue tracking list.
  5. A draft of the accepted modifications and additions are published monthly in an updated draft document.
  6. 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.
  7. 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.
  8. 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.
  9. 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 Of The Standard

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.

Policy

  • There is one official translation for each language.
  • All translations are based on the English version.
  • Every translation has one maintainer selected by the OpenChain Project.
  • Translations should be reviewed by two or more people to ensure integrity, accuracy and completeness.
  • Both reviewers sign off on a translation to confirm it is complete.
  • Translations are made under the terms of the license of the material being translated.
  • Translation version numbers must correspond to the official English version it is based on.

Translation Checklist

  1. Receive nomination to perform translation via the main OpenChain mailing list. If approved by the Specification Work Team Chair then precede to complete the remaining steps.
  2. Obtain names of maintainer and reviewer(s). Add them to the translation page listing for the given language
  3. Direct all translation related discussions to the specification mailing list. Maintainer and reviewer will need to join this list:
  4. Maintainer obtains a MS Word or ODT copy of the English version to facilitate the translation:
  5. Create a github repository and assign maintainer admin access. If you are not familiar with Github we will assist you in checking in your work product files and creating the additional required files prior to the release of the translation.
    • The maintainer should include a CONTRIBUTORS.md file in the top directory that lists all the contributors.
    • The maintainer should include a License file should be the same as the version of the English spec being translated.
  6. Submit final version for review in pdf format to the specification mailing list for review. This review is largely about the formatting.
    • The following disclaimer must be included in English and the translated language above the copyright and license notices found on page 2: “This is an official translation from the OpenChain Project. It has been translated from the original English text. In the event there is confusion between this translation and the English version, The English text shall take precedence.”
  7. Once the formatted version is approved: send maintainer and reviewers formal email sign off requests via the specification mailing list. This sign off is largely about ensuring the translation content accurately and completely represents the text found in the English version.
  8. Obtain sign offs from maintainer and reviewer(s).
  9. Post translated pdf version to the OpenChain Translation web page. It should also be stored in the github repo.
  10. Announce the availability of the translated version on the main OpenChain mailing list