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 can voice their thoughts, and different positions are ideally resolved via informed consent of the involved people, who accept the collective decision as "good enough for now, safe enough to try".

II. Role transitions

The main goal of these principles is to encourage a continuous replenishing of the management team via a smooth transition flow between community roles — from newcomer, to occasional contributor, to regular contributor, to maintainer. This way the project can adapt in a flexible way to the the natural variations in availability and interest of its contributors, ensuring long-term resilience, and avoiding single points of failure.

To this end, rather than assigning roles and tasks to people, these guidelines instead 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.

• Regular contributors shall be recognized as collaborators in the organization.

  • Specifically: once a contributor has had 5 pull requests merged, 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.

• Members of the organization who demonstrate interest in performing maintainership tasks, by reviewing and/or merging PRs, responding to and labeling issues, and generally doing project maintenance work, shall be made part of the maintenance team, and their name added to the list of current maintainers in the MAINTAINERS.md file.

  • Specifically: once a contributor has been an organization member for at least 3 months, and has reviewed or merged 10 pull requests by other contributors, they 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.

• If a collaborator or maintainer stops being active in the project for more than 6 months, their membership status should be equally ceased and their name added to the list of former maintainers in the MAINTAINERS.md file. 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.

  • This inactivity threshold additionally ensures that the list of organization members doesn't grow to unwieldy sizes, and that it accurately reflects the active team managing the project.