mirror of https://github.com/CrimsonTome/tldr.git
move role change guidelines from GOVERNANCE.md to COMMUNITY-ROLES.md
parent
155a25a797
commit
de56d0fbeb
|
@ -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
|
### Current owners
|
||||||
|
|
||||||
The following people are the current owners of the tldr-pages organization,
|
The following people are the current owners of the tldr-pages organization,
|
||||||
|
|
|
@ -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,
|
the entire community can read, apply, improve and adapt them as needed,
|
||||||
with no central authority.
|
with no central authority.
|
||||||
|
|
||||||
|
Community members are asked to abide by the following principles:
|
||||||
## I. Participation and community interactions
|
|
||||||
|
|
||||||
- **All contributions are welcome**,
|
- **All contributions are welcome**,
|
||||||
[no matter how small](https://github.com/kentcdodds/all-contributors).
|
[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)
|
[consenting](https://en.wikipedia.org/wiki/Sociocracy#Consent_vs._consensus)
|
||||||
to it as "good enough for now, safe enough to try".
|
to it as "good enough for now, safe enough to try".
|
||||||
|
|
||||||
|
- **Community roles reflect actual activity**.
|
||||||
## II. Role transitions
|
Community roles in the tldr-project are set up
|
||||||
|
to dynamically reflect organizational work performed by community members,
|
||||||
The following guidelines aim to keep the project vibrant and responsive,
|
rather than assigned as authority positions by top-down decision-making.
|
||||||
by ensuring a **smooth transition flow between community roles** —
|
The different roles that contributors can take in the community,
|
||||||
from newcomer, to occasional contributor, to regular contributor, to maintainer.
|
and the principles that guide the transitions among them,
|
||||||
This way, the project should be able to adapt dynamically and flexibly
|
are described in the [COMMUNITY-ROLES.md](COMMUNITY-ROLES.md) document.
|
||||||
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.
|
|
||||||
|
|
Loading…
Reference in New Issue