MESA Collaboration
Groups and Responsibilities
As the MESA developer base grows, effective collaboration becomes increasingly important. This demands enough structure to ensure quality and maintainability, but not so much structure as to dissuade engagement of new developers or discourage existing ones.
The future directions that the MESA instrument takes will be primarily driven by the interest of individual developers. The continued quality of MESA requires that the developers feel collectively responsible for all parts of the code and pay attention to large-scale MESA architecture issues. Additionally, it requires that the function, quality, and coverage of the test suite continues to grow with MESA.
Key groups
MESA Users (MU): Anyone who uses MESA for their science, education, or software. This is the most important group.
MESA Contributors (MC): Any user who wishes to share improvements to MESA (e.g., contribute a hook/routine, make a pull request).
MESA Developers (MD): These are individuals committed to improving MESA and its infrastructure (e.g., the MESA Test Hub). Instructions on how to become a developer are found here.
Responsibilities of developers include:
Stewardship of test_suite cases
Each test suite case must have at least one designated person (i.e., the steward) who understands what capabilities it tests and is ultimately responsible for keeping it updated as MESA evolves. Stewardship includes answering questions regarding your test suite, ensuring (through documentation) that people know how to use it for both research and testing purposes, raising the alarm when your test case is struggling (including your best diagnosis of the issue), and being ready to declare that the test case needs modification (or deletion).
Maintenance of each module and/or MESA capability
Each module and/or MESA capability must have at least one developer who is familiar with the relevant code and takes responsibility for ensuring its quality. These developers then commit to providing feedback on proposed changes from other developers. It is the responsibility of the MTC to ensure that the developers collectively possess sufficient knowledge of the MESA internals to maintain it effectively.
Engage with the MESA user community
Contribute to the process of documenting the instrument
Participate (when invited and possible) as a TA for MESA Summer School
Answer questions from MESA-Users
MESA Technical Council (MTC): This is a small group of developers who agree to commit a substantial amount of their time to provide oversight and guidance concerning MESA architectural and technical issues. The MTC holds the ultimate responsibility for the global health of the Instrument. This includes development, maintainability, testing, etc. They are responsible for ensuring regular communication between the developers. They must maintain an awareness of ongoing MESA development (e.g., surveying the intentions of the developers, monitoring the development of substantial branches to avoid a branch that can’t be brought back to the trunk).
MESA Administrative Council (MAC): The group that works together to ensure that all aspects of the MESA project are thriving. This includes activities such as identifying and achieving funding, ensuring successful MESA Summer Schools, making instrument paper decisions, creating attractive environments and opportunities for graduate students and postdocs to engage in MESA development, enhancing MESA’s use in education, ensuring that the usage of MESA by the astrophysics community is appropriate and documented, and communicating individual developer contributions to the astrophysics community so that the careers of developers are enhanced by their engagement.
Currently, the MAC is Lars, Rich, and Frank.
Onboarding and offboarding processes
These groups are not static and will change as individuals’ engagement with MESA evolves. If someone is permanently or temporarily unable to fulfill their responsibilities, they must inform the MD. Removal from MD, MTC, and MAC can be for inactivity, harm to the Project, or simply opting out.
Onboarding to the MD is described here.
Instrument Paper Principles
Note
These guidelines are principles, not laws. They are not intended to provide an exact or complete definition of the principles in all circumstances and should be understood in that context.