From 3f40ed8d37065603017b1bf7c6d78c363be06569 Mon Sep 17 00:00:00 2001 From: Feynman Zhou Date: Fri, 17 Mar 2023 17:54:43 +0800 Subject: [PATCH 1/5] add definitation and process of WG Signed-off-by: Feynman Zhou --- governance/GOVERNANCE.md | 46 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/governance/GOVERNANCE.md b/governance/GOVERNANCE.md index daf1621..917d4fd 100644 --- a/governance/GOVERNANCE.md +++ b/governance/GOVERNANCE.md @@ -76,6 +76,51 @@ New ORAS owners participate in an onboarding period during which they fulfill al The onboarding period is intended to ensure that the to-be-appointed owner is able/willing to take on the time requirements, familiar with ORAS core logic and concepts, understands the overall system architecture and interactions that comprise it, and is able to work well with both the existing owners and the community. +## Working Groups + +Working Groups are primarily used to facilitate topics of discussion that are in scope for ORAS but that cross multiple sub-projects and teams. It provides a formal avenue for disparate teams or groups to collaborate around a common problem, craft a balanced position, and disband. + +The Working Group does not own any code. To create a Working Group in the ORAS community, organizers should have a clear goal measured through a specific deliverable or deliverables. Working Group is temporary in nature and will be eventually disbanded after reaching its stated goal(s). + +### Purpose of establishing ORAS Working Group + +Establishing an ORAS Working Groups enables the ORAS community to experiment, validate, and define new capabilities of specifications. Each Working Group shall have a defined scope of the ORAS Working Group's intended activities and goals. The end result of the 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 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 Proposal + +An ORAS Working Group proposal 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 a Working Group should be submitted as a GitHub 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 a 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 Working Group owners will present to following content to the ORAS maintainers: + +- 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. + ## Decision Making at the ORAS org level When owners need to make decisions there are two ways decisions are made, unless described elsewhere. @@ -101,6 +146,7 @@ This ORAS project has adopted the [CNCF Code of Conduct](https://github.com/cncf ## Attributions * This governance model we created using both the [SPIFFE](https://github.com/spiffe/spire/blob/main/MAINTAINERS.md) and [Helm](https://github.com/helm/community/blob/main/governance/governance.md) governance documents. +* The Working Group model we created above references the practice from [OCI Working Groups](https://github.com/opencontainers/tob/blob/main/WG-INFO.md) and [Kubernetes Working Group Formation and Disbandment](https://github.com/kubernetes/community/blob/master/committee-steering/governance/wg-governance.md). ## DCO and Licenses From 84a21a07c467077363959b768bfad266263e5e45 Mon Sep 17 00:00:00 2001 From: Feynman Zhou Date: Sat, 1 Apr 2023 01:00:55 +0800 Subject: [PATCH 2/5] add WORKING-GROUP.md Signed-off-by: Feynman Zhou --- governance/GOVERNANCE.md | 46 ++-------------------------- governance/WORKING-GROUPS.md | 59 ++++++++++++++++++++++++++++++++++++ 2 files changed, 61 insertions(+), 44 deletions(-) create mode 100644 governance/WORKING-GROUPS.md diff --git a/governance/GOVERNANCE.md b/governance/GOVERNANCE.md index 917d4fd..64c633d 100644 --- a/governance/GOVERNANCE.md +++ b/governance/GOVERNANCE.md @@ -78,48 +78,7 @@ The onboarding period is intended to ensure that the to-be-appointed owner is ab ## Working Groups -Working Groups are primarily used to facilitate topics of discussion that are in scope for ORAS but that cross multiple sub-projects and teams. It provides a formal avenue for disparate teams or groups to collaborate around a common problem, craft a balanced position, and disband. - -The Working Group does not own any code. To create a Working Group in the ORAS community, organizers should have a clear goal measured through a specific deliverable or deliverables. Working Group is temporary in nature and will be eventually disbanded after reaching its stated goal(s). - -### Purpose of establishing ORAS Working Group - -Establishing an ORAS Working Groups enables the ORAS community to experiment, validate, and define new capabilities of specifications. Each Working Group shall have a defined scope of the ORAS Working Group's intended activities and goals. The end result of the 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 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 Proposal - -An ORAS Working Group proposal 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 a Working Group should be submitted as a GitHub 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 a 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 Working Group owners will present to following content to the ORAS maintainers: - -- 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. +Working Groups are organizations responsible for the design and implementation of large architectural aspects of the overall ORAS project. See [WORKING-GROUPS](./WORKING-GROUPS.md) for details. ## Decision Making at the ORAS org level @@ -145,8 +104,7 @@ This ORAS project has adopted the [CNCF Code of Conduct](https://github.com/cncf ## Attributions -* This governance model we created using both the [SPIFFE](https://github.com/spiffe/spire/blob/main/MAINTAINERS.md) and [Helm](https://github.com/helm/community/blob/main/governance/governance.md) governance documents. -* The Working Group model we created above references the practice from [OCI Working Groups](https://github.com/opencontainers/tob/blob/main/WG-INFO.md) and [Kubernetes Working Group Formation and Disbandment](https://github.com/kubernetes/community/blob/master/committee-steering/governance/wg-governance.md). +This governance model we created using both the [SPIFFE](https://github.com/spiffe/spire/blob/main/MAINTAINERS.md) and [Helm](https://github.com/helm/community/blob/main/governance/governance.md) governance documents. ## DCO and Licenses diff --git a/governance/WORKING-GROUPS.md b/governance/WORKING-GROUPS.md new file mode 100644 index 0000000..d7b0cbb --- /dev/null +++ b/governance/WORKING-GROUPS.md @@ -0,0 +1,59 @@ +# Working Groups + +Working Groups are organizations responsible for the design and implementation of large architectural aspects of the overall ORAS project. Working Groups operate with a fair amount of autonomy within the broader scope of the project. They tend to be long-lived or temporary. + +Working Groups are primarily used to facilitate topics of discussion that are in scope for ORAS but that cross multiple sub-projects and teams. It provides a formal avenue for disparate teams or groups to collaborate around a common problem, craft a balanced position, and disband. + +Generally, Working Groups could be created once sufficient community interest and discussion has occurred that there is general agreement that: + +- The problem or feature space is interesting and is worth long-term investment by the ORAS community +- The problem or feature space is not well-covered by any of the existing subprojects or Working Groups +- The problem or feature space is in the scope of ORAS charter but there is not standard solution in the industry yet. It is an innovation work that requires early research and investigation across different organizations + +## Purpose of establishing ORAS Working Group + +Establishing an ORAS Working Groups enables the ORAS community to experiment, validate, and define new capabilities of specifications. Each Working Group shall have a defined scope of the ORAS Working Group's intended activities and goals. The end result of the 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 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 Proposal + +An ORAS Working Group proposal should contain the following information: + +- a charter with mission, goals, 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 a Working Group should be submitted as a GitHub 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 a 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 Working Group owners will present to following content to the ORAS maintainers: + +- 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. + +## Dissolving a working group + +Some Working Groups are ephemeral or naturally reach the end of their useful life. Working Group owners can choose dissolve their Working Groups by submitting an issue in the ORAS community repository. The ORAS [Owners](../OWNERS.md) takes ownership to handle their request and ORAS Owners also reserves the right to dissolve or recharter working groups over time as necessary, though they will strive to first discuss this in committee meetings and open community discussion. + +## Attributions + +The Working Group model we created above references the practice from [OCI Working Groups](https://github.com/opencontainers/tob/blob/main/WG-INFO.md), [Knative working group processes and guidelines](https://github.com/knative/community/blob/main/mechanics/WORKING-GROUP-PROCESSES.md) and [Kubernetes Working Group Formation and Disbandment](https://github.com/kubernetes/community/blob/master/committee-steering/governance/wg-governance.md). +,m \ No newline at end of file From c3a9951e74ccb9793b7fd71ff2911f7880c5ad1d Mon Sep 17 00:00:00 2001 From: Feynman Zhou Date: Tue, 25 Apr 2023 23:13:10 +0800 Subject: [PATCH 3/5] doc: add differences between subproject and WG Signed-off-by: Feynman Zhou --- governance/WORKING-GROUPS.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/governance/WORKING-GROUPS.md b/governance/WORKING-GROUPS.md index d7b0cbb..208b7f6 100644 --- a/governance/WORKING-GROUPS.md +++ b/governance/WORKING-GROUPS.md @@ -53,6 +53,14 @@ There is no requirement that owners or contributors to the ORAS Working Group wi Some Working Groups are ephemeral or naturally reach the end of their useful life. Working Group owners can choose dissolve their Working Groups by submitting an issue in the ORAS community repository. The ORAS [Owners](../OWNERS.md) takes ownership to handle their request and ORAS Owners also reserves the right to dissolve or recharter working groups over time as necessary, though they will strive to first discuss this in committee meetings and open community discussion. +## FAQ + +### Differences between Sub-project and the Working Group + +Working groups are organizations responsible for the design and implementation of large architectural aspects of the overall ORAS project. Working groups operate with a fair amount of autonomy within the broader scope of the project. They tend to be long-lived or temporary. + +The sub-project is defined in [GOVERNANCE.md](./GOVERNANCE.md). The sub-project is a GitHub repository under the ORAS organization, which is intended to solving specific requirements and is more focused on implementation. It could be the outcome of the Working Group. A Working Group's scope may be across multiple sub-projects. + ## Attributions The Working Group model we created above references the practice from [OCI Working Groups](https://github.com/opencontainers/tob/blob/main/WG-INFO.md), [Knative working group processes and guidelines](https://github.com/knative/community/blob/main/mechanics/WORKING-GROUP-PROCESSES.md) and [Kubernetes Working Group Formation and Disbandment](https://github.com/kubernetes/community/blob/master/committee-steering/governance/wg-governance.md). From f9d6b4e634acfb2b9bde47d8541b4366ab2621af Mon Sep 17 00:00:00 2001 From: Feynman Zhou Date: Tue, 25 Apr 2023 23:16:52 +0800 Subject: [PATCH 4/5] refine doc Signed-off-by: Feynman Zhou --- governance/WORKING-GROUPS.md | 1 - 1 file changed, 1 deletion(-) diff --git a/governance/WORKING-GROUPS.md b/governance/WORKING-GROUPS.md index 208b7f6..3378a21 100644 --- a/governance/WORKING-GROUPS.md +++ b/governance/WORKING-GROUPS.md @@ -64,4 +64,3 @@ The sub-project is defined in [GOVERNANCE.md](./GOVERNANCE.md). The sub-project ## Attributions The Working Group model we created above references the practice from [OCI Working Groups](https://github.com/opencontainers/tob/blob/main/WG-INFO.md), [Knative working group processes and guidelines](https://github.com/knative/community/blob/main/mechanics/WORKING-GROUP-PROCESSES.md) and [Kubernetes Working Group Formation and Disbandment](https://github.com/kubernetes/community/blob/master/committee-steering/governance/wg-governance.md). -,m \ No newline at end of file From 983e9b3c395d6410a00e2edfd37e24d7d4f60795 Mon Sep 17 00:00:00 2001 From: Feynman Zhou Date: Fri, 5 May 2023 23:40:30 +0800 Subject: [PATCH 5/5] update the WG definition Signed-off-by: Feynman Zhou --- governance/WORKING-GROUPS.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/governance/WORKING-GROUPS.md b/governance/WORKING-GROUPS.md index 3378a21..2185381 100644 --- a/governance/WORKING-GROUPS.md +++ b/governance/WORKING-GROUPS.md @@ -1,6 +1,6 @@ # Working Groups -Working Groups are organizations responsible for the design and implementation of large architectural aspects of the overall ORAS project. Working Groups operate with a fair amount of autonomy within the broader scope of the project. They tend to be long-lived or temporary. +Working Groups are organizations responsible for the design and implementation of large architectural aspects of the overall ORAS project. Working Groups operate with a fair amount of autonomy within the broader scope of the project. Working Groups are primarily used to facilitate topics of discussion that are in scope for ORAS but that cross multiple sub-projects and teams. It provides a formal avenue for disparate teams or groups to collaborate around a common problem, craft a balanced position, and disband. @@ -57,7 +57,7 @@ Some Working Groups are ephemeral or naturally reach the end of their useful lif ### Differences between Sub-project and the Working Group -Working groups are organizations responsible for the design and implementation of large architectural aspects of the overall ORAS project. Working groups operate with a fair amount of autonomy within the broader scope of the project. They tend to be long-lived or temporary. +Working groups are organizations responsible for the design and implementation of large architectural aspects of the overall ORAS project. Working groups operate with a fair amount of autonomy within the broader scope of the project. They tend to be short-lived. The sub-project is defined in [GOVERNANCE.md](./GOVERNANCE.md). The sub-project is a GitHub repository under the ORAS organization, which is intended to solving specific requirements and is more focused on implementation. It could be the outcome of the Working Group. A Working Group's scope may be across multiple sub-projects.