Project Roles
We aim to have clearly-defined roles and expectations for each open source project that ROOST hosts. This is not intended to be overly prescriptive, but should make it clear what ROOST does, what a maintainer does, etc. while leaving room to grow and adapt over time.
ROOST
ROOST is the non-profit host and facilitator of open source trust and safety projects. We contribute infrastructure (code hosting, communication channels), industry connections (bringing together other open source projects, platform operators, T&S experts, model creators), subject matter experts (across both T&S and open source) and some engineering resources (via staff or contracted engineers).
As the host of the open source repositories, ROOST technically has ultimate administrative control over the repositories themselves; however, the projects are released under open source licenses and thus may be forked by anyone. This provides a very real check on that control as it ensures ROOST must continue to provide the best environment for contributors and work in their interests.
Technical Design Committee
The ROOST Technical Design Committee (TDC) is appointed by the ROOST board and is composed of individuals with relevant industry experience. They facilitate the overarching technical direction and roadmap of our open source efforts in consultation with ROOST and project maintainers.
Maintainer(s)
Each open source project hosted by ROOST has one or more maintainer who is ultimately responsible for day-to-day development and decision making. This is often but not necessarily the lead developer of each project, as a maintainer may be more of a facilitator or steward than the person writing the majority of the code.
Maintainers are responsible for defining the specifics of the project’s roadmap, project management, and release management in alignment with the overarching roadmap defined by the TDC. Maintainers have commit access (within the branch protection parameters defined by ROOST), and thus determine what code gets merged in on an ongoing basis.
Maintainers are initially appointed by ROOST, and may be an individual or a team of individuals. If a team, decision-making is done on a rough consensus basis, with the TDC available for consultation or tie-breaking if necessary. Decisions are recorded in the project’s issue tracker for transparency.
Maintainers are publicly defined in the project’s CODEOWNERS file for transparency and to aid with automated permissions handling. Maintainers may appoint additional or replacement maintainers at their discretion. Ultimately ROOST may remove/appoint a new maintainer in the case of inactivity, a vacancy, or misconduct, though we would expect that case to be exceptionally rare.
Teams
As the community grows (and should the need arise), ROOST may define “teams” which are groups of individuals with a shared interest and domain. Teams may be granted specific authority such as maintainership or decision-making capability within their domain.
Contributors
Anyone who has demonstrated the interest and ability to contribute to a project may be considered a “contributor.” Contributors may propose changes to a project by starting a discussion, filing an issue, and/or opening a pull request which must be approved by a maintainer before it is merged.
Regular contributors who have had multiple or significant contributions merged into a project are strong contenders to be appointed as a maintainer or co-maintainer if the need arises.
Community
Community members include anyone who interacts with ROOST projects across our spaces including Discord and GitHub. They do not have any explicit permissions, but are consulted for discussions, vibe checks, and open meetings.
Partners/organizations
ROOST open source projects generally operate on an individual contributor/maintainer basis; that is, while a specific organization may employ a contributor or maintainer, organizations themselves are not considered the contributor or maintainer by default. This does not prevent ROOST or those organizations from championing and publicizing their involvement, but it helps clarify expectations, especially in the case of a change in employment.
ROOST may create a GitHub team on the ROOST org for partner organizations to aid with permissions management/access control, e.g. for early access to repositories that are not yet public.