Clarify the process of setting up a new working group under ORAS

[toddysm]

We need a clarification of the process for creation of a working group under ORAS. The GOVERNANCE.md specifies how maintainers are added but it doesn't specify how subprojects (WGs/repos) are created. We need to have the following answered:

• How a proposal for WG should be submitted?
• How is the proposal accepted? Who needs to approve the proposal to be accepted? Project maintainers? How many votes? Or just community? How many votes?
• What is the criteria for approval of a WG? Does this fit into the project chapter?
• What is required for the WG? New repo?
• How are maintainers for the WG (and new repo) selected?
• What happens if maintainers in the WG do not participate in the WG? How maintainers are removed from the WG?

There may be others but let's have the discussion in this issue.

[SteveLasker]

minor nit, you're mixing "working group" and "sub-project" terminology. Can we consolidate on "sub-project" as the term?

[SteveLasker]

Thanks, @toddysm
The existing GOVERNANCE: ORAS Org Owners covers who is responsible for adding new sub-projects:

• Deciding what subprojects are part of the ORAS project
• Deciding on the creation of new subprojects

I've added #36 to clarify the existing sub-projects, which is needed regardless. See issue #23

If we agree to merge that file, we can then define the process to add sub-projects to be opening a PR to that file, asking the ORG maintainers to approve.

There's yet another step that would need to define who are the sub-project maintainers.

This following entry suggests ORAS org owners would approve sub-project maintainer changes. Although we should add text to be more explicit.

When a subproject has no owners the ORAS org owners become responsible for it and may archive the subproject or find new owners

[toddysm]

I may need some clarification about what the definition of a subproject is. It may be matter of semantics but for me the output from the workgroup may (or may not) result in sub-project(s) work. My understanding of the purpose of the WG is to investigate the space and specify what needs to be done. While sub-project for me is the place where the "what needs to be done" is done - either a spec or code :) This may be done in the existing sub-projects like the ORAS CLI and the Distribution on in a completely new one if that is needed.

Also, the GOVERNANCE document specifies that the sub-project (not the WG:)) needs to fit into the Vision of ORAS. An outcome from the WG group may be that this something does not fit in the Vision of the project. I looked around and couldn't find a Vision document (the question I brought up in the meeting yesterday although I used the term Charter).

There is still open the question of how the maintainers for the subproject (or WG) are selected. This seems unclear to me from the governance point of view. Also, bearing in mind that for the current proposal none of the folks interested (except you) have any formal role in the ORAS project.

Just some of the questions popping in my mind while thinking about this.

[toddysm]

I would propose the following as a process to create a working group under the ORAS project:

---

Purpose of an ORAS Working Group

ORAS may establish one or more working groups (each, an “ORAS Working Group”) to experiment, validate, and define new capabilities of specifications. Each ORAS Working Group shall have a defined scope of the ORAS Working Group's intended activities and goals. The end result of the ORAS Working Group's work product shall be either:

• an update to an existing specification (for example, adding support for a new set of features);
• a new specification (for example, creating an specification for a new topical area); or
• a new ORAS sub-project other than a specification (for example, creating a reference implementation of an specification).

Any participant in the ORAS technical community may propose a working group to the maintainers. Participants can become maintainers of the Working Group. The maintainers shall maintain a public list of the information required to be included in a working group proposal.

Required information for ORAS Working Group Proposals

ORAS Working Group proposals should contain the following information:

• a clearly defined objective and scope of what the working groups aims to accomplish
• a list of owners who have agreed to participate in the working group, review progress, report progress back to the ORAS community, and present the results to the maintainers once the working group has completed its objectives
• a list of ORAS Projects, non-ORAS projects, or organizations sponsoring the working group and participating in the implementation and use case validation of the work done by the group
• a set of project rules which govern how contributions to the working group will be handled and decisions will be made
• a working agreement for making progress, which may include weekly meetings, dedicated channels for discussions, or a shared repository
• a request for ORAS resources, which may include recurring meetings in the ORAS calendar, ORAS hosted repository, or topic specific communication channels
• a name of the working group
  Note: It is recommended that the working group is clearly differentiated from the sub-projects by using "Working Group" in the name and wg- prefix for the designated repository if such is required

Proposal for an ORAS Working Group should be submitted as an issue with all the information above.

Requirements for maintainers approval of the working group

ORAS maintainers should review the proposal for a working group and vote for its creation. Working groups can be approved with a super-majority of the maintainer votes. Once the approval is complete, maintainers will provide the requested resources to the working group participants.

Required information for maintainers approval of the working group outcome

When an ORAS Working Group determines that it has completed its initial work and is prepared to request maintainers approval for the outputs as a specification or a sub-project for ORAS, the ORAS Working Group owners will present to the maintainers the following:

• the recommended next steps, draft specification, or project content
• the validation work which demonstrates real world usability
• the set of maintainers who have agreed to carry the work forward

There is no requirement that owners or contributors to the ORAS Working Group will continue to be maintainers for an approved specification or other ORAS sub-project after maintainers approval and release. However, the maintainers will consider it a requirement that any approved specification or other ORAS sub-project has a dedicated and active group of maintainers to continue the work.

---

I would be happy to submit a PR to add to the governance if the maintainers are in a agreement.
@sajayantony, @shizhMSFT, @SteveLasker, @deitch, @jdolitsky

[sajayantony]

Thanks @toddysm. I'm in support of documenting this and would welcome a PR. This also helps WG maintainers exit or become maintainers once the proposal is done. Enables a good timeboxed focused effort and an opportunity to include more experts from the community.

I would also like to highlight the challenges that the OCI working group had and even though the full recommendation was not accepted it did land major portions of it. It enabled a lot of members to show up and bring in participation from the community on the specific topic rather than the issues of the whole project that might not apply to WG use cases.

+1 on seeing this governance proposal on ORAS.

[shizhMSFT]

LGTM. I'm glad to see new working groups to experiment and explore new areas for oras.

[FeynmanZhou]

LGTM. Adding two new org owners @TerryHowe @sabre1041. Do you have any comments about @toddysm's proposal?

[TerryHowe]

LGTM, do you want to make a PR out of this?