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


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.

How do authorship invitations arise?

During the completion of the first six MESA Instrument Papers, there have been multiple channels for co-author invitations.

  • Running a non-MESA code in a controlled and engaged manner that enables verification of a NEW MESA capability (e.g., Dessart for shocks).

  • Developing a substantial new MESA capability by working with the MESA developers to incorporate existing techniques or codes into MESA (e.g., RSP with Smolec, STELLA with Blinnikov, Sorokina, RTI with Duffell).

  • Undertaking a substantial development effort that leads to a new MESA or MESA-related capability (e.g., Marchant on binary, Townsend on GYRE in MESA, Wolf on TestHub).

  • Working closely with the MESA developers over a prolonged period to assist in the science or code verification of a new capability (e.g., Brown on massive stars, Arras on planets).

  • Making significant and ongoing contributions to the vitality of the MESA project such as by time spent testing and documenting, time spent working on the software to make it more flexible, robust, and reliable, or time spent responding to MESA-Users.

The MAC monitors the evolution of MESA, decides when it is time for an instrument paper, and sets the schedule from initiation to submission. The MAC works to identify individuals it feels are positioned to be invited. It will also query MESA developers about imminent completion of items that might lead to co-author invitations.

What does it mean, once invited, to be a co-author?

Prospective co-authors should be prepared to participate by:

  1. Completing any sections for which they are a prime author in a timely manner.

  2. Reading and commenting on all sections of the paper.

  3. Assisting others where needed in items 1 and 2.

  4. Fully participating in the 3-4 day close-out session of the paper.

The MAC can relax any of these four items when there is value in doing so.