29Jan2021_discussion

[nicgaspar]

Attendees : @gregtucker @kbarnhart @mcflugen @nicgaspar

Values:

• Respect the value of people's time
• Responsive to people's requests (code contributors should be responsive)
• Code meets contribution standards (along the lines of doc strings & testing)
• We don't exclude contributions based on who is submitting (e.g. age, location, funding, do not impact whether you can contribute)
• Open decision making on whether to accept a pull request
• Open decision making on a change breaking version increase
• Open decision making on whether proposed changes are acceptable

Open vs. Closed spectrum

• Caretakers/deciders are the main development team (team from the start)
• CSDMS integration facility controls Landlab decisions
• Independent body that controls Landlab decisions - community owns Landlab, as represented by council members (that are elected? by whom? what is process to become a councilor?)

Role of a council of Landlab:

• Just an advisory group. Council meets once a quarter to get updates but most work done by Eric.
• More active council. Individual roles, e.g., communications councilor, chair, user liaison, code standards person. [Questions : Who would be part of this council without any incentives? Incentives are usually money. Or writing proposals. Can you gain something from being on the council?]

How do we move forward with answering issues?

• Do we answer questions that are more about modeling, and not about our code?
• Some OS software has a two tier system in whom they respond to. Collaborators will always get responses. Unpaid users will not always get responses. [e.g. see Dakota help https://dakota.sandia.gov/resources.html]
• Can we require some minimum expectations before we answer issues?
• How do we make sure that people are actually committed and serious? It's easy to ask for something, and people may not realize how much time we take to give helpful and thoughtful responses.

[gregtucker]

Here's an attempt to distill a few points from the above discussion:

• Role: an advisory role is more realistic (but includes high-level decision making such as whether/how/when to issue a major backward-compatibility-breaking release), with (for now) the CSDMS Integration Facility responsible for handling CI, maintenance, communications, etc.
• The value of "responsive" above is tempered by the expectation that users do their homework first, and that primary responsibility lies with the developer of the relevant component/element (especially when they are funded, e.g. via broader impacts or cyberinfrastructure support, to share and support the relevant element(s)).
• It is reasonable for those who do work in developing, maintaining, and/or supporting Landlab be compensated in a meaningful way, whether in the form of grant funding, co-authorship/collaboration, or other.
• The question of the future composition of a Council of Landlab (e.g., core development team vs. anyone in the community who is interested) remains open.

[gregtucker]

There's a relevant blog post here that discusses governance approaches for open-source research software projects. It points to three examples: the Carpentries, NumPy, and node.js. Given the considerations noted above, the scale and evolution of Landlab, my sense is that something like the NumPy governance model could be a good fit. Some elements:

• They operate by consensus, which is thoughtfully defined and described.
• They recognize Contributors.
• They have a Steering Council populated by Contributors. The Council is empowered to make certain kinds of decisions when needed (though I get the sense that it's not often needed). Existing Council members nominate new ones.

One difference between Landlab and NumPy (in addition to the scale and scope obviously) is that Landlab exists as a package within CSDMS, and so I think it would make sense to formally acknowledge the link with CSDMS.

[gregtucker]

Further discussions 4/9/21 with GT, KRB, NMG, and EI (GT taking notes):

• Looked at NumPy's governance model
• Landlab has a lot fewer contributors than NumPy
• Useful definition of consensus, but LL has lots of users who aren't active in contributing code, and might be less likely to notice problematic changes
• Who are the people who say "yes" as opposed to "no"? In practice, it has tended to be people who pay attention to GitHub Issues
• Who has the authority, for example, to change a component made by someone who is no longer an active contributor? Document could usefully discuss this kind of thing.