Skip to content

Latest commit

 

History

History
159 lines (122 loc) · 11.1 KB

GOVERNANCE.md

File metadata and controls

159 lines (122 loc) · 11.1 KB

Drasi Governance and Community Membership

This document details the governance policies for the Drasi project and outlines the responsibilities of contributor roles in Drasi. The Drasi project includes the platform and core components, SDKs, CLI, samples, QuickStart tutorials, and docs. Responsibilities for roles are scoped to each repo.

Code of Conduct

This project has adopted the Contributor Covenant Code of Conduct.

Project Roles

Project Role Responsibilities Requirements Defined by
Member Active contributor in the community. Reviewer of PRs Sponsored by two approvers or maintainers. Multiple contributions to the project. Drasi GitHub org member
Approver Approve accepting contributions Highly experienced and active reviewer and contributor to a subproject. CODEOWNERS in GitHub
Maintainer Set direction and priorities for a subproject Demonstrated responsibility and excellent technical judgement for the subproject. CODEOWNERS, GitHub Team and repo ownership in GitHub

Member

Members are continuously active contributors in the community. They can have issues and PRs assigned to them. Members are expected to participate in community discussions and remain active contributors to the community.

Defined by: Member of the Drasi GitHub organization

Requirements

  • Enabled two-factor authentication on their GitHub account
  • Have made multiple contributions to the project or community. Contributions may include, but is not limited to:
    • Authoring or reviewing PRs on GitHub
    • Filing or commenting on issues on GitHub
    • Contributing to sub-projects, or community discussions (e.g. meetings, chat, etc.)
  • Joined the Discord server
  • Have read the contributor guide
  • Actively contributing to 1 or more sub-projects
  • Sponsored by two approvers or maintainers (sponsors). Note the following requirements for sponsors:
    • Sponsors must have close interactions with the prospective member - e.g. code/design/proposal review, coordinating on issues, etc
    • Sponsors must be approvers or maintainers in at least one repo in the Drasi org
  • Open an issue against the Drasi/community repo
    • Ensure your sponsors are @mentioned on the issue
    • Complete every item on the checklist preview the current version of the template
    • Make sure that the list of contributions included is representative of your work on the project
  • Have your sponsoring reviewers reply confirmation of sponsorship: +1
  • Once your sponsors have responded, your request will be reviewed by the Drasi Maintainers. Any member of the Maintainers team can review the requirements and add members to the GitHub org

Responsibilities and privileges

  • Responsive to issues and PRs assigned to them
  • Active owner of code contributed by them (unless ownership is explicitly transferred)
    • Code is well tested
    • Tests consistently pass
    • Addresses bugs or issues discovered after code is accepted
    • Members are encouraged to review and approve via the GitHub workflow. This review work, while not sufficient to merge a PR, does accrue toward the Member becoming an Approver. Merge approval and final review are performed by an Approver
  • Members can be assigned to issues and PRs, and people can ask members for reviews with a /cc @username

Approver

Code approvers can both review and approve code contributions, as well as help maintainers triage issues and do project management.

While code review is focused on code quality and correctness, approval is focused on holistic acceptance of a contribution including backwards/forwards compatibility, adhering to API and conventions, performance and correctness issues, interactions with other sub-projects, etc.

Approver status can be scoped to a part of the codebase. For example, critical core components may have higher bar for becoming an approver.

Requirements

The following apply to the part of the codebase for which one would be an Approver:

  • Reviewer of the codebase for at least 1 month
  • Reviewer for at least 5 substantial PRs to the codebase, with the definition of substantial area to the maintainer's discretion (e.g. refactors/adds new functionality rather than one-line pulls)
  • Nominated by a maintainer from the repository in which the nomination is applied to:
    • With an approving vote of at least 2 maintainers from the repository maintainers. In the case of a repository with a solo maintainer, a single vote suffices.
    • With no objections from other repository maintainers for a period of one week.
    • Maintainers team acts as the final resolution to any escalation.

Responsibilities and privileges

The following apply to the part of the codebase for which one would be an approver in the CODEOWNERS files:

  • Approver status may be a precondition to accepting large code contributions
  • Demonstrate sound technical judgement (may be asked to step down by a maintainer if they lose confidence of the maintainers)
  • Responsible for project quality control via code reviews
    • Focus on holistic acceptance of contribution such as dependencies with other features, backwards / forwards compatibility, API and conventions, etc
  • Expected to be responsive to review requests (inactivity for more than 1 month may result in suspension until active again)
  • Mentor contributors and reviewers
  • May approve code contributions for acceptance
  • Inactivity for more than 3 months leads to a removal vote by other maintainers/approvers and not an automatic removal

Maintainer

Maintainers are the technical authority for a subproject in the Drasi org. They MUST have demonstrated both good judgement and responsibility towards the health of that subproject. Maintainers MUST set technical direction and make or approve design decisions for their subproject - either directly or through delegation of these responsibilities.

Defined by: GitHub organization ownership, permissions and membership in the Maintainers team.

Requirements

The following apply to the project for which one would be an owner in the CODEOWNERS files:

  • Deep understanding of the technical goals and direction of the subproject
  • Deep understanding of the technical domain (specifically the language) of the project
  • Sustained contributions to design and direction by doing all of:
    • Authoring and reviewing proposals
    • Initiating, contributing and resolving discussions (e.g. emails, GitHub issues, meetings)
    • Identifying subtle or complex issues in designs and implementation PRs
  • Directly contributed to the project through implementation and / or review

Responsibilities and privileges

The following apply to the repos for which one would be an owner:

  • Make and approve technical design decisions for the project
  • Set technical direction and priorities for the project
  • Define milestones and releases
    • Decides on when PRs are merged to control the release scope
  • Mentor and guide approvers and contributors to the project
  • Escalate approver and maintainer workflow concerns (i.e. responsiveness, availability, and general contributor community health) to the TC
  • Ensure continued health of subproject:
    • Adequate test coverage to confidently release
    • Tests are passing reliably (i.e. not flaky) and are fixed when they fail
  • Ensure a healthy process for discussion and decision making is in place
  • Work with other maintainers to maintain the project's overall health and success holistically

Maintainers MUST remain active. If they are unresponsive for >3 months, they will be automatically removed unless a super-majority of the other repository maintainers agrees to extend the period to be greater than 3 months.