1# Emissary Ingress Governance
2
3This document defines the project governance for Emissary Ingress.
4
5## Overview
6
7**Emissary Ingress** is an open source project that is committed to building a thriving community. This document outlines how the community governs itself. All community members must adhere to the [Code of Conduct](CODE_OF_CONDUCT.md)
8
9## Community Roles
10
11* **Users:** Members that engage with the Emissary Ingress community via any medium (Slack, GitHub, mailing lists, etc.).
12* **Contributors:** Regular contributions to projects (documentation, code reviews, responding to issues, participation in proposal discussions, contributing code, etc.).
13* **Maintainers**: The Emissary Ingress project leaders. They are responsible for the overall health and direction of the project; final reviewers of PRs and responsible for releases. Maintainers are expected to triage issues, proactively fix bugs, review PRs to ensure code quality, and contribute documentation.
14
15### Maintainers
16
17New maintainers must be nominated by an existing maintainer and must be elected by a supermajority of existing maintainers. Likewise, maintainers can be removed by a supermajority of the existing maintainers or can resign by notifying one of the maintainers.
18
19If you're interested in becoming a maintainer, contact an existing maintainer to express your interest. A good way to start is to fix some small issues (if you haven't already), working with one or more existing maintainers. As you build up a representative body of contributions, the maintainers will provide regular feedback on your progress towards maintainer status. After you have built up that representative body of contributions (usually over a period of 3-4 months), the maintainers will meet to discuss and vote on granting maintainer status.
20
21### Decision Making
22
23Ideally, all project decisions are resolved by consensus. If impossible, any maintainer may call a vote. Unless otherwise specified in this document, any vote will be decided by a majority of maintainers.
24
25### Supermajority
26
27A supermajority is defined as two-thirds of members in the group.
28
29A supermajority of [Maintainers](#maintainers) is required for adding or removing maintainers.
30
31### Voting Process
32
33Voting on decisions will be conducted using GitHub:
34
35- Open an issue, if an appropriate issue is not already present.
36- Write a description of the issue at hand in a comment on the issue. The description must include:
37 - A summary of the vote to be taken;
38 - Whether the vote requires a majority or a supermajority; and
39 - The meaning of a yay vote and a nay vote, if not obvious.
40
41 For example, when voting to add a maintainer, the meanings of yay and nay are straightforward. On the other hand, for a choice between two alternatives, the comment should spell out which alternative is supported by a yay vote, and which by a nay vote.
42- Maintainers vote by placing emoji on the comment: :thumbsup: for yay, :thumbsdown: for nay.
43
44## Updating Governance
45
46All substantive changes in Governance require a supermajority agreement by all maintainers.
View as plain text