New developers

Note

This document was voted upon by the existing developers. Before making any changes you must confer with the other developers.

What is a developer?

A developer is someone who commits to spend (some) time helping to run and maintain the MESA project. This can include adding new code and documentation but also includes many other tasks that are needed to keep the project running. These include (but are not limited to) managing and maintaining infrastructure, running meetings, triaging bug reports, merging Pull Requests, applying for funding for infrastructure, and providing technical and scientific knowledge to other developers. The amount of time someone commits is up to the individual to decide on, and it is expected to vary over time as various other tasks take priority.

If you simply want to fix a bug or get some new code added to MESA then you don’t need to be a developer. We welcome PR’s and bug reports from the community and you don’t need to be a developer to contribute that way. Only if you want to take a more active role in managing the MESA project do you need to be a developer.

Who can become a developer?

Anyone.

How to become a developer?

New developers need to be nominated by an existing developer. Either reach out to an existing developer or an existing developer may reach out to you. This is a good time to understand what is expected from being a developer, the level of time commitment you can provide, as well as what you can get out of being a developer.

If a potential developer reaches out to an existing developer, but that developer is unsure about nominating them, then the existing developer should reach out to the other developers to see if anyone else is interested in nominating and mentoring this person.

Process:

  • The nominator posts their nomination in mesa-dev and Slack.

  • There is a period that spans at least 2 dev meetings and 2 weeks minimum (that is one meeting to propose the person and then sufficient time for people to raise objections).

  • The nomination is accepted if there are 1 or fewer objections raised.

  • To veto someone then either:

    • Two separate people should raise objections on their own in either slack or mesa-dev.

    • Or, one person raises an objection and for privacy reasons they do not want to share this with the entire developer group. In this case, they should discuss with another developer, whom they trust, and that person can raise the second veto. In this case objections should be communicated to the nominator directly, but the objector does not have to share their reasons.

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 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.

Infrastructure Access for Collaborators

Membership in the MESA Developers entails (but is not necessarily limited to) access to several key pieces of infrastructure: the MESA Developers Slack, regular zoom meetings, and commit access to the GitHub repository. When members of the developer team are collaborating with researchers outside of the team on projects that involve significant MESA development, it may be useful to grant some degree of access to this infrastructure without necessarily going through the full process of nomination for membership in the MESA Developers. Examples include students, postdocs, or other researchers hired by or collaborating with members of the developer team. In such cases, we adopt the following policies for access to the infrastructure:

  • Developers may grant commit access to the GitHub repository by adding somebody to the MESAHub GitHub organization in the Outside Collaborator role. This access does not require a nomination and vote, but the developer granting access should notify the developer team by posting on Slack or on the mesa-developers mailing list.

  • Developers may also add collaborators to the MESA Developers Slack, without the need for a nomination or vote. We will reserve a few private channels for developer team members only, and the #meetings channel will only be accessible to those approved to join the zoom meetings.

  • Developers may nominate outside collaborators to participate in the regular developer zoom calls and have access to the #meetings channel on Slack, including recordings of previous meetings. The procedure for approving this nomination will be the same as described above for approving developer team member nominations, but in this case the scope is on the narrow question of zoom meeting participation. The timeline for this approval will therefore be at least 2 weeks and must span 2 meetings.

This delegated access may be followed by nomination for membership in due course, and these policies are intended to facilitate smooth communication and collaboration prior to that step. If necessary, the above categories of access can also be revoked following the process described in the Removing a Developer section of this documentation.

Removing a Developer

At any time an existing developer can retire for any reason if they need to step back from working on MESA.

At times it may be required to forcibly remove an individual from the developer community. This is a serious action and should not be taken lightly. Reasons for this may include (but are not limited to) violations of the code of conduct, abuse or harassment of others, or issues of scientific integrity.

In the event that a developer needs to be removed, then an existing developer should call a vote to remove the person. This vote should be seconded by another developer. Removal then requires a majority of existing developers to vote for removal. If the developer is removed then commit access to MESA will be removed, as well as the developer’s access to the MESA developers communication channels (slack, mesa-dev).

In exceptional time-sensitive circumstances the administrators of the MESA infrastructure (mailing lists, github, slack, testhub) may suspend a developer’s access if they feel that waiting for a vote would not be appropriate. Reasons can include (but are not limited to): posting abusive messages, denial or degradation of service, committing malicious code, or other actions that the admin feels is damaging the infrastructure. This is not a removal from being a developer, but should be considered a serious issue. The admin should discuss their reasons at the earliest opportunity with the other developers, and this must lead either to a vote to remove the developer or a clear path toward ending the suspension.

Approving This Document

This document was approved by unanimous consent of the current MESA Developers as of December 2022.

Changing This Document

Changes to this document will follow the same process as the initial approval process.

Changes will be put to a vote of all current developers. If someone has serious concerns then please raise them before the vote. Acceptance will require unanimous consent. Abstentions will count as implicit approval. Thus only a direct no vote will count against it. The vote will be held on slack (and emailed to mesa-dev) with an appropriate period of time for people to read and approve this document.

Changelog

  • Initial document approved December 5, 2022