Processes - OpenChain

Need Immediate Help?

What Do You Want To Know?

Process for Developing Standards
Process for Translating Standards
Process for Forming New Study Groups
Process for Forming New Work Groups
Process for Winding Down Study Groups or Work Groups
Process for OpenChain Study and Work Group Elections
Process for Governing Board Elections

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:

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

Formal Process:

Hold a community kickoff meeting and revisit the OpenChain Project specification development guiding principles.
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.
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.
Publish modifications and additions in a draft document contained in relevant GitHub Repository.
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.
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.
If a consensus expresses concerns over any changes made during the Public Comments period we would
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.
In the event we do not have consensus on the final version – we would repeat the following cycle until we have consensus:
1. accommodate changes to address majority concerns;
2. 14 day Public Comments period; followed by
3. a 14 day Freeze period cycle.
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.
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:

Propose a translation on the monthly calls, specification mailing list or other official channel like our WeChat group.
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
Add the proposed translations as an Issue to the License Compliance GitHub Repository or Security Assurance GitHub Repository.
The translation license should be the same as the English original
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.”
The translation will be accepted (or flagged for further review) via GitHub.
It will then be announced on the main mailing list and the specification mailing list.

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. 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. 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.