# Emissary Ingress Governance

This document defines the project governance for Emissary Ingress.

## Overview

**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)

## Community Roles

* **Users:** Members that engage with the Emissary Ingress community via any medium (Slack, GitHub, mailing lists, etc.).
* **Contributors:** Regular contributions to projects (documentation, code reviews, responding to issues, participation in proposal discussions, contributing code, etc.).
* **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.

### Maintainers

New 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.

If 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.

### Decision Making

Ideally, 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.

### Supermajority

A supermajority is defined as two-thirds of members in the group.

A supermajority of [Maintainers](#maintainers) is required for adding or removing maintainers.

### Voting Process

Voting on decisions will be conducted using GitHub:

- Open an issue, if an appropriate issue is not already present.
- Write a description of the issue at hand in a comment on the issue. The description must include:
   - A summary of the vote to be taken;
   - Whether the vote requires a majority or a supermajority; and
   - The meaning of a yay vote and a nay vote, if not obvious.

   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.
- Maintainers vote by placing emoji on the comment: :thumbsup: for yay, :thumbsdown: for nay.

## Updating Governance

All substantive changes in Governance require a supermajority agreement by all maintainers.
