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 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](https://en.wikipedia.org/wiki/Bus_factor).

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.
(That's not to say they're hard-set rules:
exceptions can always be considered, via open community discussion.)

- 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**](https://github.com/orgs/tldr-pages/people).
      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](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.