-
Notifications
You must be signed in to change notification settings - Fork 270
Add policy for adding new maintainers #434
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add policy for adding new maintainers #434
Conversation
FairlySadPanda
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I know this is a draft and largely none of my business
I've done some copy-editing to clean up grammar and use more declarative language. Feel free to ignore all of this, it's just tips on grammar and sentence structure. 🫡
EmoGarbage404
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
grammatical nitpicking.
| - If there are any concerns about the nomination, they should be discussed in the thread and addressed before the vote is closed. | ||
| 4. At the end of the week, the vote should be closed and the results should be announced. If the vote passes, the person being nominated should be contacted and asked if they would like to accept the position. If they agree, they can be added to the maintainers list. | ||
|
|
||
| ### Special Maintainer Roles |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this bullet points explaining the additional maintainer roles are unnecessary. You could remove all of this below and replace it with something like this:
For adding maintainers with special duties (engine maintainers, art leads, etc.), the process for voting is the same as above but with the following changes:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's good if it's well defined. Saying "etc." leaves it open to interpretation.
| - **Robust Toolbox Maintainer**: A Maintainer of Robust Toolbox, our underlying game engine. | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd probably remove this as I think RT maintainers would entirely be under PJB's purview unless that were no longer feasible, in which case we would add them under the policy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mirroring the response from Discourse:
I included RT maintainers here as there would otherwise be no policy for them. Unless I am mistaken, RT Maintainers are always normal Maintainers. In practice that means only existing RT Maintainers can nominate new RT Maintainers, which then the entire Maintainer Team votes on. With the changes @SlamBamActionman suggested, the RT Maintainer Team would still hold the final yes and no.
beck-thompson
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
double approve from me
See https://forum.spacestation14.com/t/policy-for-adding-new-maintainers/18790
Voting happens here: https://forum.spacestation14.com/t/maintainer-policy-change-policy-for-adding-new-maintainers/19077