From c53f2b3921b0f0e6a3fa88edc70edd313409c621 Mon Sep 17 00:00:00 2001 From: Ebraheem Farag <63124736+Debraheem@users.noreply.github.com> Date: Thu, 2 Apr 2026 08:39:59 -0400 Subject: [PATCH 1/3] [ci skip] update onboarding documents, pending feedback --- docs/source/developing/new_developers.rst | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/docs/source/developing/new_developers.rst b/docs/source/developing/new_developers.rst index e61e1035e..0154cc7bd 100644 --- a/docs/source/developing/new_developers.rst +++ b/docs/source/developing/new_developers.rst @@ -45,9 +45,22 @@ Post Acceptance Assuming the new developer has been accepted, the nominator: -* Makes sure the new developer agrees to the code of conduct and knows that discussions on dev channels should be considered private and may include work in progress and thus should not be shared. -* 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. +* 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. +* 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. +* As the new developer becomes established, discusses with them whether they would like to take on additional project maintenance responsibilities. Such responsibilities are optional and are not a required part of onboarding. + +The relevant onboarding contacts are: + +* Mentor and primary onboarding contact: the nominator. +* GitHub maintainer and contact for GitHub access: Matteo Cantiello. +* Slack maintainer and contact for Slack access: Rich Townsend. +* testhub maintainer and contact for testhub access: Bill Wold. Infrastructure Access for Collaborators --------------------------------------- From 04f8b3be25b453494b1364f467f3de7e8c444f02 Mon Sep 17 00:00:00 2001 From: Ebraheem Farag <63124736+Debraheem@users.noreply.github.com> Date: Thu, 2 Apr 2026 08:44:30 -0400 Subject: [PATCH 2/3] [ci skip] fix typos in Bill's name Corrected the name of the testhub maintainer from Bill Wold to Bill Wolf and removed periods from the onboarding contact list. --- docs/source/developing/new_developers.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/source/developing/new_developers.rst b/docs/source/developing/new_developers.rst index 0154cc7bd..0ef426a0b 100644 --- a/docs/source/developing/new_developers.rst +++ b/docs/source/developing/new_developers.rst @@ -57,10 +57,10 @@ Assuming the new developer has been accepted, the nominator: The relevant onboarding contacts are: -* Mentor and primary onboarding contact: the nominator. -* GitHub maintainer and contact for GitHub access: Matteo Cantiello. -* Slack maintainer and contact for Slack access: Rich Townsend. -* testhub maintainer and contact for testhub access: Bill Wold. +* Mentor and primary onboarding contact: the nominator +* GitHub maintainer and contact for GitHub access: Matteo Cantiello +* Slack maintainer and contact for Slack access: Rich Townsend +* testhub maintainer and contact for testhub access: Bill Wolf Infrastructure Access for Collaborators --------------------------------------- From 9d94f6d6f8d9a5ae7721153334fd8690068d07c3 Mon Sep 17 00:00:00 2001 From: Ebraheem Farag <63124736+Debraheem@users.noreply.github.com> Date: Thu, 16 Apr 2026 11:15:46 -0400 Subject: [PATCH 3/3] [ci skip] address round1 comments/feedback --- docs/source/developing/contributing.rst | 2 ++ docs/source/developing/new_developers.rst | 11 +++-------- 2 files changed, 5 insertions(+), 8 deletions(-) diff --git a/docs/source/developing/contributing.rst b/docs/source/developing/contributing.rst index 3e6e08704..022f639f9 100644 --- a/docs/source/developing/contributing.rst +++ b/docs/source/developing/contributing.rst @@ -103,6 +103,8 @@ MESA development uses the following branching model: The line between what should be a feature branch / pull request and what's committed straight onto the main branch can be drawn based on how disruptive a change is expected to be. If it has the potential to break test suite cases, don't commit it directly to main. Use a branch. +If you are planning a backward-incompatible change, discuss it with with the broader developer team before substantial development begins. + Making a commit --------------- diff --git a/docs/source/developing/new_developers.rst b/docs/source/developing/new_developers.rst index 0ef426a0b..21b8bfcd2 100644 --- a/docs/source/developing/new_developers.rst +++ b/docs/source/developing/new_developers.rst @@ -37,22 +37,17 @@ Process: 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. - Post Acceptance --------------- Assuming the new developer has been accepted, the nominator: * 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. -* 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. +* Makes sure the new developer gets access to the relevant infrastructure. This includes adding them to the MESAHub GitHub organization with permissions appropriate to their role, adding them to Slack and any relevant private channels, and arranging access to testhub. +* Points the new developer to the existing documentation for development workflows and helps them learn the expected GitHub workflow, including branches, commits, pull requests, responding to review, use of the testing infrastructure, and, where appropriate, merge procedures. +* Acts as the primary mentor for the new developer during onboarding and coordinates a backup mentor in case the nominator becomes unavailable during the onboarding period. The nominator should make time to answer questions and help the new developer become comfortable with day-to-day development tasks. * 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. * As the new developer becomes established, discusses with them whether they would like to take on additional project maintenance responsibilities. Such responsibilities are optional and are not a required part of onboarding. The relevant onboarding contacts are: