mirror of https://github.com/CrimsonTome/tldr.git
116 lines
5.2 KiB
Markdown
116 lines
5.2 KiB
Markdown
# 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 can voice their thoughts,
|
|
and different positions are ideally resolved via
|
|
[informed consent](https://en.wikipedia.org/wiki/Sociocracy#Consent_vs._consensus)
|
|
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](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.
|
|
|
|
- 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.
|