From e4c43c3d2728ff5bf8f75f403848403c85858c92 Mon Sep 17 00:00:00 2001 From: Stefan Prodan Date: Thu, 19 Nov 2020 21:00:07 +0200 Subject: [PATCH 01/13] Add DCO, CoC and Gov docs Signed-off-by: Stefan Prodan --- GOVERNANCE.md | 159 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 159 insertions(+) create mode 100644 GOVERNANCE.md diff --git a/GOVERNANCE.md b/GOVERNANCE.md new file mode 100644 index 0000000..2108dc3 --- /dev/null +++ b/GOVERNANCE.md @@ -0,0 +1,159 @@ + + +# Flux Governance + +This document defines the governance process for the Flux project and community. + +- [Values](#values) + - [Code of Conduct](#code-of-conduct) +- [Roles in the Flux Community](#roles-in-the-flux-community) + - [Users](#users) + - [Contributors](#contributors) + - [Maintainers](#maintainers) + - [Oversight Committee](#oversight-committee) +- [Decision Making](#decision-making) + - [Deciders](#deciders) + - [Decision Guidelines](#decision-guidelines) + - [Simple Majority Decisions](#simple-majority-decisions) + - [Supermajority Decisions](#supermajority-decisions) + - [Unanimity Decisions](#unanimity-decisions) +- [Proposal Process](#proposal-process) +- [Licenses and Copyright](#licenses-and-copyright) + +## Values + +- **Open:** +The Flux community strives to be open, accessible and welcoming to everyone. +Anyone may contribute, and contributions are available to all users according to open source values and licenses. +- **Transparent:** +Flux strives for transparency in all discussions, announcements, disclosures and decision making. +- **Unbiased:** +Flux strives to operate independently of specific partisan interests, and for decision making to fairly balance the wider community interests of its end users and contributors. + +### Code of Conduct + +The Flux community adheres to the CNCF Code of Conduct . + +Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting a _Flux_ Oversight Committee member. + +If no conclusion can be reached in meditation, such issues can be escalated to the CNCF mediator, Mishi Choudhary , in which case CNCF may choose to intervene. + +## Roles in the Flux Community + +The Flux community comprises the following roles: + +### Users + +Flux end users are the most important aspect of the community, without whom the project would have no purpose. Users are anyone who has a need for the project. +Apart from following the Code of Conduct, there are no special requirements. + +### Contributors + +Flux welcomes all kinds of contributions, including code, issues, documentation, external tools, advocacy and community work. +As a contributor we want to invite you to join the discussions in a variety of forums laid out in . + +### Maintainers + +Maintainers are elected Contributors who showed significant and sustained contributions in a git repository. +Current Maintainers are listed in a `MAINTAINERS` file at the root of the git repository. + +Maintainers are expected to: + +- Enable and promote Flux community values +- Engage with end Users through appropriate communication channels +- Serve as a point of conflict resolution between Contributors to their git repository +- Maintain open collaboration with Contributors and other Maintainers +- Ask for help when unsure and step down considerately + +Maintainers will be invited to the `@fluxcd/maintainers` team, and are members of this team for as long as they are involved with the project. + +### Oversight Committee + +This committee is responsible for the overall project, and anything not easily managed by the Maintainers of each git repository. Including: + +- Overseeing the project health and growth +- Maintaining the brand, mission, vision, values, and scope of the overall project +- Changes to licensing and intellectual property +- Administering access to all project assets +- Administering git repositories as needed +- Handling Code of Conduct violations +- Managing financial decisions +- Defining the scope of each git repository +- Resolving escalated decisions when Maintainers responsible are blocked + +Ultimately the committee - after consulting with the collective of Maintainers and their community - drive the direction, values and governance of the overall project. + +This committee will initially be comprised of Flux Maintainers who have steered the project prior to this initial Governance document. +The aspiration is no one company or organization should have oversight of the overall project, however that is not yet realistic at this stage. The goal is to broaden maintainership to include a wider range of organizations during CNCF incubation. + +Oversight Committee members are publicly listed in the `@fluxcd/oversight-committee` GitHub team. + +## Decision Making + +### Deciders + +- Repository Maintainers: Decisions that affect only one git repository. +- Oversight Committee: Decisions that are outside the scope of a single git repository. + +### Decision Guidelines + +- Decisions that warrant wider input should be made public by using the below guidelines in combination with the Proposal Process below. +- Whether or not wider input is required, the Flux community believes that the best decisions are reached through Consensus . +- Most decisions start by seeking Lazy Consensus . +- If an objection is raised through the Lazy Consensus process, Deciders work together to seek an agreeable solution. +- If Consensus can not be reached, but a decision must be made, the next step is try to attempt to agree that a vote should be called. + This is important, as it gives dissenting views a chance to request more information or raise further points. + If Deciders are the Oversight Committee, part of that responsibility is the final point of escalation, so agreeing to a vote is assumed if timeline doesn't allow the consensus process to continue. +- If Deciders are Repository Maintainers, and they can't agree on calling a vote, they may escalate to the Oversight Committee. + This should only be done at this stage if: + 1. An unmovable deadline is threatened by continuing the Consensus process; or + 2. A Decider feels there is unreasonable blocking of both reaching Consensus and agreeing to a vote. + This should be rare, due to the social cost of discontinuing the Consensus process for this reason. + Most decisions should wait for the above process to take its course. +- If Deciders agree to a vote, the default is a Simple Majority. +- However, there are cases that require stronger voting – Supermajority or Unanimity – specified below: + +### Simple Majority Decisions + +If a vote is called, the default is a Simple Majority Vote . + +### Supermajority Decisions + +If a vote is called, the following decisions require a Supermajority Vote . + +- Oversight Committee: Enforcing a Code of Conduct violation by a community member. +- Oversight Committee: Licensing and intellectual property changes. +- Oversight Committee: Material changes to the Governance document. + - Note: editorial changes to governance may be made by lazy consensus, unless challenged. + These are changes which fix spelling or grammar, update work affiliation or similar, update style or reflect an outside and obvious reality. + They do not change the intention or meaning of anything in this document. + +### Unanimity Decisions + +If a vote is called, the following decisison require Unanimity . + +- Repository Maintainers: Electing new Maintainers of the same repository. +- Oversight Committee: Electing new Committee members. +- Oversight Committee: Removing a Repository Maintainer or Committee member for any reason other than inactivity. + +## Proposal Process + +- Code changes should go through the pull request process, where the idea and implementation details can be publicly discussed with Maintainers, other contributors, and end users. + Pull requests should only be merged after receiving GitHub approval from at least one Maintainer who is not the pull request author. + Note that Flux v2 uses GitHub discussions for proposals in the `fluxcd/toolkit` git repository . +- Non-code changes should be proposed as GitHub issues. + If unclear which git repository to create the issue in, default to the community repository . +- All proposals should be discussed publicly in an appropriate GitHub issue or pull request. +- If a Maintainer of an affected git repository feels feedback from specific people is warranted they will @mention those users or teams to request feedback. +- Proposals may also be added to the Flux Dev weekly meetings agenda, as a good avenue for making progress on a decision . + +## Licenses and Copyright + +- Apache 2.0 is required for all git repositories. +- Developer Certificate of Origin (DCO) commit signoff is required for all new code contributions. + +Links to relevant CNCF documentation: + +- +- +- From 9628ffd0b0529fbde6ef3ec0757db065d575c908 Mon Sep 17 00:00:00 2001 From: Dan Garfield Date: Thu, 19 Nov 2020 13:43:53 -0700 Subject: [PATCH 02/13] Update Governance to be GitOps Working Group Spec Remove confusion around Flux and change words to GitOps Working Group. Signed-off-by: Dan Garfield --- GOVERNANCE.md | 34 +++++++++++++++------------------- 1 file changed, 15 insertions(+), 19 deletions(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 2108dc3..7bac956 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -1,12 +1,12 @@ -# Flux Governance +# GitOps Working Group Governance -This document defines the governance process for the Flux project and community. +This document defines the governance process for the GitOps Working Group and community. - [Values](#values) - [Code of Conduct](#code-of-conduct) -- [Roles in the Flux Community](#roles-in-the-flux-community) +- [Roles in the GitOps Working Group](#roles-in-the-GitOps-Working-Group) - [Users](#users) - [Contributors](#contributors) - [Maintainers](#maintainers) @@ -23,34 +23,34 @@ This document defi ## Values - **Open:** -The Flux community strives to be open, accessible and welcoming to everyone. +The GitOps Working Group strives to be open, accessible and welcoming to everyone. Anyone may contribute, and contributions are available to all users according to open source values and licenses. - **Transparent:** -Flux strives for transparency in all discussions, announcements, disclosures and decision making. +The GitOps Working Group strives for transparency in all discussions, announcements, disclosures and decision making. - **Unbiased:** -Flux strives to operate independently of specific partisan interests, and for decision making to fairly balance the wider community interests of its end users and contributors. +The GitOps Working Group strives to operate independently of specific partisan interests, and for decision making to fairly balance the wider community interests of its end users and contributors. ### Code of Conduct -The Flux community adheres to the CNCF Code of Conduct . +The GitOps Working Group adheres to the CNCF Code of Conduct . -Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting a _Flux_ Oversight Committee member. +Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting a _GitOps Working Group_ Oversight Committee member. If no conclusion can be reached in meditation, such issues can be escalated to the CNCF mediator, Mishi Choudhary , in which case CNCF may choose to intervene. -## Roles in the Flux Community +## Roles in the GitOps Working Group -The Flux community comprises the following roles: +The GitOps Working Group community comprises the following roles: ### Users -Flux end users are the most important aspect of the community, without whom the project would have no purpose. Users are anyone who has a need for the project. +GitOps Working Group end users are the most important aspect of the community, without whom the project would have no purpose. Users are anyone who has a need for the project. Apart from following the Code of Conduct, there are no special requirements. ### Contributors -Flux welcomes all kinds of contributions, including code, issues, documentation, external tools, advocacy and community work. -As a contributor we want to invite you to join the discussions in a variety of forums laid out in . +The GitOps Working Group welcomes all kinds of contributions, including code, issues, documentation, external tools, advocacy and community work. +As a contributor we want to invite you to join the discussions. ### Maintainers @@ -59,13 +59,13 @@ Current Maintainers are listed in a `MAINTAINERS` file at the root of the git re Maintainers are expected to: -- Enable and promote Flux community values +- Enable and promote GitOps Working Group community values - Engage with end Users through appropriate communication channels - Serve as a point of conflict resolution between Contributors to their git repository - Maintain open collaboration with Contributors and other Maintainers - Ask for help when unsure and step down considerately -Maintainers will be invited to the `@fluxcd/maintainers` team, and are members of this team for as long as they are involved with the project. +Maintainers will be invited to the `@gitops/maintainers` team, and are members of this team for as long as they are involved with the project. ### Oversight Committee @@ -139,13 +139,9 @@ If a vote is called, the following decisison require Unanimity . - Non-code changes should be proposed as GitHub issues. - If unclear which git repository to create the issue in, default to the community repository . - All proposals should be discussed publicly in an appropriate GitHub issue or pull request. - If a Maintainer of an affected git repository feels feedback from specific people is warranted they will @mention those users or teams to request feedback. -- Proposals may also be added to the Flux Dev weekly meetings agenda, as a good avenue for making progress on a decision . ## Licenses and Copyright From ef593d5e21d4e482aced246e670078afa9c38643 Mon Sep 17 00:00:00 2001 From: Dan Garfield Date: Fri, 20 Nov 2020 11:49:34 -0700 Subject: [PATCH 03/13] Update GOVERNANCE.md Signed-off-by: Dan Garfield --- GOVERNANCE.md | 156 +------------------------------------------------- 1 file changed, 1 insertion(+), 155 deletions(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 7bac956..73c06c5 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -1,155 +1 @@ - - -# GitOps Working Group Governance - -This document defines the governance process for the GitOps Working Group and community. - -- [Values](#values) - - [Code of Conduct](#code-of-conduct) -- [Roles in the GitOps Working Group](#roles-in-the-GitOps-Working-Group) - - [Users](#users) - - [Contributors](#contributors) - - [Maintainers](#maintainers) - - [Oversight Committee](#oversight-committee) -- [Decision Making](#decision-making) - - [Deciders](#deciders) - - [Decision Guidelines](#decision-guidelines) - - [Simple Majority Decisions](#simple-majority-decisions) - - [Supermajority Decisions](#supermajority-decisions) - - [Unanimity Decisions](#unanimity-decisions) -- [Proposal Process](#proposal-process) -- [Licenses and Copyright](#licenses-and-copyright) - -## Values - -- **Open:** -The GitOps Working Group strives to be open, accessible and welcoming to everyone. -Anyone may contribute, and contributions are available to all users according to open source values and licenses. -- **Transparent:** -The GitOps Working Group strives for transparency in all discussions, announcements, disclosures and decision making. -- **Unbiased:** -The GitOps Working Group strives to operate independently of specific partisan interests, and for decision making to fairly balance the wider community interests of its end users and contributors. - -### Code of Conduct - -The GitOps Working Group adheres to the CNCF Code of Conduct . - -Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting a _GitOps Working Group_ Oversight Committee member. - -If no conclusion can be reached in meditation, such issues can be escalated to the CNCF mediator, Mishi Choudhary , in which case CNCF may choose to intervene. - -## Roles in the GitOps Working Group - -The GitOps Working Group community comprises the following roles: - -### Users - -GitOps Working Group end users are the most important aspect of the community, without whom the project would have no purpose. Users are anyone who has a need for the project. -Apart from following the Code of Conduct, there are no special requirements. - -### Contributors - -The GitOps Working Group welcomes all kinds of contributions, including code, issues, documentation, external tools, advocacy and community work. -As a contributor we want to invite you to join the discussions. - -### Maintainers - -Maintainers are elected Contributors who showed significant and sustained contributions in a git repository. -Current Maintainers are listed in a `MAINTAINERS` file at the root of the git repository. - -Maintainers are expected to: - -- Enable and promote GitOps Working Group community values -- Engage with end Users through appropriate communication channels -- Serve as a point of conflict resolution between Contributors to their git repository -- Maintain open collaboration with Contributors and other Maintainers -- Ask for help when unsure and step down considerately - -Maintainers will be invited to the `@gitops/maintainers` team, and are members of this team for as long as they are involved with the project. - -### Oversight Committee - -This committee is responsible for the overall project, and anything not easily managed by the Maintainers of each git repository. Including: - -- Overseeing the project health and growth -- Maintaining the brand, mission, vision, values, and scope of the overall project -- Changes to licensing and intellectual property -- Administering access to all project assets -- Administering git repositories as needed -- Handling Code of Conduct violations -- Managing financial decisions -- Defining the scope of each git repository -- Resolving escalated decisions when Maintainers responsible are blocked - -Ultimately the committee - after consulting with the collective of Maintainers and their community - drive the direction, values and governance of the overall project. - -This committee will initially be comprised of Flux Maintainers who have steered the project prior to this initial Governance document. -The aspiration is no one company or organization should have oversight of the overall project, however that is not yet realistic at this stage. The goal is to broaden maintainership to include a wider range of organizations during CNCF incubation. - -Oversight Committee members are publicly listed in the `@fluxcd/oversight-committee` GitHub team. - -## Decision Making - -### Deciders - -- Repository Maintainers: Decisions that affect only one git repository. -- Oversight Committee: Decisions that are outside the scope of a single git repository. - -### Decision Guidelines - -- Decisions that warrant wider input should be made public by using the below guidelines in combination with the Proposal Process below. -- Whether or not wider input is required, the Flux community believes that the best decisions are reached through Consensus . -- Most decisions start by seeking Lazy Consensus . -- If an objection is raised through the Lazy Consensus process, Deciders work together to seek an agreeable solution. -- If Consensus can not be reached, but a decision must be made, the next step is try to attempt to agree that a vote should be called. - This is important, as it gives dissenting views a chance to request more information or raise further points. - If Deciders are the Oversight Committee, part of that responsibility is the final point of escalation, so agreeing to a vote is assumed if timeline doesn't allow the consensus process to continue. -- If Deciders are Repository Maintainers, and they can't agree on calling a vote, they may escalate to the Oversight Committee. - This should only be done at this stage if: - 1. An unmovable deadline is threatened by continuing the Consensus process; or - 2. A Decider feels there is unreasonable blocking of both reaching Consensus and agreeing to a vote. - This should be rare, due to the social cost of discontinuing the Consensus process for this reason. - Most decisions should wait for the above process to take its course. -- If Deciders agree to a vote, the default is a Simple Majority. -- However, there are cases that require stronger voting – Supermajority or Unanimity – specified below: - -### Simple Majority Decisions - -If a vote is called, the default is a Simple Majority Vote . - -### Supermajority Decisions - -If a vote is called, the following decisions require a Supermajority Vote . - -- Oversight Committee: Enforcing a Code of Conduct violation by a community member. -- Oversight Committee: Licensing and intellectual property changes. -- Oversight Committee: Material changes to the Governance document. - - Note: editorial changes to governance may be made by lazy consensus, unless challenged. - These are changes which fix spelling or grammar, update work affiliation or similar, update style or reflect an outside and obvious reality. - They do not change the intention or meaning of anything in this document. - -### Unanimity Decisions - -If a vote is called, the following decisison require Unanimity . - -- Repository Maintainers: Electing new Maintainers of the same repository. -- Oversight Committee: Electing new Committee members. -- Oversight Committee: Removing a Repository Maintainer or Committee member for any reason other than inactivity. - -## Proposal Process - -- Code changes should go through the pull request process, where the idea and implementation details can be publicly discussed with Maintainers, other contributors, and end users. -- Non-code changes should be proposed as GitHub issues. -- All proposals should be discussed publicly in an appropriate GitHub issue or pull request. -- If a Maintainer of an affected git repository feels feedback from specific people is warranted they will @mention those users or teams to request feedback. - -## Licenses and Copyright - -- Apache 2.0 is required for all git repositories. -- Developer Certificate of Origin (DCO) commit signoff is required for all new code contributions. - -Links to relevant CNCF documentation: - -- -- -- +The GitOps Working Group follows the governance process described in https://github.com/fluxcd/community/blob/main/GOVERNANCE.md. From 4a977e5201a8bd4287add4286e1da3eaafde333a Mon Sep 17 00:00:00 2001 From: Cornelia Davis Date: Tue, 15 Dec 2020 10:42:28 -0800 Subject: [PATCH 04/13] Move content from fluxcd/gitops-working-group (#1) * Move content over from fluxcd/gitops-working-group * Update git URLs to reflect new home Signed-off-by: Scott Rigby --- GOVERNANCE.md | 160 +++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 159 insertions(+), 1 deletion(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 73c06c5..4370d1e 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -1 +1,159 @@ -The GitOps Working Group follows the governance process described in https://github.com/fluxcd/community/blob/main/GOVERNANCE.md. + + +# GitOps Working Group Governance + +This document defines the governance process for the GitOps Working Group project and community. + +- [Values](#values) + - [Code of Conduct](#code-of-conduct) +- [Roles in the GitOps Working Group Community](#roles-in-the-gitops-working-group-community) + - [Users](#users) + - [Contributors](#contributors) + - [Maintainers](#maintainers) + - [Oversight Committee](#oversight-committee) +- [Decision Making](#decision-making) + - [Deciders](#deciders) + - [Decision Guidelines](#decision-guidelines) + - [Simple Majority Decisions](#simple-majority-decisions) + - [Supermajority Decisions](#supermajority-decisions) + - [Unanimity Decisions](#unanimity-decisions) +- [Proposal Process](#proposal-process) +- [Licenses and Copyright](#licenses-and-copyright) + +## Values + +- **Open:** +The GitOps Working Group community strives to be open, accessible and welcoming to everyone. +Anyone may contribute, and contributions are available to all users according to open source values and licenses. +- **Transparent:** +The GitOps Working Group strives for transparency in all discussions, announcements, disclosures and decision making. +- **Unbiased:** +The GitOps Working Group strives to operate independently of specific partisan interests, and for decision making to fairly balance the wider community interests of its end users and contributors. + +### Code of Conduct + +The GitOps Working Group community adheres to the CNCF Code of Conduct . + +Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting a _GitOps Working Group_ Oversight Committee member. + +If no conclusion can be reached in meditation, such issues can be escalated to the CNCF mediator, Mishi Choudhary , in which case CNCF may choose to intervene. + +## Roles in the GitOps Working Group Community + +The GitOps Working Group community comprises the following roles: + +### Users + +GitOps end users are the most important aspect of the community, without whom the project would have no purpose. Users are anyone who has a need for the project. +Apart from following the Code of Conduct, there are no special requirements. + +### Contributors + +The GitOps Working Group welcomes all kinds of contributions, including code, issues, documentation, external tools, advocacy and community work. +As a contributor we want to invite you to join the discussions in a variety of forums laid out in TBD. + +### Maintainers + +Maintainers are elected Contributors who showed significant and sustained contributions in a git repository. +The initial set of maintainers are drawn from the organizations that proposed the creation of the working group. +Current Maintainers are listed in a `MAINTAINERS` file at the root of this git repository. + +Maintainers are expected to: + +- Enable and promote GitOps Working Group community values +- Engage with end Users through appropriate communication channels +- Serve as a point of conflict resolution between Contributors to their git repository +- Maintain open collaboration with Contributors and other Maintainers +- Ask for help when unsure and step down considerately + +Maintainers will be invited to the `@gitops-working-group/maintainers` team, and are members of this team for as long as they are involved with the project. + +### Oversight Committee + +This committee is responsible for the overall project, and anything not easily managed by the Maintainers of each git repository. Including: + +- Overseeing the project health and growth +- Maintaining the brand, mission, vision, values, and scope of the overall project +- Changes to licensing and intellectual property +- Administering access to all project assets +- Administering git repositories as needed +- Handling Code of Conduct violations +- Managing financial decisions +- Defining the scope of each git repository +- Resolving escalated decisions when Maintainers responsible are blocked + +Ultimately the committee - after consulting with the collective of Maintainers and their community - drive the direction, values and governance of the overall project. + +This committee will initially be comprised of GitOps Working Group Maintainers who have steered the project prior to this initial Governance document. +The aspiration is no one company or organization should have oversight of the overall project, however that is not yet realistic at this stage. The goal is to broaden maintainership to include a wider range of organizations during CNCF incubation. + +Oversight Committee members are publicly listed in the `@gitops-working-group/oversight-committee` GitHub team. + +## Decision Making + +### Deciders + +- Repository Maintainers: Decisions that affect only one git repository. +- Oversight Committee: Decisions that are outside the scope of a single git repository. + +### Decision Guidelines + +- Decisions that warrant wider input should be made public by using the below guidelines in combination with the Proposal Process below. +- Whether or not wider input is required, the GitOps Working Group community believes that the best decisions are reached through Consensus . +- Most decisions start by seeking Lazy Consensus . +- If an objection is raised through the Lazy Consensus process, Deciders work together to seek an agreeable solution. +- If Consensus can not be reached, but a decision must be made, the next step is try to attempt to agree that a vote should be called. + This is important, as it gives dissenting views a chance to request more information or raise further points. + If Deciders are the Oversight Committee, part of that responsibility is the final point of escalation, so agreeing to a vote is assumed if timeline doesn't allow the consensus process to continue. +- If Deciders are Repository Maintainers, and they can't agree on calling a vote, they may escalate to the Oversight Committee. + This should only be done at this stage if: + 1. An unmovable deadline is threatened by continuing the Consensus process; or + 2. A Decider feels there is unreasonable blocking of both reaching Consensus and agreeing to a vote. + This should be rare, due to the social cost of discontinuing the Consensus process for this reason. + Most decisions should wait for the above process to take its course. +- If Deciders agree to a vote, the default is a Simple Majority. +- However, there are cases that require stronger voting – Supermajority or Unanimity – specified below: + +### Simple Majority Decisions + +If a vote is called, the default is a Simple Majority Vote . + +### Supermajority Decisions + +If a vote is called, the following decisions require a Supermajority Vote . + +- Oversight Committee: Enforcing a Code of Conduct violation by a community member. +- Oversight Committee: Licensing and intellectual property changes. +- Oversight Committee: Material changes to the Governance document. + - Note: editorial changes to governance may be made by lazy consensus, unless challenged. + These are changes which fix spelling or grammar, update work affiliation or similar, update style or reflect an outside and obvious reality. + They do not change the intention or meaning of anything in this document. + +### Unanimity Decisions + +If a vote is called, the following decisison require Unanimity . + +- Repository Maintainers: Electing new Maintainers of the same repository. +- Oversight Committee: Electing new Committee members. +- Oversight Committee: Removing a Repository Maintainer or Committee member for any reason other than inactivity. + +## Proposal Process + +- Changes to artifacts produced by the GitOps Working Group (documentation, samples, etc.) should go through the pull request process, where the idea and any implementation details can be publicly discussed with Maintainers, other contributors, and end users. + Pull requests should only be merged after receiving GitHub approval from at least one Maintainer who is not the pull request author. +- Non-artifact changes should be proposed as GitHub issues. + If unclear which git repository to create the issue in, default to the community repository . +- All proposals should be discussed publicly in an appropriate GitHub issue or pull request. +- If a Maintainer of an affected git repository feels feedback from specific people is warranted they will @mention those users or teams to request feedback. +- Proposals may also be added to the GitOps Working Group meetings agenda, as a good avenue for making progress on a decision . + +## Licenses and Copyright + +- Apache 2.0 is required for all git repositories. +- Developer Certificate of Origin (DCO) commit signoff is required for all new code contributions. + +Links to relevant CNCF documentation: + +- +- +- From 2711e063f69ba5315fea09c247ec53396d070733 Mon Sep 17 00:00:00 2001 From: Cornelia Davis Date: Wed, 24 Mar 2021 13:19:06 -0700 Subject: [PATCH 05/13] Describe role of Working Group co-chairs. (#86) * Describe role of Working Group co-chairs. Update governance to disambiguate project and working group. Signed-off-by: Cornelia Davis * Clarify the coordination resoponsibility Good suggestion @sbose78 Co-authored-by: Scott Rigby Signed-off-by: Cornelia Davis --- GOVERNANCE.md | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 4370d1e..54df453 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -2,7 +2,7 @@ # GitOps Working Group Governance -This document defines the governance process for the GitOps Working Group project and community. +This document defines the governance process for the OpenGitOps project and the GitOps Working Group and community. - [Values](#values) - [Code of Conduct](#code-of-conduct) @@ -40,21 +40,21 @@ If no conclusion can be reached in meditation, such issues can be escalated to t ## Roles in the GitOps Working Group Community -The GitOps Working Group community comprises the following roles: +The OpenGitOps and GitOps Working Group community comprises the following roles: ### Users -GitOps end users are the most important aspect of the community, without whom the project would have no purpose. Users are anyone who has a need for the project. +OpenGitOps end users are the most important aspect of the community, without whom the project would have no purpose. Users are anyone who has a need for the project. Apart from following the Code of Conduct, there are no special requirements. ### Contributors -The GitOps Working Group welcomes all kinds of contributions, including code, issues, documentation, external tools, advocacy and community work. +The OpenGitOps project welcomes all kinds of contributions, including code, issues, documentation, external tools, advocacy and community work. As a contributor we want to invite you to join the discussions in a variety of forums laid out in TBD. ### Maintainers -Maintainers are elected Contributors who showed significant and sustained contributions in a git repository. +OpenGitOps project Maintainers are elected Contributors who showed significant and sustained contributions in a git repository. The initial set of maintainers are drawn from the organizations that proposed the creation of the working group. Current Maintainers are listed in a `MAINTAINERS` file at the root of this git repository. @@ -70,7 +70,7 @@ Maintainers will be invited to the `@gitops-working-group/maintainers` GitHub team. +### Working Group Co-Chairs + +The GitOps Working Group draws together individuals who are collaborating on forming content and technology "to provide companies and individuals with the skills, knowledge and competency to implement GitOps tooling and methodologies which simplify the operation and management of infrastructure and cloud native applications" and to care for the OpenGitOps project. + +Co-chairs: + +- Ensure that meetings and other activities are conducted and progress continues to be made against the project agenda +- Have GitOps domain knowledge +- Will engage deeply in the work being done by the working group - that is, the role is not purely administrative. They are, however not responsible for performing all of the work - this is shared across the working group members and expected from those who have volunteered onto various workstreams. +- When necessary, will handle human and technical coordination across different working group workstreams. + +The working group co-chairs are selected by the members of the working group and are listed in the `CHAIRS` file at the root of this git repository. + ## Decision Making ### Deciders From 68566b7c37874b3f19d1c492b358c163a98680d7 Mon Sep 17 00:00:00 2001 From: Scott Rigby Date: Tue, 1 Jun 2021 09:10:48 -0700 Subject: [PATCH 06/13] Simplify Working Group and OpenGitOps project Governance (#125) Outline more appropriate Working Group and OpenGitOps project Governance We are now ready to update the provisional bootstrapped governance as the GitOps WG and sandbox project roles and relationships are more clearly defined. - Attempted to outline known processes as explicitly as possible, while keeping as simple as possible given the context. Looking for feedback on this - Bring initial GitOps WG charter into a charter.md, with some updates - Simplify GOVERNANCE.md - Removed stray .gitignore file - Add interested parties and organizational voting - Update timetable - Limit one vote per listed org - Also require CNCF membership to vote - Clarify requirements for individual voting - Add GitOpsCon to work products - Require supermajority vote for adding additional maintainers Co-authored-by: Dan Garfield Co-authored-by: Leonardo Murillo Signed-off-by: Scott Rigby --- GOVERNANCE.md | 203 +++++++++++++++++++++----------------------------- 1 file changed, 85 insertions(+), 118 deletions(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 54df453..e8393fe 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -1,130 +1,125 @@ - - -# GitOps Working Group Governance +# Governance -This document defines the governance process for the OpenGitOps project and the GitOps Working Group and community. +This document defines the governance process for the GitOps Working Group and community and OpenGitOps project. -- [Values](#values) - - [Code of Conduct](#code-of-conduct) -- [Roles in the GitOps Working Group Community](#roles-in-the-gitops-working-group-community) - - [Users](#users) - - [Contributors](#contributors) - - [Maintainers](#maintainers) - - [Oversight Committee](#oversight-committee) -- [Decision Making](#decision-making) - - [Deciders](#deciders) - - [Decision Guidelines](#decision-guidelines) - - [Simple Majority Decisions](#simple-majority-decisions) - - [Supermajority Decisions](#supermajority-decisions) - - [Unanimity Decisions](#unanimity-decisions) -- [Proposal Process](#proposal-process) -- [Licenses and Copyright](#licenses-and-copyright) +## Roles -## Values +### All Members -- **Open:** -The GitOps Working Group community strives to be open, accessible and welcoming to everyone. -Anyone may contribute, and contributions are available to all users according to open source values and licenses. -- **Transparent:** -The GitOps Working Group strives for transparency in all discussions, announcements, disclosures and decision making. -- **Unbiased:** -The GitOps Working Group strives to operate independently of specific partisan interests, and for decision making to fairly balance the wider community interests of its end users and contributors. +This is an open public working group welcoming anyone who would like to join and help. +There are no special requirements for membership apart from the responsibilities listed below. +Members are not required to have any explicit roles or additional responsibilities, but they may also have formally assigned roles (see below). +See the Working Group [README](README.md) for information about volunteering for committees and projects. +Note that voting requires additional conditions (see [Elections](#elections)). -### Code of Conduct +Responsibilities: -The GitOps Working Group community adheres to the CNCF Code of Conduct . +- Must follow the [Code of Conduct](CODE_OF_CONDUCT.md) +- May not create the impression that they have any authority or formal responsibilities within the GitOps WG other than their explicitly assigned roles -Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting a _GitOps Working Group_ Oversight Committee member. +### Committees -If no conclusion can be reached in meditation, such issues can be escalated to the CNCF mediator, Mishi Choudhary , in which case CNCF may choose to intervene. +Working Group [Members](#all-members) may volunteer to join WG Committees and help with specific projects according to their interest and ability. +Responsibilities vary per committee, but in general please remember everyone is a volunteer. +Committees follow processes to allow for progress so long as they maintain inclusiveness, transparency, and respect for all involved. -## Roles in the GitOps Working Group Community +Current WG committees: -The OpenGitOps and GitOps Working Group community comprises the following roles: +- Principles Committee + - Responsible for drafting the revised GitOps Principles (see [Timeline](#timeline)) +- Events Committee + - Responsible for organizing events such as GitOpsCon, and supporting other events in the wider GitOps community (see [Timeline](#timeline)) +- Communications Committee + - Reponsible for coordinating public communications on behalf of the working group -### Users - -OpenGitOps end users are the most important aspect of the community, without whom the project would have no purpose. Users are anyone who has a need for the project. -Apart from following the Code of Conduct, there are no special requirements. +### Maintainers -### Contributors +Working Group and OpenGitOps project Maintainers are [Members](#all-members) who have shown significant and sustained contributions in the GitOps WG. +The initial set of Maintainers were drawn from the organizations that proposed the creation of the working group. +Current Maintainers are listed in a [MAINTAINERS](./MAINTAINERS) file at the root of this git repository. -The OpenGitOps project welcomes all kinds of contributions, including code, issues, documentation, external tools, advocacy and community work. -As a contributor we want to invite you to join the discussions in a variety of forums laid out in TBD. +Responsibilities: -### Maintainers +- Enable and promote GitOps Working Group community values +- Engage with the wider GitOps community through appropriate [communication channels](./README.md#how-to-get-involved) +- Maintain involvement and open collaboration with working group members and committees +- Review and approve pull requests +- Ask for help when unsure and step down considerately when appropriate -OpenGitOps project Maintainers are elected Contributors who showed significant and sustained contributions in a git repository. -The initial set of maintainers are drawn from the organizations that proposed the creation of the working group. -Current Maintainers are listed in a `MAINTAINERS` file at the root of this git repository. +The GitHub `@gitops-working-group/maintainers` team will be kept up to date with current maintainers. -Maintainers are expected to: +### Chairs -- Enable and promote GitOps Working Group community values -- Engage with end Users through appropriate communication channels -- Serve as a point of conflict resolution between Contributors to their git repository -- Maintain open collaboration with Contributors and other Maintainers -- Ask for help when unsure and step down considerately +The GitOps WG and OpenGitOps project will be co-chaired by 3 [Maintainers](#maintainers). +A maximum of one person from any one entity may hold a chair role at any given moment in order to avoid undue influence, and maintain balanced representation. +Current chairs are listed in a [CHAIRS.md](./CHAIRS.md) file at the root of this git repository. -Maintainers will be invited to the `@gitops-working-group/maintainers` team, and are members of this team for as long as they are involved with the project. +Responsibilities: -### Oversight Committee +- Primary role of Chairs is governance of the Working Group, who collectively care for the OpenGitOps project +- Ensure the promotion of continued open involvement for the working group +- Ensure that meetings and other activities are conducted and progress continues to be made against the project agenda, while also engaging other group members in leadership roles +- Ensure discussion is extended asynchronously to be inclusive of members who cannot attend a specific meeting time +- Schedule discussion of proposals that have been submitted +- Partner with Maintainers and other WG members to establish a roadmap and manage ongoing projects +- Ask for new proposals to be made to address an identified needs +- Have GitOps domain knowledge +- Engage deeply in the work being done by the working group - that is, the role is not purely administrative. + Chairs are, however not responsible for performing all of the work - this is shared across the working group members and expected from those who have volunteered onto various workstreams. +- When necessary, handle human and technical coordination across different working group workstreams +- Handle Code of Conduct violations +- Resolve escalated decisions when Maintainers can not reach consensus -The OpenGitOps oversight committee is responsible for the overall project, and anything not easily managed by the Maintainers of each git repository. Including: +Ultimately the chairs - after consulting with the collective of Maintainers and their community - drive the direction, values and governance of the overall project. -- Overseeing the project health and growth -- Maintaining the brand, mission, vision, values, and scope of the overall project -- Changes to licensing and intellectual property -- Administering access to all project assets -- Administering git repositories as needed -- Handling Code of Conduct violations -- Managing financial decisions -- Defining the scope of each git repository -- Resolving escalated decisions when Maintainers responsible are blocked +The GitHub `@gitops-working-group/chairs` team will be kept up to date with current chairs. -Ultimately the committee - after consulting with the collective of Maintainers and their community - drive the direction, values and governance of the overall project. +## Elections -This committee will initially be comprised of GitOps Working Group Maintainers who have steered the project prior to this initial Governance document. -The aspiration is no one company or organization should have oversight of the overall project, however that is not yet realistic at this stage. The goal is to broaden maintainership to include a wider range of organizations during CNCF incubation. +[Chairs](#chairs) will be elected for one year terms and may run for reelection. -Oversight Committee members are publicly listed in the `@gitops-working-group/oversight-committee` GitHub team. +The election process takes place on the CNCF SIG App Delivery [mailing list](cncf-sig-app-delivery@lists.cncf.io ). -### Working Group Co-Chairs +Before each election, there will be a call for nominations on the mailing list. +Nominations should be sent to the mailing list, and include a brief bio and personal statement describing the candidate's qualifications to serve in this capacity. +Self-nominations are welcome. Only existing maintainers are eligible for nomination. -The GitOps Working Group draws together individuals who are collaborating on forming content and technology "to provide companies and individuals with the skills, knowledge and competency to implement GitOps tooling and methodologies which simplify the operation and management of infrastructure and cloud native applications" and to care for the OpenGitOps project. +The GitOps WG employs "organization voting" to ensure no single organization can dominate the election process or project. +Up to two individuals from organizations who are both active members of the CNCF and listed in the [interested parties](interested-parties.md) may vote. +Interested parties must be added at least one week before any election to have a vote. +Chairs will be elected using Ranked Choice Voting. -Co-chairs: +Election results will be announced on the mailing list, and current chairs listed in this document will be updated accordingly. -- Ensure that meetings and other activities are conducted and progress continues to be made against the project agenda -- Have GitOps domain knowledge -- Will engage deeply in the work being done by the working group - that is, the role is not purely administrative. They are, however not responsible for performing all of the work - this is shared across the working group members and expected from those who have volunteered onto various workstreams. -- When necessary, will handle human and technical coordination across different working group workstreams. +### Special Elections -The working group co-chairs are selected by the members of the working group and are listed in the `CHAIRS` file at the root of this git repository. +There are several cases where positions are put up for unscheduled, special elections. -## Decision Making +- Stepping down: If an elected chair steps down (or, in rare cases, is removed), a special election will be necessary to fill vacancies +- Change of affiliation: When affiliations of current chairs change – through job changes, mergers, etc. – and entity becomes overrepresented for a specific role, members of that entity will first be asked if they wish to resign their roles in order to remain within the allotment. + If insufficient members resign their roles, the positions held by members associated with that entity will all be put up for a special election -### Deciders +In these cases, positions will be open both to previous holders and to any new nominees. +The standard nomination and [election](#elections) process will be carried out. +Representatives elected though this process will serve the remaining part of the current term. -- Repository Maintainers: Decisions that affect only one git repository. -- Oversight Committee: Decisions that are outside the scope of a single git repository. +## Decision Making ### Decision Guidelines -- Decisions that warrant wider input should be made public by using the below guidelines in combination with the Proposal Process below. -- Whether or not wider input is required, the GitOps Working Group community believes that the best decisions are reached through Consensus . -- Most decisions start by seeking Lazy Consensus . -- If an objection is raised through the Lazy Consensus process, Deciders work together to seek an agreeable solution. +- The GitOps Working Group believes that the best decisions are reached through Consensus . + This applies to all working communication by WG members (see [How To Get Involved](README.md#how-to-get-involved)). +- Most decisions begin by seeking Lazy Consensus . +- If an objection is raised through the Lazy Consensus process, the group works together to seek an agreeable solution. - If Consensus can not be reached, but a decision must be made, the next step is try to attempt to agree that a vote should be called. This is important, as it gives dissenting views a chance to request more information or raise further points. - If Deciders are the Oversight Committee, part of that responsibility is the final point of escalation, so agreeing to a vote is assumed if timeline doesn't allow the consensus process to continue. -- If Deciders are Repository Maintainers, and they can't agree on calling a vote, they may escalate to the Oversight Committee. +- If Maintainers can't agree on calling a vote, they may escalate to the Chairs. This should only be done at this stage if: - 1. An unmovable deadline is threatened by continuing the Consensus process; or + 1. An important deadline is threatened by continuing the Consensus process; or 2. A Decider feels there is unreasonable blocking of both reaching Consensus and agreeing to a vote. This should be rare, due to the social cost of discontinuing the Consensus process for this reason. Most decisions should wait for the above process to take its course. -- If Deciders agree to a vote, the default is a Simple Majority. +- If maintainers agree to a vote, the default is a Simple Majority. - However, there are cases that require stronger voting – Supermajority or Unanimity – specified below: ### Simple Majority Decisions @@ -135,38 +130,10 @@ If a vote is called, the default is a Simple Majority Vote . -- Oversight Committee: Enforcing a Code of Conduct violation by a community member. -- Oversight Committee: Licensing and intellectual property changes. -- Oversight Committee: Material changes to the Governance document. +- Maintainers: Adding additional maintainers. +- Chairs: Enforcing a Code of Conduct violation by a community member. +- Chairs: Licensing and intellectual property changes. +- Chairs: Material changes to the Governance document. - Note: editorial changes to governance may be made by lazy consensus, unless challenged. These are changes which fix spelling or grammar, update work affiliation or similar, update style or reflect an outside and obvious reality. They do not change the intention or meaning of anything in this document. - -### Unanimity Decisions - -If a vote is called, the following decisison require Unanimity . - -- Repository Maintainers: Electing new Maintainers of the same repository. -- Oversight Committee: Electing new Committee members. -- Oversight Committee: Removing a Repository Maintainer or Committee member for any reason other than inactivity. - -## Proposal Process - -- Changes to artifacts produced by the GitOps Working Group (documentation, samples, etc.) should go through the pull request process, where the idea and any implementation details can be publicly discussed with Maintainers, other contributors, and end users. - Pull requests should only be merged after receiving GitHub approval from at least one Maintainer who is not the pull request author. -- Non-artifact changes should be proposed as GitHub issues. - If unclear which git repository to create the issue in, default to the community repository . -- All proposals should be discussed publicly in an appropriate GitHub issue or pull request. -- If a Maintainer of an affected git repository feels feedback from specific people is warranted they will @mention those users or teams to request feedback. -- Proposals may also be added to the GitOps Working Group meetings agenda, as a good avenue for making progress on a decision . - -## Licenses and Copyright - -- Apache 2.0 is required for all git repositories. -- Developer Certificate of Origin (DCO) commit signoff is required for all new code contributions. - -Links to relevant CNCF documentation: - -- -- -- From cbc2d87b9f904285f7ca0a5407f07205bc5f29a0 Mon Sep 17 00:00:00 2001 From: Scott Rigby Date: Fri, 17 Dec 2021 19:36:55 -0500 Subject: [PATCH 07/13] Fix link to Code of Conduct Signed-off-by: Scott Rigby --- GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index e8393fe..2d7e9fb 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -14,7 +14,7 @@ Note that voting requires additional conditions (see [Elections](#elections)). Responsibilities: -- Must follow the [Code of Conduct](CODE_OF_CONDUCT.md) +- Must follow the [Code of Conduct](https://github.com/open-gitops/.github/blob/main/CODE_OF_CONDUCT.md) - May not create the impression that they have any authority or formal responsibilities within the GitOps WG other than their explicitly assigned roles ### Committees From 100cee2912ecc431156663d896f4352884105345 Mon Sep 17 00:00:00 2001 From: Scott Rigby Date: Fri, 17 Dec 2021 19:37:43 -0500 Subject: [PATCH 08/13] Link to the documents repo, where the principles are now published To-do: remove the principles committee in a future update, now that it has folded back into the wider group. My suggestion is to make that change as a separate Git commit, so there's a record. Remove anchor to the old timeline. GitOps WG timeline moved here (https://github.com/cncf/tag-app-delivery/tree/main/gitops-wg#timeline), but this list on the website is more appropriate to what is described here for the events committee. Signed-off-by: Scott Rigby --- GOVERNANCE.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 2d7e9fb..94dd752 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -26,9 +26,9 @@ Committees follow processes to allow for progress so long as they maintain inclu Current WG committees: - Principles Committee - - Responsible for drafting the revised GitOps Principles (see [Timeline](#timeline)) + - Responsible for drafting the revised [GitOps Principles](https://github.com/open-gitops/documents) - Events Committee - - Responsible for organizing events such as GitOpsCon, and supporting other events in the wider GitOps community (see [Timeline](#timeline)) + - Responsible for organizing events such as GitOpsCon, and supporting other events in the wider GitOps community (see [OpenGitOps events](https://opengitops.dev/events)) - Communications Committee - Reponsible for coordinating public communications on behalf of the working group From 173e14286853abfbf34f23f5c01486253540bae5 Mon Sep 17 00:00:00 2001 From: Scott Rigby Date: Fri, 17 Dec 2021 19:38:46 -0500 Subject: [PATCH 09/13] Update link to the new location of GitOps WG community involvement info To-do: Update https://github.com/open-gitops/.github/blob/main/CONTRIBUTING.md as a separate PR in the community health files repo. The plan is to move the appropriate steps directly into this document. For now link to what we have. Signed-off-by: Scott Rigby --- GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 94dd752..34e60c3 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -41,7 +41,7 @@ Current Maintainers are listed in a [MAINTAINERS](./MAINTAINERS) file at the roo Responsibilities: - Enable and promote GitOps Working Group community values -- Engage with the wider GitOps community through appropriate [communication channels](./README.md#how-to-get-involved) +- Engage with the wider GitOps community through appropriate [communication channels](https://github.com/cncf/tag-app-delivery/blob/main/gitops-wg/README.md#community) - Maintain involvement and open collaboration with working group members and committees - Review and approve pull requests - Ask for help when unsure and step down considerately when appropriate From f510d2ecc6c679e812a32bd1aa1ee15faf8c87e5 Mon Sep 17 00:00:00 2001 From: Scott Rigby Date: Fri, 17 Dec 2021 19:39:10 -0500 Subject: [PATCH 10/13] Update link and description to new chairs file location Signed-off-by: Scott Rigby --- GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 34e60c3..e6b7c74 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -52,7 +52,7 @@ The GitHub `@gitops-working-group/maintainers` team will be kept up to date with The GitOps WG and OpenGitOps project will be co-chaired by 3 [Maintainers](#maintainers). A maximum of one person from any one entity may hold a chair role at any given moment in order to avoid undue influence, and maintain balanced representation. -Current chairs are listed in a [CHAIRS.md](./CHAIRS.md) file at the root of this git repository. +Current chairs are listed in a [CHAIRS.md](https://github.com/cncf/tag-app-delivery/blob/main/gitops-wg/CHAIRS.md) file in the GitOps Working Group directory of the CNCF App Delivery TAG git repository. Responsibilities: From e9a578b75ccfcef1fd53a865a646c0de23fe2682 Mon Sep 17 00:00:00 2001 From: Scott Rigby Date: Fri, 17 Dec 2021 19:39:35 -0500 Subject: [PATCH 11/13] Fix markdown mailto link See https://github.github.com/gfm/#example-612 Signed-off-by: Scott Rigby --- GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index e6b7c74..a6e6c8d 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -78,7 +78,7 @@ The GitHub `@gitops-working-group/chairs` team will be kept up to date with curr [Chairs](#chairs) will be elected for one year terms and may run for reelection. -The election process takes place on the CNCF SIG App Delivery [mailing list](cncf-sig-app-delivery@lists.cncf.io ). +The election process takes place on the CNCF SIG App Delivery mailing list . Before each election, there will be a call for nominations on the mailing list. Nominations should be sent to the mailing list, and include a brief bio and personal statement describing the candidate's qualifications to serve in this capacity. From 724cdf3dab2bcba07fd846c1e9d3d5967a363186 Mon Sep 17 00:00:00 2001 From: Scott Rigby Date: Fri, 17 Dec 2021 19:39:52 -0500 Subject: [PATCH 12/13] Update link to interested parties doc Signed-off-by: Scott Rigby --- GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index a6e6c8d..f1f0cf6 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -85,7 +85,7 @@ Nominations should be sent to the mailing list, and include a brief bio and pers Self-nominations are welcome. Only existing maintainers are eligible for nomination. The GitOps WG employs "organization voting" to ensure no single organization can dominate the election process or project. -Up to two individuals from organizations who are both active members of the CNCF and listed in the [interested parties](interested-parties.md) may vote. +Up to two individuals from organizations who are both active members of the CNCF and listed in the [interested parties](https://github.com/cncf/tag-app-delivery/blob/main/gitops-wg/interested-parties.md) may vote. Interested parties must be added at least one week before any election to have a vote. Chairs will be elected using Ranked Choice Voting. From ef817e94bbba2d23cd4969310d0cb0a327ab6789 Mon Sep 17 00:00:00 2001 From: Scott Rigby Date: Fri, 17 Dec 2021 19:40:04 -0500 Subject: [PATCH 13/13] ew location for community involvement info Signed-off-by: Scott Rigby --- GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index f1f0cf6..6b1dd2c 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -108,7 +108,7 @@ Representatives elected though this process will serve the remaining part of the ### Decision Guidelines - The GitOps Working Group believes that the best decisions are reached through Consensus . - This applies to all working communication by WG members (see [How To Get Involved](README.md#how-to-get-involved)). + This applies to all working communication by WG members (see [GitOps WG community info](https://github.com/cncf/tag-app-delivery/blob/main/gitops-wg/README.md#community)). - Most decisions begin by seeking Lazy Consensus . - If an objection is raised through the Lazy Consensus process, the group works together to seek an agreeable solution. - If Consensus can not be reached, but a decision must be made, the next step is try to attempt to agree that a vote should be called.