tldr/GOVERNANCE.md

Project governance

The tldr-pages project strives to have an open, welcoming, and non-hierarchical governance structure.

To that end, this document describes the principles that guide the self-management of the project. By having them written down explicitly, and open to scrutiny, the entire community can read, apply, improve and adapt them as needed, with no central authority.

I. Participation and community interactions

• All contributions are welcome, no matter how small. The tldr-pages project is a do-ocracy, so don't hesitate to get involved — we're happy to welcome you into the community! Please take a look at CONTRIBUTING.md to get started.

• All discussions should be respectful and cordial. Avoid making assumptions about the others' intentions, and make your own intentions clear. When in doubt, provide additional context, or ask for clarification. Remember, it's very hard to convey meaning on a purely written medium, especially between people from different cultures, technical backgrounds, English proficiency levels, etc.

• All communications are public. There are no permanent private channels where maintainers discuss "internal" matters. Occasional private chat or email messages may be exchanged, e.g. when setting up services that require passwords, but otherwise all communications that impact the project will either happen in issue and PR discussions, or in the Gitter chat room (which is open to all, and publicly logged).

• All decisions are made by community consensus. This does not mean there has to be unanimity, nor that decisions result from vote counts. What it means is that every interested member of the community is welcome to voice their thoughts, and incompatible positions are ideally resolved with involved participants either agreeing with the final decision, or voluntarily consenting to it as "good enough for now, safe enough to try".

II. Role transitions

The following guidelines aim to keep the project vibrant and responsive, by ensuring a smooth transition flow between community roles — from newcomer, to occasional contributor, to regular contributor, to maintainer. This way, the project should be able to adapt dynamically and flexibly to the natural variations in availability and interest of its contributors, improving long-term resilience, reducing the risk of burnout, and avoiding single points of failure.

To this end, rather than assigning roles and tasks to people, these guidelines aim to recognize the work that people already do. Everyone is therefore encouraged to get involved and contribute to the project in whatever way they prefer, and we will strive to get barriers out of the way of these contributions.

To ensure that these role transitioning processes are straightforward, transparent, predictable, and impartial, the metrics used are objective, easy to check, and explicitly described below. (That's not to say they're hard-set rules: exceptions can always be considered, via open community discussion.)

• Regular contributors should be added as collaborators in the repository. Specifically: once a contributor has had 5 non-trivial pull requests merged on a repository under the tldr-pages organization, they should be invited to become a collaborator in that repository. This means they will be able to push commits to that repository, as well as merge PRs, label and close issues, among other things.

• Collaborators who perform maintenance tasks should be made org members. (Maintenance work is understood as facilitating contributions by other people, which in this project consists primarily of reviewing and/or merging PRs.) Specifically: once a repository collaborator has merged at least 10 PRs and submitted at least 5 non-trivial reviews to PRs (either the same or different ones) they should be invited to become a member of the tldr-pages organization. This means they will be able to push commits to all of the organization's repositories, merge PRs, label and close issues, among other things. Note: All members of the tldr-pages organization must make their membership public.

• Maintainers who have been helping out for a while should become org owners. Specifically: members of the tldr-pages organization who remain active for at least 6 months should be invited to become an owner of the tldr-pages organization. This means they will be able to add people to the organization, manage all the organization's repositories, configure integrations, etc. They should also be added to the list of current maintainers in the MAINTAINERS.md file.

• These roles are temporary, and that's OK. People's interests and availability naturally change over time, so the project should regularly update the list of people in each role, in order to accurately reflect the active team managing the project (and to avoid conveying an undue sense of obligation on people whose priorities have shifted.) Specifically: If an organization member becomes inactive for over 6 months, their membership status should be equally deactivated and their name added to the list of former maintainers in the MAINTAINERS.md file. (They should nevertheless remain as collaborators in the repositories on which they have been active in the past.) Again, this is and merely a reflection of their actual involvement with the project, not a demotion or punishment. Indeed, if they return to active participation in the project, they should be added back to the organization, to reflect that fact.