lilith/tldr
1
0
Fork 0
mirror of https://github.com/tldr-pages/tldr.git synced 2025-04-29 23:24:55 +02:00
Code Activity

move role change guidelines from GOVERNANCE.md to COMMUNITY-ROLES.md

Browse source
This commit is contained in:
Waldir Pimenta 2018-01-17 16:55:16 +00:00
parent 155a25a797
commit de56d0fbeb
2 changed files with 84 additions and 76 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

76
COMMUNITY-ROLES.md
View file

@ -1,3 +1,79 @@
# Community roles
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.)
## When to change roles
- **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.
- **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.
(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.
## Who can change roles
### Current owners
The following people are the current owners of the tldr-pages organization,

84
GOVERNANCE.md
View file

@ -10,8 +10,7 @@ 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
Community members are asked to abide by the following principles:
- **All contributions are welcome**,
[no matter how small](https://github.com/kentcdodds/all-contributors).
@ -50,77 +49,10 @@ with no central authority.
[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.
- **Community roles reflect actual activity**.
Community roles in the tldr-project are set up
to dynamically reflect organizational work performed by community members,
rather than assigned as authority positions by top-down decision-making.
The different roles that contributors can take in the community,
and the principles that guide the transitions among them,
are described in the [COMMUNITY-ROLES.md](COMMUNITY-ROLES.md) document.