From 9eabcaef992b48d673ba7bde93e1a6d4425d805a Mon Sep 17 00:00:00 2001 From: Sebastiaan van Stijn Date: Tue, 15 Dec 2015 14:20:00 +0100 Subject: [PATCH] Update rules for adding/removing maintainers and holidays This adds new rules to the maintainers file to clarify the way maintainers are added and removed from the list. Also removed the "holidays" rule, which is not used in practice. Signed-off-by: Sebastiaan van Stijn --- MAINTAINERS | 84 ++++++++++++++++++++++++++++++---- maintainercollector/rules.toml | 84 ++++++++++++++++++++++++++++++---- 2 files changed, 148 insertions(+), 20 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 927c938dc7..f20bdeb773 100755 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -30,6 +30,79 @@ It's easy to appreciate a really cool and technically advanced feature. It's har to appreciate the absence of bugs, the slow but steady improvement in stability, or the reliability of a release process. But those things distinguish a good project from a great one. +""" + [Rules.adding-maintainers] + + title = "How are maintainers added?" + + text = """ +Maintainers are first and foremost contributors that have shown they are +committed to the long term success of a project. Contributors wanting to +become maintainers are expected to be deeply involved in contributing code, +pull request review, and triage of issues in the project for more than three +months. + +Just contributing does not make you a maintainer, it is about building trust +with the current maintainers of the project and being a person that they can +depend on and trust to make decisions in the best interest of the project. + +Maintainers are assigned per project (repository). Being a maintainer in +one project does not automatically make you a maintainer in other projects. + +Periodically, the existing maintainers curate a list of contributors that have +shown regular activity on the project over the prior months. From this +list, maintainer candidates are selected and proposed on the maintainers +mailing list. + +After a candidate has been announced on the maintainers mailing list, the +existing maintainers are given five business days to discuss the candidate, +raise objections and cast their vote. Candidates must be approved by the BDFL +and at least 66% of the current maintainers by adding their vote on the mailing +list. Only maintainers of the repository that the candidate is proposed for are +allowed to vote. The BDFL's vote is mandatory. + +If a candidate is approved, a maintainer will contact the candidate to +invite the candidate to open a pull request that adds the contributor to +the MAINTAINERS file. The candidate becomes a maintainer once the pull +request is merged. +""" + + [Rules.stepping-down-policy] + + title = "Stepping down policy" + + text = """ +Life priorities, interests, and passions can change. If you're a maintainer but +feel you must remove yourself from the list, inform other maintainers that you +intend to step down, and if possible, help find someone to pick up your work. +At the very least, ensure your work can be continued where you left off. + +After you've informed other maintainers, create a pull request to remove +yourself from the MAINTAINERS file. +""" + + [Rules.inactive-maintainers] + + title = "Removal of inactive maintainers" + + text = """ +Similar to the procedure for adding new maintainers, existing maintainers can +be removed from the list if they do not show significant activity on the +project. Periodically, the maintainers review the list of maintainers and their +activity over the last three months. + +If a maintainer has shown insufficient activity over this period, a neutral +person will contact the maintainer to ask if they want to continue being +a maintainer. If the maintainer decides to step down as a maintainer, they +open a pull request to be removed from the MAINTAINERS file. + +If the maintainer wants to remain a maintainer, but is unable to perform the +required duties they can be removed with a vote by the BDFL and at least 66% of +the current maintainers. The BDFL's vote is mandatory. An e-mail is sent to the +mailing list, inviting maintainers of the project to vote. The voting period is +five business days. Issues related to a maintainer's performance should be +discussed with them among the other maintainers so that they are not surprised +by a pull request removing them. """ [Rules.bdfl] @@ -142,20 +215,11 @@ editor, and thus asking them to `git commit --amend -s` is not the best way forw In this case, maintainers can update the commits based on clause (c) of the DCO. The most trivial way for a contributor to allow the maintainer to do this, is to add -a DCO signature in a Pull Requests's comment, or a maintainer can simply note that +a DCO signature in a pull requests's comment, or a maintainer can simply note that the change is sufficiently trivial that it does not substantially change the existing contribution - i.e., a spelling change. When you add someone's DCO, please also add your own to keep a log. -""" - - [Rules.holiday] - - title = "I'm a maintainer, and I'm going on holiday" - - text = """ -Please let your co-maintainers and other contributors know by raising a pull -request that comments out your `MAINTAINERS` file entry using a `#`. """ [Rules."no direct push"] diff --git a/maintainercollector/rules.toml b/maintainercollector/rules.toml index 61df17abe7..da45016906 100644 --- a/maintainercollector/rules.toml +++ b/maintainercollector/rules.toml @@ -18,6 +18,79 @@ It's easy to appreciate a really cool and technically advanced feature. It's har to appreciate the absence of bugs, the slow but steady improvement in stability, or the reliability of a release process. But those things distinguish a good project from a great one. +""" + [Rules.adding-maintainers] + + title = "How are maintainers added?" + + text = """ +Maintainers are first and foremost contributors that have shown they are +committed to the long term success of a project. Contributors wanting to +become maintainers are expected to be deeply involved in contributing code, +pull request review, and triage of issues in the project for more than three +months. + +Just contributing does not make you a maintainer, it is about building trust +with the current maintainers of the project and being a person that they can +depend on and trust to make decisions in the best interest of the project. + +Maintainers are assigned per project (repository). Being a maintainer in +one project does not automatically make you a maintainer in other projects. + +Periodically, the existing maintainers curate a list of contributors that have +shown regular activity on the project over the prior months. From this +list, maintainer candidates are selected and proposed on the maintainers +mailing list. + +After a candidate has been announced on the maintainers mailing list, the +existing maintainers are given five business days to discuss the candidate, +raise objections and cast their vote. Candidates must be approved by the BDFL +and at least 66% of the current maintainers by adding their vote on the mailing +list. Only maintainers of the repository that the candidate is proposed for are +allowed to vote. The BDFL's vote is mandatory. + +If a candidate is approved, a maintainer will contact the candidate to +invite the candidate to open a pull request that adds the contributor to +the MAINTAINERS file. The candidate becomes a maintainer once the pull +request is merged. +""" + + [Rules.stepping-down-policy] + + title = "Stepping down policy" + + text = """ +Life priorities, interests, and passions can change. If you're a maintainer but +feel you must remove yourself from the list, inform other maintainers that you +intend to step down, and if possible, help find someone to pick up your work. +At the very least, ensure your work can be continued where you left off. + +After you've informed other maintainers, create a pull request to remove +yourself from the MAINTAINERS file. +""" + + [Rules.inactive-maintainers] + + title = "Removal of inactive maintainers" + + text = """ +Similar to the procedure for adding new maintainers, existing maintainers can +be removed from the list if they do not show significant activity on the +project. Periodically, the maintainers review the list of maintainers and their +activity over the last three months. + +If a maintainer has shown insufficient activity over this period, a neutral +person will contact the maintainer to ask if they want to continue being +a maintainer. If the maintainer decides to step down as a maintainer, they +open a pull request to be removed from the MAINTAINERS file. + +If the maintainer wants to remain a maintainer, but is unable to perform the +required duties they can be removed with a vote by the BDFL and at least 66% of +the current maintainers. The BDFL's vote is mandatory. An e-mail is sent to the +mailing list, inviting maintainers of the project to vote. The voting period is +five business days. Issues related to a maintainer's performance should be +discussed with them among the other maintainers so that they are not surprised +by a pull request removing them. """ [Rules.bdfl] @@ -130,20 +203,11 @@ editor, and thus asking them to `git commit --amend -s` is not the best way forw In this case, maintainers can update the commits based on clause (c) of the DCO. The most trivial way for a contributor to allow the maintainer to do this, is to add -a DCO signature in a Pull Requests's comment, or a maintainer can simply note that +a DCO signature in a pull requests's comment, or a maintainer can simply note that the change is sufficiently trivial that it does not substantially change the existing contribution - i.e., a spelling change. When you add someone's DCO, please also add your own to keep a log. -""" - - [Rules.holiday] - - title = "I'm a maintainer, and I'm going on holiday" - - text = """ -Please let your co-maintainers and other contributors know by raising a pull -request that comments out your `MAINTAINERS` file entry using a `#`. """ [Rules."no direct push"]