Skip to content

Latest commit

 

History

History
46 lines (27 loc) · 3.08 KB

GOVERNANCE.md

File metadata and controls

46 lines (27 loc) · 3.08 KB

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

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 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: 👍 for yay, 👎 for nay.

Updating Governance

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