Process for Public Comment Periods:

The OpenChain Study Groups and/or Work Groups may submit material for public comment periods from time to time. This is most frequently done during the Process for Developing Standards (see below), but it may be invoked for other purposes. One example is when a guide is being prepared, and wider awareness and commentary is requested from both inside and beyond the OpenChain community.

The generic process for Public Comment Periods is:

• A Study Group or Work Group coordinates with the OpenChain General Manager or other relevant staff to discuss whether a public comment period is required
• If necessary, permission is obtained from the OpenChain Governing Board or Steering Committee
  • As a general rule, outcomes of the Specification Work Group are subject to approval from the OpenChain Governing Board and/or Steering Committee
  • The OpenChain Governing Board generally discusses and approves strategically important matters related to our standards
  • The Steering Committee generally discusses and approves new standards or updates to our standards
  • Other topics, guides and activities throughout the OpenChain Project may be put to the OpenChain Governing Board or Steering Committee if they are deemed to be strategic to the Project vision and mission, or they will directly impact our standards
• A public comment period is subsequently announced with a term to be determined by the Study Group or Work Group in question, or potentially the OpenChain Governing Board or Steering Committee if their approval is involved
• This announcement will contain information on how to contribute to the public comment period for both existing OpenChain Project contributors and the general public
• The Study Group or Work Group announcing the public comment period will then collect feedback for the duration of the comment period. This feedback is generally collected through:
  • The Study Group or Work Group mailing list
  • The Study Group or Work Group GitHub repository or another OpenChain Project GitHub Repository
    • When feedback is obtained through GitHub, it usually takes the form of GitHub Issues being created by commenters
• At the conclusion of the public comment period the issues collected will be addressed by the Study Group or Work Group via their scheduled calls or via their mailing list
• The results of the review of the public comment periods will then be more widely announced via the main OpenChain mailing lists, website or other measures

Process for Developing Standards:

Our vision is a supply chain where open source is delivered with trusted and consistent process management information. Our mission is to make that happen.

The OpenChain Project has an extensive global community of over 1,000 companies collaborating to make the supply chain quicker, more effective and more efficient. As part of this we make specifications that can turn into standards.

Making a new specification is a process with a lot of moving pieces. We scope development as outlined below. Prior to the process below kicking in, ideas around new specifications can be shared via our mailing list if they are tagged as proposals, with the recommendation that they are kept in a coherent thread, and ideally also recorded in GitHub.

We have four guiding principles:

1. 1. Build trust around the open source supply chain.
   2. Remember that less is more:
      — Define the key requirements of a quality program
      — Do this by solving real pain points in the supply chain
   3. Keep our specifications limited to what and why (avoid the how and when)
      — Embrace different implementations to solve challenges
      — Avoid mandating specific process content
   4. Be open to all to participate and contribute

Formal Process:

1. 1. A Work Group may propose drafting a new specification to the OpenChain Steering Committee in the following manner:
   2. A proposal should be drafted that explains the rationale behind the specification to the Steering Committee [written statement]
   3. The proposal should also explain how the activity supports the Project Charter of the OpenChain Project [written statement]
   4. Submit to Steering Committee via a formal Steering Committee meeting held adjacent to the next Board Meeting
   5. Permission granted and formally ratified, or permission denied, or further questions asked at that meeting
   6. If permission is granted, the draft specification can be created.
   7. Hold a community kickoff meeting and revisit the OpenChain Project specification development guiding principles.
   8. Accept and discuss feedback from anyone who wants to participate either at the Monthly Community Calls or on the specification mailing list or the relevant GitHub Repository.
   9. Record feedback through GitHub issues and their comments for the relevant specification. The current practice is usually to have a GitHub Repository dedicated to each specification under development. We do not accept Pull Requests due to requirements to keep copyright ownership limited and allow easy transfer to international standards organizations.
   10. Publish modifications and additions in a draft document contained in relevant GitHub Repository.
   11. Open a Public Comments Period nine months before our target completion date. This runs for 6 months and only accepts minor updates such as typos or grammar corrections that do not change the requirements 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.
   12. Open a Freeze Period three months before our target completion date to allow a 3 month review of any changes made during the Public Comments Period.
   13. If a consensus expresses concerns over any changes made during the Public Comments period we would
       1. 1. make changes to accommodate those concerns followed by
          2. an additional 14 day Public Comments period; followed by
          3. 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.
   14. In the event we do not have consensus on the final version – we would repeat the following cycle until we have consensus:
       1. 1. accommodate changes to address majority concerns;
          2. 14 day Public Comments period; followed by
          3. a 14 day Freeze period cycle.
   15. Send the completed draft specification to the OpenChain Steering Committee for formal review and a vote on whether to accept the community recommendations for an updated or new specification.
   16. In principle, we target updates to our ISO standards once every five years

Please Note: the final decision on content and release of OpenChain Project specifications lies with the OpenChain Steering Committee.

Process for Translating Standards:

We encourage translations of our specifications. However, we want these translations to follow a process to help ensure accuracy.

Policy:

• • All translations are based on the English version, which is are official, normative versions of the OpenChain specifications.
  • There is one official translation for each language.
  • Every translation has one maintainer selected by the OpenChain Project.
  • Translations should be reviewed wherever possible by two or more people to ensure integrity, accuracy and completeness.
  • 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. 1. Propose a translation on the monthly calls, specification mailing list or other official channel like our WeChat group.
   2. Get a copy of the English version of our specification to facilitate the translation:
      OpenChain ISO/IEC 5230:2020 in MarkDown
      OpenChain Security Assurance Specification in MarkDown
   3. Add the proposed translations as an Issue to the License Compliance GitHub Repository or Security Assurance GitHub Repository.
   4. The translation license should be the same as the English original
   5. The translation should also include the following disclaimer:
      • • “This is a translation from the original specification in English. In the event there is confusion between this translation and the English version, The English text shall take precedence.”
   6. The translation will be accepted (or flagged for further review) via GitHub.
   7. It will then be announced on the main mailing list and the specification mailing list.

Process for Depreciating Standards:

1. 1. In principle, all Draft Specifications may find a natural conclusion outside of graduating as an OpenChain Specification, either when it is found unsuitable to address a problem in our domain, or when it is determined that their work is best carried out elsewhere
   2. If such a situation is identified, the relevant chair or GM should explain the rationale [written statement]
   3. This would be submitted to the Steering Committee via a formal Steering Committee meeting held adjacent to the next Board Meeting
   4. Permission granted and formally ratified, or permission denied, or further questions asked at that meeting
   5. If permission is granted, the draft specification would wind down or transfer elsewhere

Process for Forming New Study Groups:

Note based on previous board discussion: It is suggested that new study groups remain relatively easy to form, to ensure new ideas can be examined and relevance to market easily maintained.

• • A proposal should be drafted that explains the rationale behind the new group to the governing board [written statement]
  • The proposal should also explain how the activity supports the mission of the OpenChain Project [written statement]
  • Submit to board via GM
  • Board permission granted against a certain time period [one week via email to the board] with or without questions, and formally ratified at the [next board meeting]

Process for Forming New Work Groups:

Note based on previous board discussion: It is suggested that Work Groups have a higher barrier to entry than previously, to ensure they are working on solutions that conclusively support our project charter.

• • In principle, new Work Groups should be formed from existing Study Groups
  • A Work Group should be designed to take the conversation outcome of a Study Group, and implement a solution based on that outcome
  • A proposal should be drafted that explains the rationale behind the new group to the governing board [written statement]
  • The proposal should also explain how the activity supports the Project Charter of the OpenChain Project [written statement]
  • This would be submitted to the OpenChain Governing Board via the board mailing list
  • Board permission granted against a certain time period [two weeks] with or without questions, and formally ratified at the [next board meeting]

Process for Winding Down Study Groups or Work Groups:

• • In principle, all Study Groups and Work Groups may find a natural conclusion, either when their mission is complete, or when it is determined that their work is best carried out elsewhere
  • If such a situation is identified, the relevant chair or GM should explain the rationale [written statement]
  • This would be submitted to the OpenChain Governing Board via the board mailing list
  • Board permission granted against a certain time period [one week via email to the board] with or without questions, and formally ratified at the [next board meeting]

Process for OpenChain Study and Work Group Elections:

This process currently applies to:

• • OpenChain Specification Work Group
  • OpenChain Education Work Group
  • OpenChain Telco Work Group

The Overall Process:

• • The OpenChain Governing Board formally considers who should be appointed as the chairperson for the relevant OpenChain Study or Work Group, and invites the broader OpenChain community to provide their perspective;
  • In this process, the broader OpenChain community will have nominees proposed and voted on to provide a recommendation;
  • That recommendation will be passed to the OpenChain Governing Board for review, approval and ratification at their next meeting.

Election Process:

• • The specific process on behalf of the community is to undertake a voting process after a period of nomination;
  • The nomination period is one week;
  • The voting period is one week;
  • If a single candidate stands, they automatically win;
  • If two or more candidates: simple majority wins;
  • Simple majority = 50%+1 or more, of the votes cast;
  • Run-off will take place if:
    1. 1. If there are more than 2 candidates and no one receives a simple majority, or
       2. There a tie between the top 2 candidates.
  • The run-off will be among the 2 candidates who received the most votes;
  • If the run-off results in another tie, then the Governing Board Chair will cast an additional deciding vote:
  • The relevant work group or study group chair to be confirmed at subsequent board meeting;
  • The Governing Board reserves the right to make any determination they regard as appropriate.

Nomination Methods:

The community can nominate in the following manner:

• • Members of the relevant@ (example: specification@lists.openchainproject.org) mailing list are entitled to be nominated as chair.
  • Members of main@ are entitled to join relevant@ and take part in the election.
  • You can nominate yourself by sending an email to the relevant@ mailing list.
  • You can nominate someone else by sending an email to the relevant@ mailing list (but please make sure they are ok with it first).

Process for Governing Board Elections:

• • Term: 3 years;
  • Election: Self-nomination;
  • Nomination period: four weeks in advance of board meeting;
  • Voting period: three weeks in advance of board meeting;
  • Voting takes place by email to General Manager and the current Chair;
  • Candidate numbers required: one or more is valid;
  • Voting finished two weeks advance of board meeting (no vote = automatic acceptance if one candidate);
  • General Manager and Chair independently tally and confirm the votes;
  • The results are reported anonymously with only the elected member’s name reported;
  • Voting validity if two or more candidates: simple majority wins;
  • Simple majority = 50%+1 or more, of the votes cast;
  • Run-off will take place if:
    1. 1. If there are more than 2 candidates and no one receives a simple majority, or
       2. There a tie between the top 2 candidates.
  • The run-off will be among the 2 candidates who received the most votes;
  • If the run-off results in another tie, then the Board Chair will cast an additional deciding vote;
  • Chair to be confirmed at subsequent board meeting.

Process for Partner Applications:

• This process for partner application is designed to encourage organizations of all sizes to consider participation.
• Applicants should prepare a three slide (or more) deck and email it to our helpdesk.
  • This should explain their organization,
  • what services they plan to offer, and
  • how they intend to engage with the OpenChain community outside of products or services – this usually takes the form of helping with the development of reference material, providing outreach and promotion for our standards and work, and/or providing space for community meetings or events.
• Their application will then go before the OpenChain Governing Board.
• Approval, rejection or requests for more information are usually provided within two weeks.