Replies: 4 comments 2 replies
-
A test of the efficiency would be how fast it would take to release 2.2.1, which needs to contain #1960. |
Beta Was this translation helpful? Give feedback.
-
RE: #2009 & Bus factor... some history... I support adding an additional person across all items, but how do we determine who that person in? I can see different people for different reasons. This might be a simple exercise, but I want to make sure we have some rigor/thought behind it if multiple people are interested in this type of role. |
Beta Was this translation helpful? Give feedback.
-
Also I would like to win the lottery, not be hit by a bus. |
Beta Was this translation helpful? Give feedback.
-
One other piece of history -- once upon a time, we had three dedicated contributors all consistent and regular -- making contributions, attending meetings, being responsive. Then in one month -- two had a baby and the other bought a new house and moved and the project came to an absolute halt for maybe three months. So while we can reduce the lottery factor, it still doesn't mean that perfect storms can't happen. |
Beta Was this translation helpful? Give feedback.
-
We all know this famous excerpt:
I have currently noted that to some infrastructure components supporting Mesa only one or two maintainers of Mesa have access to it. That slows down development velocity, puts an unevenly large burden on some maintainers but most importantly poses a risk to Mesa continuity. Some infrastructure is more important that others, but PyPI is among one if not the most important.
The PyPI case shows this clearly: A failed 2.2.0 release (including announcement to 100+ users of a release that was not on PyPI yet), because a (for me) 5 minute job was left open for over a year (#1479, #1855). No hard feelings here but it's a weakness we should address.
Therefore I would propose that we make it a policy that to any Mesa component, at least 3 maintainers have full access. And if there isn't a clear reason why not, all maintainers should have access.
Further, we should increase the bus factor ReadtheDocs, Coveralls, GitHub Actions, Dependabot, Pre-commit.ci. And we should check if there isn't any (infrastructure) component we're missing.
We probably want to keep some internal (non-public facing) documentation on who has access to what.
Beta Was this translation helpful? Give feedback.
All reactions