From ead41a7f1979dd9a7659955a803783e662b7ff24 Mon Sep 17 00:00:00 2001 From: Waldir Pimenta Date: Wed, 17 Jan 2018 00:15:17 +0000 Subject: [PATCH 1/9] maintainers-guide.md: reorder content and add section headings --- contributing-guides/maintainers-guide.md | 40 +++++++++++++----------- 1 file changed, 22 insertions(+), 18 deletions(-) diff --git a/contributing-guides/maintainers-guide.md b/contributing-guides/maintainers-guide.md index dd033ea724ecd..fdd0ec8bad725 100644 --- a/contributing-guides/maintainers-guide.md +++ b/contributing-guides/maintainers-guide.md @@ -3,33 +3,17 @@ The following guidelines are meant to provide a general basis for the behavior expected of tldr-pages maintainers: +## I. Responding to contributions + - When responding to issues or pull requests, remember that you're temporarily the face of the tldr-pages project. **Be welcoming and friendly**, and if you don't know how to answer, ping other maintainers who you think might have a say. -- Although push access allows committing directly to the repository, - plase **create pull requests for all of your changes**, - except the simplest ones (e.g. typo fixes). - This ensures that the entire process other contributors go through - is exposed to maintainers, - who can then identify and address bottlenecks or inconveniences. - Similarly, **avoid merging your own PRs**. - - **Every new discussion should receive a response within 3 days (ideally)**. You can respond yourself or ask other members to provide their thoughts/opinions. -- When merging PRs, use the strategy that produces a **clean git history**: - Use squash if there's a single commit in the PR, - or if the multiple commits are not independent changes. - If the PR author took the time to craft individual, - informative commit messages for each commit, - use rebase to honor that work and preserve the history of the changes. - - A simple heuristic to follow is that if there are more "dirty" commits - than "clean" commits, then prefer squash, else do a rebase. - - **Know when and how to say no**. Sometimes requests or contributions need to be declined, at least in their current form. @@ -46,3 +30,23 @@ for the behavior expected of tldr-pages maintainers: is a voluntary gift of time offered to the tldr project by someone who cares about it, so make sure not to take it for granted. + +## II. Handling PRs + +- When merging PRs, use the strategy that produces a **clean git history**: + Use squash if there's a single commit in the PR, + or if the multiple commits are not independent changes. + If the PR author took the time to craft individual, + informative commit messages for each commit, + use rebase to honor that work and preserve the history of the changes. + + A simple heuristic to follow is that if there are more "dirty" commits + than "clean" commits, then prefer squash, else do a rebase. + +- Although push access allows committing directly to the repository, + please **create pull requests for all of your changes**, + except the simplest ones (e.g. typo fixes). + This ensures that the entire process other contributors go through + is exposed to maintainers, + who can then identify and address bottlenecks or inconveniences. + Similarly, **avoid merging your own PRs**. From d62b941b4d5ebc1d1368e17f645e5fe4677f8561 Mon Sep 17 00:00:00 2001 From: Waldir Pimenta Date: Wed, 17 Jan 2018 00:19:01 +0000 Subject: [PATCH 2/9] maintainers-guide.md: reword some passages for improved clarity --- contributing-guides/maintainers-guide.md | 36 +++++++++++++----------- 1 file changed, 20 insertions(+), 16 deletions(-) diff --git a/contributing-guides/maintainers-guide.md b/contributing-guides/maintainers-guide.md index fdd0ec8bad725..0869a7eb21a5a 100644 --- a/contributing-guides/maintainers-guide.md +++ b/contributing-guides/maintainers-guide.md @@ -10,7 +10,9 @@ for the behavior expected of tldr-pages maintainers: **Be welcoming and friendly**, and if you don't know how to answer, ping other maintainers who you think might have a say. -- **Every new discussion should receive a response within 3 days (ideally)**. +- **Help keep the project responsive**. + New discussion threads (issues or pull requests) + should receive a response within 3 days, ideally. You can respond yourself or ask other members to provide their thoughts/opinions. @@ -29,24 +31,26 @@ for the behavior expected of tldr-pages maintainers: (pull request, feature request, bug report, etc.) is a voluntary gift of time offered to the tldr project by someone who cares about it, - so make sure not to take it for granted. + so make sure it's clear that that we don't take it for granted. ## II. Handling PRs -- When merging PRs, use the strategy that produces a **clean git history**: - Use squash if there's a single commit in the PR, - or if the multiple commits are not independent changes. - If the PR author took the time to craft individual, - informative commit messages for each commit, - use rebase to honor that work and preserve the history of the changes. - - A simple heuristic to follow is that if there are more "dirty" commits - than "clean" commits, then prefer squash, else do a rebase. - -- Although push access allows committing directly to the repository, +- When merging PRs, use the **merge strategy that produces a clean git history**: + If there's a single commit in the PR, + or if the multiple commits are not semantically independent changes, + use the `Squash and merge` method. + If the PR author took the time to craft + individual, informative messages for each commit, + use the `Rebase and merge` method, + to honor that work and preserve the history of the changes. + For less clear-cut cases, a simple heuristic you can follow + is that if there are more "dirty" commits than "clean" commits, + then prefer squash, else do a rebase. + +- Although having push access allows committing directly to the repository, please **create pull requests for all of your changes**, except the simplest ones (e.g. typo fixes). - This ensures that the entire process other contributors go through - is exposed to maintainers, + This ensures that the entire process that regular contributors go through + is also exposed to maintainers, who can then identify and address bottlenecks or inconveniences. - Similarly, **avoid merging your own PRs**. + Similarly, **avoid merging your own PRs** unless approved by other maintainers. From f4454587af57a5465430c8a2968174134fd4e34f Mon Sep 17 00:00:00 2001 From: Waldir Pimenta Date: Wed, 17 Jan 2018 00:19:55 +0000 Subject: [PATCH 3/9] maintainers-guide.md: add more content to the first section --- contributing-guides/maintainers-guide.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/contributing-guides/maintainers-guide.md b/contributing-guides/maintainers-guide.md index 0869a7eb21a5a..602158940aae9 100644 --- a/contributing-guides/maintainers-guide.md +++ b/contributing-guides/maintainers-guide.md @@ -15,6 +15,9 @@ for the behavior expected of tldr-pages maintainers: should receive a response within 3 days, ideally. You can respond yourself or ask other members to provide their thoughts/opinions. + In addition, if possible, try to hang around in the + [Gitter chat room](https://gitter.im/tldr-pages/tldr) + on a regular basis as well, or at least show up every now and then. - **Know when and how to say no**. Sometimes requests or contributions need to be declined, @@ -33,6 +36,13 @@ for the behavior expected of tldr-pages maintainers: by someone who cares about it, so make sure it's clear that that we don't take it for granted. +- Try to **keep the entire contribution process web-based**, if possible, + to ensure it is accessible and straightforward. + If you're comfortable with git, consider offering to perform + interactive rebases or other command-line operations + on behalf of contributors, + or assisting them if they want to do it themselves. + ## II. Handling PRs - When merging PRs, use the **merge strategy that produces a clean git history**: From 81bd5e3d81ec6a3e5d80edace8f4c8ef82269a5c Mon Sep 17 00:00:00 2001 From: Waldir Pimenta Date: Wed, 17 Jan 2018 00:21:38 +0000 Subject: [PATCH 4/9] maintainers-guide.md: add more content to the second section --- contributing-guides/maintainers-guide.md | 26 ++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/contributing-guides/maintainers-guide.md b/contributing-guides/maintainers-guide.md index 602158940aae9..8b2d073307d03 100644 --- a/contributing-guides/maintainers-guide.md +++ b/contributing-guides/maintainers-guide.md @@ -45,6 +45,32 @@ for the behavior expected of tldr-pages maintainers: ## II. Handling PRs +- PRs will be merged once they + (1) **pass the automated tests** (Travis CI, CLA signing, etc.), + (2) have the **review comments addressed**, and + (3) get **approved reviews by two maintainers** + (the second maintainer can perform the merge immediately after accepting.) + +- If a PR fails to get a review from a second maintainer after a few days, + the first maintainer should ping others for review. If it still lingers around + for **over a week without a second maintainer’s approval**, + the first maintainer can go ahead and merge it. + +- If the only issues holding up a merge are **trivial fixes** + (typos, syntax errors, etc.), and the author doesn't respond in a day or two, + **maintainers can make the necessary changes themselves**, + and proceed with the merge process. + +- If a PR **stops getting feedback from the submitter** and is marked as stale + by [probot-stale](../.github/stale.yml), + any maintainer can choose to take over the PR + and make the necessary changes to get the content ready for merging. + +- During the review process, make sure that contributors, especially new ones, + are not **overwhelmed with too many change requests**. + Be mindful of signs of fatigue (less enthusiastic responses, slower reactions), + and relax review standards if necessary — minor issues can always be fixed later. + - When merging PRs, use the **merge strategy that produces a clean git history**: If there's a single commit in the PR, or if the multiple commits are not semantically independent changes, From 0a47fb13973eb62c4a8b7ae3c4613984d7e9b09a Mon Sep 17 00:00:00 2001 From: Waldir Pimenta Date: Wed, 17 Jan 2018 00:22:45 +0000 Subject: [PATCH 5/9] maintainers-guide.md: add introductory note --- contributing-guides/maintainers-guide.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/contributing-guides/maintainers-guide.md b/contributing-guides/maintainers-guide.md index 8b2d073307d03..82ca31b6108b6 100644 --- a/contributing-guides/maintainers-guide.md +++ b/contributing-guides/maintainers-guide.md @@ -1,7 +1,16 @@ # Maintainer's guide The following guidelines are meant to provide a general basis -for the behavior expected of tldr-pages maintainers: +for the behavior expected of tldr-pages maintainers. + +*Note:* This text is a living standard; +that is, it is meant to *describe* the project's maintenance practices, +rather than *prescribe* them. +As a maintainer, you're expected to refer to it for clarifications +about the collaborative workflows of the project, +but also to propose changes to it +that you feel would make it more useful +as a guideline for current and future maintainers. ## I. Responding to contributions From 20effca6f75fa6fdbc6a05b6d9c07148c7e50258 Mon Sep 17 00:00:00 2001 From: Waldir Pimenta Date: Wed, 17 Jan 2018 16:50:39 +0000 Subject: [PATCH 6/9] rename MAINTAINERS.md --> COMMUNITY-ROLES.md --- MAINTAINERS.md => COMMUNITY-ROLES.md | 0 GOVERNANCE.md | 4 ++-- 2 files changed, 2 insertions(+), 2 deletions(-) rename MAINTAINERS.md => COMMUNITY-ROLES.md (100%) diff --git a/MAINTAINERS.md b/COMMUNITY-ROLES.md similarity index 100% rename from MAINTAINERS.md rename to COMMUNITY-ROLES.md diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 9891750dc3bda..90915fe845e5a 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -105,7 +105,7 @@ exceptions can always be considered, via open community discussion.) 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 [MAINTAINERS.md](MAINTAINERS.md) file. + 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, @@ -116,7 +116,7 @@ exceptions can always be considered, via open community discussion.) 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 MAINTAINERS.md file. + 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 From 11ad4983c13a4e4c5bcef7252d685652c05dc149 Mon Sep 17 00:00:00 2001 From: Waldir Pimenta Date: Wed, 17 Jan 2018 16:52:24 +0000 Subject: [PATCH 7/9] COMMUNITY-ROLES.md: minor tweaks in preparation for expansion --- COMMUNITY-ROLES.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/COMMUNITY-ROLES.md b/COMMUNITY-ROLES.md index a6e10e08c0067..32d8e534bb99f 100644 --- a/COMMUNITY-ROLES.md +++ b/COMMUNITY-ROLES.md @@ -1,7 +1,8 @@ -## Current maintainers +### Current owners The following people are the current owners of the tldr-pages organization, -and have admin access to all of its repositories. +have admin access to all of its repositories, +and are responsible for performing role changes in the community. - Romain Prieto `` (@rprieto) - Igor Shubovych `` (@igorshubovych) @@ -12,9 +13,9 @@ and have admin access to all of its repositories. - Agniva De Sarker `` (@agnivade) - Starbeamrainbowlabs `` (@sbrl) -## Past maintainers +### Past owners -The following people are former maintainers of the tldr-pages project, -who have moved on to other projects. +The following people used to be owners in the tldr-pages organization, +and have since moved on to other projects. Their contributions and dedication have ensured the success of the tldr project, and for that they'll always be appreciated. From 1ddc6f5172cb6bdd42bfe048f0b9494963ddf8a1 Mon Sep 17 00:00:00 2001 From: Waldir Pimenta Date: Wed, 17 Jan 2018 16:55:16 +0000 Subject: [PATCH 8/9] 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 32d8e534bb99f..02cb58bb6655b 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 90915fe845e5a..783200957f8fd 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. From c453ad6aebeab51ed5ae3c83d5722cd12c1d66f2 Mon Sep 17 00:00:00 2001 From: Waldir Pimenta Date: Wed, 17 Jan 2018 16:55:57 +0000 Subject: [PATCH 9/9] COMMUNITY-ROLES.md: add role transition procedures --- COMMUNITY-ROLES.md | 119 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 119 insertions(+) diff --git a/COMMUNITY-ROLES.md b/COMMUNITY-ROLES.md index 02cb58bb6655b..b2ab6f2cc614e 100644 --- a/COMMUNITY-ROLES.md +++ b/COMMUNITY-ROLES.md @@ -72,6 +72,125 @@ exceptions can always be considered, via open community discussion.) they should be added back to the organization, to reflect that fact. +## How to change roles + +*Note: this section is aimed at owners in the tldr-pages organization +(i.e. the group of people who are able to perform these changes).* + +If you notice a contributor being particularly active, +review their recent contributions to check whether a role transition is due, +according to the criteria defined in the previous section. +If a role change is warranted, **open a new issue proposing that role change**, +using one of the template messages below as a base. + +### For adding new collaborators + +Open an issue with the following message: + +``` +Hi, @username(s)! You seem to be enjoying contributing to the tldr-pages project. +You now have had five distinct pull requests merged ([LINKS TO THE RELEVANT PRs]), +which qualifies you to become a collaborator in this repository, +as explained in our +[governance guidelines](https://github.com/tldr-pages/tldr/blob/master/GOVERNANCE.md). + +As a collaborator, you will have commit access +and can therefore merge pull requests from others, label and close issues, +and perform various other maintenance tasks that are needed here and there. +Of course, all of this is voluntary +— you're welcome to contribute to the project in whatever ways suit your liking. + +If you do decide to start performing maintenance tasks, though, +we only ask you to get familiar with the +[maintainer's guide](https://github.com/tldr-pages/tldr/blob/master/contributing-guides/maintainers-guide.md). + +Thanks for all your work so far! +``` + +Once they acknowledge the message, +go to https://github.com/tldr-pages/tldr/settings/collaboration +and add them to the repository as collaborator with write permissions. + +### For adding new organization members + +Open an issue with the following message: + +``` +Hi, @username(s)! After joining as a collaborator in the repository, +you have been regularly performing maintenance tasks. Thank you for that! +According to +[GOVERNANCE.md](https://github.com/tldr-pages/tldr/blob/master/GOVERNANCE.md), +you've now met the thresholds to be effectively considered +an active maintainer of the project ([LINKS TO THE RELEVANT PRs]). +To publicly acknowledge that fact, we'll add you to the tldr-pages organization. + +If you accept the invitation, we ask you to make your membership public, +and (in case you don't already) start hanging out in our Gitter chat room. +You'll now be one of the public faces of the tldr-pages project. +Welcome aboard! +``` + +Once they acknowledge the message, +go to https://github.com/orgs/tldr-pages/people +and add them to the organization as a member. + +### For adding new organization owners: + +Open an issue with the following message: + +``` +Hi, @username(s)! You've been an active tldr-pages org member for over 6 months. +Thanks for sticking around this far and helping out! +According to +[GOVERNANCE.md](https://github.com/tldr-pages/tldr/blob/master/GOVERNANCE.md), +you're now eligible for becoming an owner of the organization. + +That means you will, from now on, be part of the team +responsible for performing role changes (like this one!) in the community. +Before performing such role transitions, make sure to review the +[COMMUNITY-ROLES.md](https://github.com/tldr-pages/tldr/blob/master/COMMUNITY-ROLES.md) +document. + +Thanks for all the work you've done so far. You rock! +``` + +Once they acknowledge the message, +go to https://github.com/orgs/tldr-pages/people +and change their role from "member" to "owner". + +Afterwards, add their name to the list of current organization owners below. + +### For removing inactive organization members: + +Open an issue with the following message: + +``` +Hi, @username(s)! As you know, our +[governance guidelines](https://github.com/tldr-pages/tldr/blob/master/GOVERNANCE.md) +define processes for keeping the list of organization members +in sync with the actual maintenance team. +Since you haven't been active in the project for a while now, +we'll be moving you to the status of former maintainer. + +In practice, not much will change on your side, +since you'll remain a collaborator in the repos you have been active in, +so **you will keep the ability to commit, merge PRs, label and close issues, etc.**, +if you feel so inclined. But even if you don't, +keep in mind that every bit of work you already did for the tldr-pages project +was a voluntary gift of your time to this community. +Your efforts have contributed to a project +which helps hundreds of people every day — be proud of it! + +And of course, you're welcome back anytime as a maintainer, if you so choose +— in which case we'll re-add you to the organization, +as is also described in the guidelines. +In any case, we wish you the best of luck in your new endeavors! +``` + +Once the role change is completed, +make sure to update the lists below accordingly. + + ## Who can change roles ### Current owners