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