chore: Updating Governance policy and memebership roles (#5016)

.github/ISSUE_TEMPLATE/maintainer.md

@@ -0,0 +1,33 @@
+---
+name: Organization Maintainer Request
+about: Request to become a maintianer in LitmusChaos Org
+title: "REQUEST: Promote <your-GH-handle> to maintainer for LitmusChaos"
+labels: type/maintainer-request
+assignees: ""
+---
+
+### GitHub Username
+
+@<your-GH-handle>
+
+### Requirements
+
+- [ ] I have reviewed [the community role guidelines](/community-roles.md)
+- [ ] I have [enabled 2FA on my GitHub account](https://github.com/settings/security)
+- [ ] I am an active member of 1 or more LitmusChaos subprojects for atleast the last 6 months.
+- [ ] I am an active participant in issue/PR reviews for atleast 2 subprojects and for the past 6 months.
+- [ ] I have been involved in technical and project discussions with other maintainers.
+- [ ] I have atleast one sponsor that meet the sponsor requirements listed in the community role guidelines
+- [ ] I have spoken to my sponsor ahead of this application, and they have agreed to sponsor my application
+- [ ] I understand that I can [make my membership public](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-your-membership-in-organizations/publicizing-or-hiding-organization-membership) if I'd like to once I am invited to the organization
+
+### Sponsors
+
+- @<sponsor-1>
+- @<sponsor-2>
+
+### List of contributions to the Argoproj project
+
+- PRs reviewed / authored
+- Issues responded to
+- Projects I am involved with

.github/ISSUE_TEMPLATE/member.md

@@ -0,0 +1,31 @@
+---
+name: Organization Member Request
+about: Request membership in LitmusChaos Org
+title: "REQUEST: New member request for <your-GH-handle>"
+labels: type/member-request
+assignees: ""
+---
+
+### GitHub Username
+
+@<your-GH-handle>
+
+### Requirements
+
+- [ ] I have reviewed [the community role guidelines](/community-roles.md)
+- [ ] I have [enabled 2FA on my GitHub account](https://github.com/settings/security)
+- [ ] I am actively contributing to 1 or more LitmusChaos subprojects
+- [ ] I have atleast one sponsor that meet the sponsor requirements listed in the community role guidelines
+- [ ] I have spoken to my sponsor ahead of this application, and they have agreed to sponsor my application
+- [ ] I understand that I can [make my membership public](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-your-membership-in-organizations/publicizing-or-hiding-organization-membership) if I'd like to once I am invited to the organization
+
+### Sponsors
+
+- @<sponsor-1>
+- @<sponsor-2>
+
+### List of contributions to the Argoproj project
+
+- PRs reviewed / authored
+- Issues responded to
+- Projects I am involved with

.github/ISSUE_TEMPLATE/reviewer.md

@@ -0,0 +1,33 @@
+---
+name: Organization Reviewer Request
+about: Request reviewer membership in LitmusChaos Org
+title: "REQUEST: Promote <your-GH-handle> to reviewer for LitmusChaos"
+labels: type/reviewer-request
+assignees: ""
+---
+
+### GitHub Username
+
+@<your-GH-handle>
+
+### Requirements
+
+- [ ] I have reviewed [the community role guidelines](/community-roles.md)
+- [ ] I have [enabled 2FA on my GitHub account](https://github.com/settings/security)
+- [ ] I am an active member of 1 or more LitmusChaos subprojects for atleast the last 3 months.
+- [ ] I am an active participant in issue/PR reviews for atleast 1 month.
+- [ ] I have reviewed or authored atleast 5 significant PRs.
+- [ ] I have atleast one sponsor that meet the sponsor requirements listed in the community role guidelines
+- [ ] I have spoken to my sponsor ahead of this application, and they have agreed to sponsor my application
+- [ ] I understand that I can [make my membership public](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-your-membership-in-organizations/publicizing-or-hiding-organization-membership) if I'd like to once I am invited to the organization
+
+### Sponsors
+
+- @<sponsor-1>
+- @<sponsor-2>
+
+### List of contributions to the Argoproj project
+
+- PRs reviewed / authored
+- Issues responded to
+- Projects I am involved with

GOVERNANCE.md

@@ -1,130 +1,79 @@
 # LitmusChaos Project Governance
 
+This document outlines the governance structure for the LitmusChaos project, a CNCF Incubating project. It describes the roles, responsibilities, decision-making processes, and mechanisms for community involvement.
+
 We abide by the [Code of Conduct](./CODE_OF_CONDUCT.md) for all the projects maintained under the LitmusChaos Organization.
 
 For specific guidance on practical contribution steps for any LitmusChaos sub-project please
-see our [CONTRIBUTING.md](./CONTRIBUTING.md) guide and the sub-project specific contributing guides 
+see our [CONTRIBUTING.md](./CONTRIBUTING.md) guide and the sub-project specific contributing guides
 in the respective GitHub repositories.
 
-## Maintainership
-
-There are different types of maintainers, with different responsibilities, but
-all maintainers have 3 things in common:
-
-1) They share responsibility in the project's success.
-2) They have made a long-term, recurring time investment to improve the project.
-3) They spend that time doing whatever needs to be done, not necessarily what
-is the most interesting or fun.
-
-Maintainers are often under-appreciated, because their work is harder to appreciate.
-It's easy to appreciate a really cool and technically advanced feature. It's harder
-to appreciate the absence of bugs, the slow but steady improvement in stability,
-or the reliability of a release process. But those things distinguish a great
-project from a good one.
-
-## Reviewers
+## Roles and Membership
 
-A reviewer is a core role within the project.
-They share in reviewing issues and pull requests and their LGTM counts towards the
-required LGTM count to merge a code change into the project.
+Roles and their responsibilities are detailed in the [Community Membership](./community-roles.md) document.
 
-Reviewers are part of the organization but do not have write access.
-Becoming a reviewer is a core aspect in the journey to becoming a maintainer.
+The list of current maintainers and their organizational affiliations is maintained in the [MAINTAINERS.md](./MAINTAINERS.md) file.
 
-## Adding maintainers
+## Conflict Resolution and Voting
 
-Maintainers are first and foremost contributors that have shown they are
-committed to the long term success of a project. Contributors wanting to become
-maintainers are expected to be deeply involved in contributing code, pull
-request review, and triage of issues in the project for more than three months.
+Most issues within the project are resolved by consensus. When consensus cannot be reached, a voting process is initiated. All decisions are documented publicly, either in GitHub or in meeting notes.
 
-Just contributing does not make you a maintainer, it is about building trust
-with the current maintainers of the project and being a person that they can
-depend on and trust to make decisions in the best interest of the project.
-
-Periodically, the existing maintainers curate a list of contributors that have
-shown regular activity on the project over the prior months. From this list, 
-candidates are selected and proposed as maintainers.
-
-After a candidate has been proposed as maintainer via a Pull Request by any of 
-the existing maintainers, the other maintainers are given five business days 
-to discuss the candidate, raise objections and cast their vote. 
-The Votes take place via the pull request comment. Candidates must be approved by at 
-least 66% of the current maintainers by adding their vote on the mailing list. 
-The reviewer role has the same process but only requires 33% of current maintainers. 
-Only maintainers of the repository that the candidate is proposed for are allowed to 
-vote. The candidate becomes a maintainer once the pull request is merged.
-
-## Adding sub-projects
+### Voting Process
 
-Similar to adding maintainers, new sub projects can be added to LitmusChaos
-GitHub organization as long as they adhere to the LitmusChaos vision and mission. 
-New projects are discussed in either the Contributor Meeting or the Community 
-slack and requires at least 1 maintainer approval.
+- **Threshold:** A vote passes with a simple majority.
+- **Quorum:** At least 30% of maintainers must participate in the vote.
+- **Voting Method:** Votes are cast by adding +1 or -1 to the associated GitHub issue or PR.
+- **Binding Votes:** Each maintainer has one binding vote. Non-binding votes from the community are encouraged.
+- **Organizational Limit:** No single organization can cast more than 40% of the eligible votes. Organizations with more than 40% of maintainers must designate voting members.
+- **Duration:** Voting remains open for one week.
 
-If a project is approved, a maintainer will add the project to the LitmusChaos
-GitHub organization, and make an announcement on a public forum.
+## How are decisions made?
 
-## Stepping down policy
+LitmusChaos is an open-source project with an open design philosophy. This means
+that the repository is the source of truth for EVERY aspect of the project,
+including its philosophy, design, road map, and APIs. _If it's part of the
+project, it's in the repo. If it's in the repo, it's part of the project._
 
-Life priorities, interests, and passions can change. If you're a maintainer but
-feel you must remove yourself from the list, inform other maintainers that you
-intend to step down, and if possible, help find someone to pick up your work.
-At the very least, ensure your work can be continued where you left off.
+As a result, all decisions can be expressed as changes to the repository. An
+implementation change is a change to the source code. An API change is a change
+to the API specification. A philosophy change is a change to the philosophy
+manifesto, and so on.
 
-After you've informed other maintainers, create a pull request to remove
-yourself from the MAINTAINERS file.
+All decisions affecting LitmusChaos, big and small, follow the same 3 steps:
 
-## Removal of inactive maintainers
+- Step 1: Open a pull request. Anyone can do this.
+- Step 2: Discuss the pull request. Anyone can do this.
+- Step 3: Merge or refuse the pull request. Who does this depends on the nature
+  of the pull request and which areas of the project it affects.
 
-Similar to the procedure for adding new maintainers, existing maintainers can
-be removed from the list if they do not show significant activity on the
-project. Periodically, the maintainers review the list of maintainers and their
-activity over the last three months.
+## Decision-Making Process
 
-If a maintainer has shown insufficient activity over this period, a neutral
-person will contact the maintainer to ask if they want to continue being
-a maintainer. If the maintainer decides to step down as a maintainer, they
-open a pull request to be removed from the MAINTAINERS file.
+Most decisions are made through consensus. If consensus cannot be reached, maintainers may initiate a vote.
 
-## Emeritus maintainers
+### Voting
 
-For committers who are stepping down or being removed due to inactivity,
-the project would like to memorialize their contributions to the project by
-recognizing them as Emeritus maintainers in the EMERITUS.md file. The EMERITUS.md
-file will include a brief paragraph summarizing their contribution to the
-containerd project and recognize them as permanent Emeritus members of the
-community. While Emeritus maintainers are not active in the project, their
-expertise is always valued and their LGTM may count towards the required LGTM
-count to merge a code change into the project.
+- **Threshold:** A vote passes with a simple majority.
+- **Quorum:** At least 30% of maintainers must participate in the vote.
+- **Method:** Votes are cast using +1 (approve) or -1 (reject) in the relevant GitHub PR or issue.
+- **Duration:** Voting remains open for one week.
 
-If in the future an Emeritus maintainer has the desire or ability to return to
-contributing to the project, Emeritus maintainers can submit a pull request
-reversing their removal from the MAINTAINERS file and approval only requires
-2 LGTMs from current committers to return to full committer status in the
-project.
+## Community Support and Transparency
 
+LitmusChaos aims for full transparency and inclusion in all governance activities. All decisions are made publicly and documented in the GitHub repositories or public meetings.
 
-## How are decisions made?
+### Recurring Public Meetings
 
-LitmusChaos is an open-source project with an open design philosophy. This means
-that the repository is the source of truth for EVERY aspect of the project,
-including its philosophy, design, road map, and APIs. *If it's part of the
-project, it's in the repo. If it's in the repo, it's part of the project.*
+- #### Maintainers and Contributors Meeting
 
-As a result, all decisions can be expressed as changes to the repository. An
-implementation change is a change to the source code. An API change is a change
-to the API specification. A philosophy change is a change to the philosophy
-manifesto, and so on.
+  Covers technical issues, future milestones, and roadmaps. Also focused on governance, membership, and the future direction of the project.
 
-All decisions affecting LitmusChaos, big and small, follow the same 3 steps:
+- #### Community Meeting
 
-* Step 1: Open a pull request. Anyone can do this.
+  Engages end users and the community with project updates, user presentations, and open discussions.
 
-* Step 2: Discuss the pull request. Anyone can do this.
+- #### Meeting Calendar
 
-* Step 3: Merge or refuse the pull request. Who does this depends on the nature
-of the pull request and which areas of the project it affects.
+  Please fill [this invite form](https://forms.gle/AsuXB2hbTG2TyD2d9) to be added to the calendar
 
 ## Helping contributors with the DCO
 
@@ -148,10 +97,12 @@ When you add someone's DCO, please also add your own to keep a log.
 Yes. Nobody should ever push to master directly. All changes should be
 made through a pull request.
 
-## Conflict Resolution
+## Adding sub-projects
+
+Similar to adding maintainers, new sub projects can be added to LitmusChaos
+GitHub organization as long as they adhere to the LitmusChaos vision and mission.
+New projects are discussed in either the Contributor Meeting or the Community
+slack and requires at least 1 maintainer approval.
 
-If you have a technical dispute that you feel has reached an impasse with a
-subset of the community, any contributor may open an issue, specifically
-calling for a resolution vote of the current maintainers to resolve the dispute.
-The same voting quorums required (2/3) for adding and removing maintainers
-will apply to conflict resolution.
+If a project is approved, a maintainer will add the project to the LitmusChaos
+GitHub organization, and make an announcement on a public forum.