This doc outlines the various responsibilities of contributor roles in Schrödinger Hat.
New contributors should be welcomed to the community by existing contributors, helped with PR workflow, and directed to relevant documentation and communication channels.
Established contributors are expected to demonstrate their adherence to the principles in this document, familiarity with project organization, roles, policies, procedures, conventions, etc. Role-specific expectations, responsibilities, and requirements are enumerated below.
Contributors are continuously active members of the community. Contributors are expected to remain active in the community.
Defined by: Contributor of the Schrödinger Hat GitHub organization and assigned to the Contributor role in the Discord server.
- Enabled two-factor authentication on their GitHub account
- Have made multiple contributions to projects or community. Contribution may include, but is not limited to:
- Authoring or reviewing PRs on GitHub. At least one PR must be merged
- Filling or commenting on issues on GitHub
- Contributing to project, or community discussion (e.g. meetings, Discord)
- Have read the contributor guide
- Sponsored by 2 contributors
- Open an issue against this repository
- Ensure your sponsors are @mentioned on the issue
- Complete every item on the checklist
- Have your sponsoring reviewers reply confirmation of sponsorship:
+1
- Once your sponsors have responded, your request will be reviewed by the Schrödinger Hat Admin team. Any missing information will be requested.
- Responsive to issues and PRs assigned to them
- Active owner of code they have contributed (unless ownership is explicity transferred)
- Code is well tested
- Tests consistently pass
- Addresses bugs or issues discovered after code is accepted
- Contributors can approve open PRs
- Access limited Discord channels
Note: This is a generalized high-level description of the role, and the specifics of the project owner role's responsibilities and related processes MUST be defined for individual prijects. A project can contain different subprojects with different Project Owners.
Project Owners are the technical authority for a project in the Schrödinger Hat community. They MUST have demonstrated both good judgement and responsibility towards the health of that project. Project Owners MUST set technical direction and make or approve design decisions for their project - either directly or through delegation of these responsibilities.
Defined by: entry in the CODEOWNERS files
The process for becoming a Project Owner should be defined in the project itself.
The following apply to the projet for which one would be an owner.
- Deep understanding of the technical goals and direction of the subproject
- Deep understanding of the technical domain of the project
- Sustained contributions to design and direction by doing all of:
- Authoring and reviewing proposals
- Initiating, contributing and resolving discussions (emails, GitHub issues, meetings)
- Identifying subtle or complex issues in designs and implementation PRs
- Directly contributed to the project through implementation and / or review
- Make and approve technical design decisions for the project.
- Set technical direction and priorities for the project.
- Define milestones and releases.
- Mentor and guide approvers, reviewers, and contributors to the project.
- Ensure continued health of project
- 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 project owners to maintain the project's overall health and success holistically
Contributors are continuously active members of the community.
A core principle in maintaining a healthy community is encouraging active participation. It is inevitable that people's focuses will change over time and they are not expected to be actively contributing forever.
However, being a Contributor of Schrödinger Hat comes with an elevated set of permissions. These capabilities should not be used by those that are not familiar with the current state of the community.
Therefore Contributors with an extended period away from the community with no activity inside of it will be removed and will be required to go through the community membership process again after re-familiarizing themselves with the current state.