tldr/GOVERNANCE.md

# Project governance

The tldr-pages project strives to have an **open**, **welcoming**,
and [**non-hierarchical**](https://en.wikipedia.org/wiki/Flat_organization)
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](https://github.com/kentcdodds/all-contributors).
  The tldr-pages project is a
  [do-ocracy](https://communitywiki.org/wiki/DoOcracy),
  so don't hesitate to get involved
  — we're happy to welcome you into the community!
  Please take a look at [CONTRIBUTING.md](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](https://gitter.im/tldr-pages/tldr)
  (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](https://en.wikipedia.org/wiki/Sociocracy#Consent_vs._consensus)
  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](https://en.wikipedia.org/wiki/Bus_factor).

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**](https://github.com/orgs/tldr-pages/people)
  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**](https://help.github.com/articles/permission-levels-for-an-organization/)
  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 [COMMUNITY-ROLES.md](COMMUNITY-ROLES.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 COMMUNITY-ROLES.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.