From de56d0fbeb5cbc16d054c8a6d13002481cef29b9 Mon Sep 17 00:00:00 2001 From: Waldir Pimenta Date: Wed, 17 Jan 2018 16:55:16 +0000 Subject: [PATCH] move role change guidelines from GOVERNANCE.md to COMMUNITY-ROLES.md --- COMMUNITY-ROLES.md | 76 +++++++++++++++++++++++++++++++++++++++++ GOVERNANCE.md | 84 +++++----------------------------------------- 2 files changed, 84 insertions(+), 76 deletions(-) diff --git a/COMMUNITY-ROLES.md b/COMMUNITY-ROLES.md index 32d8e534b..02cb58bb6 100644 --- a/COMMUNITY-ROLES.md +++ b/COMMUNITY-ROLES.md @@ -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, diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 90915fe84..783200957 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -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.