Repository navigation
[Proposal for Discussion] New Roles for General Project Maintainers and DevOps #136
Description
Following on discussions had in person and most recently, in #118 , I would like to use this issue to discuss @bsipocz 's proposal of adding a role for Project Maintainers. These are folks who have their hands in many parts of the project and understand how lots of things work. Several pros and cons to this idea have been mentioned and I'd like to encourage folks to summarize their thoughts here again even if they were recently expressed elsewhere (@bsipocz, @eteq). I also think it's ok to go ahead and name the folks who you think fit the bill of this potential newly named role. (I can think of @pllim and @bsipocz, for example.) To try and foster the most discussion possible, I'll also post a link to this issue in the other relevant forums including the slack #project channel and the astropy-maintainers email list.
Activity
pllim commentedon Sep 16, 2020
I like to think of my work to be something along the lines of operations, quality assurance, reliability, and some customer support. Perhaps a subset of devops though I have to admit I never grokked what "devops" really means. 😅
bsipocz commentedon Sep 16, 2020
Yes, what the two of us do is more along the lines of operations and devops, a role that requires a good enough global oversight for the project and the wider ecosystem, the roadmap and downstream usage. A welcome change would be that it's an acknowledged role so the subpackage maintainers don't take it as a stepping on their toes into their territories when a PR is being overtaken, wrapped up or reviewed. Most of the time the intention is the speedy turnaround on PRs that don't require the deep dive of the subpackage maintainers to they can focus on the larger ones.
While the general maintainer category in my head has names of e.g. Stuart M, Derek, Anne. Who are willing to go into a problem in several submodules but generalist for to overtake the maintenance of submodules. This role can also be a stepping stone while a new maintainer gathers more confidence in the workflow and review process. A natural benefit would be that submodules can be thus tagged under this general, e.g. samp, wcs, etc, which actually better describe their status, or desired status (for the case of wcs).
On the other hand I don't propose to overpopulate these roles. I firmly believe that people should be removed from roles when they don't perform said roles for years rather than kept being listed (if consistently there is no effect in pinging them to do a review or release or provide input, then what's the point of the list?). The current page certainly has that problem. Other projects use the "emeritus core developer/emeritus maintainer" category (https://scikit-learn.org/stable/about.html, https://numpy.org/gallery/team.html) which better describes the situation.
kelle commentedon Sep 16, 2020
Excellent! I hear a 2nd concrete proposal: a new "devops" role. I will update the issue accordingly.
(I hear you about taking people out of named roles but I'd prefer we keep this issue limited to discussions about the new roles. You are welcome to start a new issue to discuss the retirement plan.)
[-][Proposal for Discussion] New Role for General Project Maintainers[/-][+][Proposal for Discussion] New Roles for General Project Maintainers and DevOps[/+][-][Proposal for Discussion] New Roles for General Project Maintainers and DevOps[/-][+][Proposal for Discussion] New Roles for General Project Maintainers[/+][-][Proposal for Discussion] New Roles for General Project Maintainers[/-][+][Proposal for Discussion] New Roles for General Project Maintainers and DevOps[/+]hamogu commentedon Sep 16, 2020
Sorry, I accidentally edited the title here to remove the "Devops" that @kelle just added (and replaced it again 2 min later). I realized that me editing the title is inappropriate for this issue (neither did I open it, nor am I an a position to decide this).
That said, I think these are two different things and should be different issues. I suggest to revert this issue to "general maintainers" and open a new issue for DevOps, if we don't have one. Those are two totally different things and should not be lumped together.
As for @bsipocz original proposal: I think that's great idea. I suggest that those general maintainers have the same access and commit rights as sub-package maintainers, i.e. they can add/remove labels, approve PRs and merge PRs following this line in our (draft) policies: https://github.com/astropy/astropy-project/pull/100/files#diff-5d169bd40a8f4276b638234544a4521fR21
Essentially, "general" maintainers" can do everything that subpackage maintainers can do outside of their own sub-package. That automatically means that every sub-package maintainer is also a general maintainer, so in my interpretation of what @bsipocz suggests, @dhomeier would not be a "general maintainer" because he already maintains a sub-package.
Now, this is where the DevOps mixes in - I suggest that as a policy, all "DevOps" also have (at least) "general maintainer" rights (I think right now, all DevOps have the required commit rights anyway?).
hamogu commentedon Sep 16, 2020
Found the issue: Role for DevOps belongs more into #118 than here. Or could be it's own issue, since #118 is more general than just "create a formal role for".
bsipocz commentedon Sep 16, 2020
or even better Derek and Stuart could choose whether they are happy with the subpackages they are currently listed, somehow shoehorned into, or rather be listed as general ones. I feel they both do more than their modules, but it should be up to them.
devops certainly need commit rights, but I would argue admin (maybe "maintainer") rights. There have been plenty of cases when access to tokens, webhook, etc were required.
adrn commentedon Sep 16, 2020
👍 to the idea of adding a "General maintainer" role, but maybe with a name to emphasize that it pertains to the core package, like "core package maintainer"?
bsipocz commentedon Sep 16, 2020
I'm not picky on the name, and even the "core package maintainer" better describes it. "general project maintainer" might be a more holistic role that we don't have and should not have before figuring out the coordination of integrations for coordinated packages.
hamogu commentedon Sep 16, 2020
It could be defined in terms of what it's not. On the website, change "subpackage maintainer" to "core package maintainer". Above or below the individual subpackages add "no specific sub-package" and list the names behind that.
mhvk commentedon Sep 17, 2020
Very much in favour. If asked without seeing the discussion, I'd actually have thought "general maintainer" would fit @pllim very well - general sense of most modules, how everything works, etc. Though the "keeps everything rolling" aspect maybe falls more under 'devops'. Hmm, I also don't really know what it is ... looking at wikipedia ... not really any the wiser ... Anyway, happy to go with it if @pllim thinks that is most appropriate!
Indeed, relatedly, one possibility to get ahead of this in future would be if the e-mail survey we do of people to see whether they themselves feel they are still involved had an option "other" under the question that (I think we have) about which role they fulfill, so they could self-define. (So, immediate consequence: since @pllim considers herself "devops", let it be so!)
Cadair commentedon Sep 17, 2020
On this vs "devops":
I think that there should be a group of people entrusted with the infrastructure maintenance, or at least a well defined subset of it, and that should be separate from a "core package maintainer".
On generalist vs specialist:
I see no reason why one can't be both. You can be happy to dive into generic tasks over the whole code base for maintenance etc and also take on a specific responsibility for the nitty gritty and features of a subpackage. For instance, I now (somehow) understand WCSAxes quite well so am happy to be a visualisation maintainer, but I wouldn't know where to start adding a feature to samp or something. However, I would happily dive into samp and update a dependency or something if it were causing trouble. That to me is the difference between the general and the specific here, it's the in-depth expertise in that subpackage.
On reviews and merging:
One thing that I am not clear on personally, and I don't understand how this proposal would interact with, is what the expectation is for people to use the merge button on subpackages they aren't maintainers on. As I am listed as a visualization maintainer should I approve / merge a simple PR to the io subpackage? Should merge an approved PR to coordinates?
If I were also a "core package maintainer" would the answer to those questions change?
kelle commentedon Sep 17, 2020
Great convo!
@Cadair , Do I understand you correctly that you are proposing a third new role dedicated to "infrastructure"?
I actually thought we had this role, but looking at the team page, I don't see it! It looks like we tried to break out the various infrastructure pieces into their own roles.
If I do understand you correctly, could you expand on what that role entails and the folks who think are currently filling that role? (I'm fine with using this thread since all of these roles are so related, but you can also start a new issue if you prefer.)
16 remaining items
eteq commentedon Oct 12, 2020
re: @astrofrog
I like this idea phrased this way! You're right it's more reflective of reality. I think it wouldn't require a ton of change anyway since all the sub-package roles still have to be maintained as "specialist", but it allows space for "generalists".
One clarification, though: would all "specialists" also be "generalists"? I know some people have expressed hesitation to be a "generalist" but are more willing to enter via the "specialist" route. So that spoils the simplicty of the above a bit (even if we can't have it really reflect reality given the github limitations).
astrofrog commentedon Oct 12, 2020
I think all specialists would also be generalists, although whether and when they choose to exercise that right is a different matter. It's going to be hard to define generalist anyway in a way that means X is a generalist and Y is not. I'll happily try and track down a bug in coordinates or WCS but I might very well fail and I don't think I could delve into votable in the first place - does this mean I'm not a generalist?
At the end of the day all specialists actually have generalist permissions in the core repo anyway?
bsipocz commentedon Oct 12, 2020
I would push back on listing everyone as a "generalist". The whole point in this (and in my view of the roles page) is to know who are in charge, who are responsible for certain parts. If there is no use of pinging those people then no point in listing them. E.g. if one is only comfortable with doing maintenance of a limited scope in core then they should not be listed as a generalist.
eteq commentedon Oct 12, 2020
More broadly, though, on
I think the current table has been important for at least some of the recruits we have brought in over the years (although certainly not a silver bullet, but every little bit helps...), particularly when behind-the-scenes politicking is required.
But given the overlap of roles and people, it does indeed make a lot of sense to have this mapping go both ways, and it's probably easier to maintain the way @embray said! Should we make an issue over at astropy.github.io for this?
bsipocz commentedon Oct 12, 2020
e.g. in my view the generalists has an overarching view of things. E.g can be pinged with any C code related issues, can be pinged with install issues, can be pinged with not so clear downstream issues. And most importantly they are comfortable with the idea of triaging issues for multiple modules not just a niche one that's their speciality.
It comes back to my usual mantra, that there is little point in diluting roles with people who are not doing said role, never respond to pings related that role, as it only creates overhead when trying to find solutions, etc.
bsipocz commentedon Oct 12, 2020
the current table is also responsible of filling roles that didn't work out, a role got filled with politicking, but not so much action followed.
mhvk commentedon Oct 12, 2020
👍 on "generalists" as a true separate category - it doesn't mean the "specialists" cannot jump in sometimes, but I think it helps give appropriate credit.
astrofrog commentedon Oct 12, 2020
Ok I'm convinced and I drop my suggestion to consider all core devs to be generalists 😀
bsipocz commentedon Oct 12, 2020
oh, certainly. And this is basically the main reason I don't really like the idea of assigning issues to people as it lowers the likelihood of someone taking up that issue randomly (while also puts pressure on the assignee, and that's not OK if they are in the project on a voluntary base).
But something has to be done though as there isn't any momentum by the maintainers to do regular triage. Maybe it's regular work together times, maybe it's regular mentions by the bot, maybe something else? What currently is visible that there isn't a visible drop in the number of bug fixes or closed issues even though there are 8+ contracts to maintainers for which the mantra is that the contracts are to do "tasks that volunteer effort has been unable to address, due to a lack of time or interest". It's not something that a single, magical person will ever be able to resolve when most issues need something to be said by the subpackage maintainer.
mhvk commentedon Oct 13, 2020
I loved the idea of the regular work-together that you started, but reality clearly intruded as I think I took part only once. One focused on triage of specific modules sounds good, though...
kelle commentedon Oct 13, 2020
Just a quick clarification, and apologies for the off topic post, but most of the current contracts are for work which volunteers were already regularly doing and not for
We're definitely moving in the direction in having more contracts address the neglected tasks, but those are not the majority of the contracts at the moment.
If anyone wants to discuss this further, I suggest we use #113.
bsipocz commentedon Oct 13, 2020
I've copy pasted that from the Moore report. If the maintainer contacts are not for doing maintainers' tasks (triage was always part of it), then at least it should not be reported back as a thing that's got done with the grant.
hamogu commentedon Feb 3, 2022
At the developer telecon, we discussed this and there is broad agreement (see dev telecon notes from today for detailed discussion) to move ahead.
Plan:
APE0 puts "creating roles" into the realm of the Coco, so I'll bring it there, but leave this PR open until it's done.
hamogu commentedon Feb 18, 2022
Closing this since PR to add general maintainer role to website is now open: astropy/astropy.github.com#475