Update onboarding documents, pending feedback#953
Conversation
Debraheem
requested review from
JMombarg,
VincentVanlaer,
aurimontem,
earlbellinger,
evbauer,
mathren,
matteocantiello,
matthiasfabry,
mjoyceGR,
rhdtownsend,
rsmolec,
warrickball and
wmwolf
Corrected the name of the testhub maintainer from Bill Wold to Bill Wolf and removed periods from the onboarding contact list.
| * Helps the new developer learn the expected GitHub workflow, including when and how to create branches, make commits, open pull requests, respond to review, and, where appropriate, merge pull requests. | ||
| * Remains involved in reviewing and guiding the new developer's contributions for an initial onboarding period of at least six months, so that the new developer receives the attention and mentorship needed to become a routine contributor to MESA. | ||
| * Helps connect the new developer with other existing developers whose expertise or responsibilities are particularly relevant to the new developer's interests and planned areas of contribution. | ||
| * If the new developer expects to work on backward incompatible changes, encourages them to raise those plans with the broader developer team before substantial development begins. |
There was a problem hiding this comment.
I would consider this more appropriate for the contribution guidelines, which would be already referenced in point 3.
| * Makes sure the new developer gets access to the infrastructure (github, slack, mesa-dev, testhub). | ||
| * Acts as a mentor to the new developer, helping them to get used to the system and the way things are done. This includes making commits, merging PR's, and general development tasks. | ||
| * Makes sure the new developer agrees to the code of conduct and knows that discussions on developer channels should be considered private and may include work in progress that should not be shared. | ||
| * Makes sure the new developer gets access to the relevant infrastructure. This includes adding them to the MESAHub GitHub organization with appropriate permissions, adding them to Slack and any relevant private channels, and arranging access to mesa-dev and testhub. |
There was a problem hiding this comment.
Something to ponder on: to what level are we given access to the various aspects of the infrastructure. E.g. GitHub has different levels of access to a repository and organisation.
| * Makes sure the new developer gets access to the relevant infrastructure. This includes adding them to the MESAHub GitHub organization with appropriate permissions, adding them to Slack and any relevant private channels, and arranging access to mesa-dev and testhub. | ||
| * Points the new developer to the existing documentation for development workflows. This includes contributing code through branches, making commits, opening pull requests, using the testing infrastructure, and identifying the points of contact for different parts of the infrastructure. | ||
| * Acts as the primary mentor for the new developer during onboarding, helping them to get used to the system and the way things are done. The nominator should make time to answer questions and help the new developer become comfortable with day to day development tasks. | ||
| * Helps the new developer learn the expected GitHub workflow, including when and how to create branches, make commits, open pull requests, respond to review, and, where appropriate, merge pull requests. |
There was a problem hiding this comment.
This is the same as the third point
| @@ -45,9 +45,22 @@ | |||
|
|
|||
| Assuming the new developer has been accepted, the nominator: | |||
There was a problem hiding this comment.
As discussed during the meeting, have a back-up mentor committed to assist if the nominator leaves the dev team during the on-boarding period.
| If after the minimum time has elapsed there are insufficient objections, then the new developer is approved. | ||
|
|
||
| .. note:: | ||
| With this process we are attempting to balance having a flexible procedure for bringing in new developers while providing an environment that all developers can work safely in. There may be reasons why someone does not want to share the reasons for vetoing someone. However we also want to balance the possibility for abuse of the system by allowing arbitrary vetoes, which may preclude people from certain groups. We are adopting this process through the calendar year 2023, and plan to evaluate and vote on whether to make it permanent at the beginning of 2024. |
There was a problem hiding this comment.
We may also want to consider deleting this rather outdated note as part of adopting changes here, now that this process seems reasonably settled. At least to me it seems that the core of this policy seems to be working well enough, as far as it goes, and now the question is what areas need to be extended and clarified.
For a bit of historical perspective, I believe there was discomfort around implementing a veto-based system that has at least some potential for abuse. The compromise was that a veto needs to at least be seconded, and this note reflects that it was adopted as a preliminary policy for a trial period for the year of 2023, with the intent to revisit and possibly make it permanent in 2024. Since this never actually was revisited as far as I'm aware, it's probably a good idea to do so now.
My reading of this page has always been that if we formally adopt this policy on a permanent basis, then we're saying that all further changes are subject to veto by two people. The formalization itself precedes the policy, so it isn't necessarily subject to any specific vote/veto threshold. I'd suggest that this needs to be discussed thoroughly and a broad consensus reached about what ought to be adopted.
4 participants
I have committed some updates to the onboarding documentation for new MESA developers to make it more clear what is expected and who can be contacted when onboarding a new developer. Please feel free to provide feedback so we can come to terms with a set of processes that everyone agrees with.