Repository navigation
Roles: Audit all existing titles and membership #519
Description
Activity
For distributions, that is only useful it if includes which distributions the person(s) is/are responsible for.
Reacted by Derek HomeierFor
coordinates, I think @eteq has been rather inactive (likely despite himself), as has @adrn. @StuartLittlefair and @eerovaher are active.uncertaintiesis indeed a bit inactive, though I've had a few PRs recently. @eteq has not been involved in it recently (wish he were, as perhaps does he!). One of quite a few where a co-maintainer would help... (@byrdie and @nstarman are generally interested in it)For
utils, similarly more people would be useful. Forutils.masked, @nstarman has been contributing. Forutils.iers, @taldcroft has contributed quite a bit.More high-level, thanks for doing this! I hope the developer survey helps clarify some bits; agreed that we should remove people from the list if they are inactive -- without prejudice of course!
Reacted by P. L. LimI'd be certainly be interested in co-maintaining
uncertainties, but I can't say that I've contributed to that subpackage yet.Reacted by Marten van Kerkwijk and Derek HomeierThanks! I don't expect everything will be resolved in a blink. I will certainly consider all the comments here when I bring this to CoCo and wherever we have to discuss.
In my opinion, we needs to distinguish between credit for work and a "contract list" like a phone book. To me, the team page is meant to the latter and thus there are a number of roles on there that are pretty small in terms of hours/year. For example see #507, where we tweaked "Astropy.org web page maintainer", to make it clear whom to contact for DNS upkeep and configuration. That's way, way less work than e.g. maintaining infrastructure, but if I have a problem with the DNS configuration, I need to know whom to talk to.
Another example is having sub-roles for distributions. Originally, every distribution had a sub-role, like "Debian maintainer", "arch linux maintainer", "macports maintainer" etc. Then, we decided that that gives way too much weight to tasks that are almost automatic (@olebole contributes a lot back to astropy form Debian's tests on exotic architectures, but most maintainers just update the version number every now and then) and we removed the sub-roles. The result is that the entry is now almost pointless, because we don't even know why some of those names are on there.
So, the question for what's listed as a role or sub-role should not be "how much work is it?" but "Is this a distinct task where someone might need contact information for the person doing that task?" For that, I would support linking contact information (e.g. email or slack channel or GH handle, depending on the role). The infrastructure team is well organized, talks to each other and coordinates among themselves who does what, so one contact is sufficient. On the other hand, the twitter person won't be able to help with a discourse configuration issue or the other way around, so they are listed as separate sub-roles.
In contrast, the credit for work is on https://www.astropy.org/credits.html.
I'm all for cleaning this up in a systematic effort, but we have to take care not to throw out the baby with the bathwater.
Reacted by Marten van Kerkwijkdistinguish between credit for work and a "contract list" like a phone book
I don't know what people really use this page for but it is apparently high visibility. Personally, I only look at the subpackage section so I know who to bug to review PRs. But I have also heard others use this page "as CVs" (unconfirmed). So, we cannot tell people how to use this page, but rather we should try to reflect the state of task assignments without appear to overly emphasizing a subset of them.
https://www.astropy.org/credits.html is a totally different beast. You can spend a lot of time maintaining something and not end up on that page until years later. If that is the sole "metric" we use for "credit for work," I would worry.
whom to contact for DNS upkeep
This is almost a security risk. I don't think we should even mention it publicly any server-side or account specific info (that includes Twitter).
The infrastructure team is well organized
Just because one part is well organized now does not mean it will be in a month. That is the inherent risk of OSS where people come and go. We should not give more "air time" (for lack of better words, it is late here) to things because they are not well organized. Therefore, I disagree with this being a reason on whether something end up on the page or not.
This reply also applies to #524 (comment) .
take care not to throw out the baby with the bathwater
I agree, though I think a lot of debates will occur on which one is the baby and which one the bathwater. 😹
whom to contact for DNS upkeep
This is almost a security risk. I don't think we should even mention it publicly any server-side or account specific info (that includes Twitter).But then, how do project members know whom to ask? Needs to written down somewhere?
The infrastructure team is well organized
Just because one part is well organized now does not mean it will be in a month.
Sure. But when that happens, and the tasks get split over more people we can add more roles again. This is a living document, pretty easy to change again.
Like @hamogu and you, I mostly use the page to find out who to ping (and mostly for the core subpackages). All the suggested changes seem to be just to clarify that, which I think is a good idea. Let's not worry about how else the page may used outside of astropy.
Astropy.org web page maintainer
This is the maintainer in the sense of a sub-package, someone who maintains the repo and so on. This also includes DNS, etc. The
sites.jsonis nominally part of that, but it's a lot harder to keep up with than some of the other stuff. Maybe we should add a separatesites.jsonrole to highlight that's extra additional work? (And e.g., I would not put myself there since I haven't had enough time to keep up with it)I got feedback from several different people. Seems like there are very different opinions on what this page represents and what should or should not be on it. I think I need to step back a little and look at the bigger picture first. 💭
Hello. I am sorry this dragged on and I never really saw it to completion. But hopefully I got the ball slowly rolling and people thinking about this (though I am sure you rather not, haha). This task is now on the plate of CoCo7. FYI and thank you for your patience.
Motivation: Over the years, the Project has evolved more quickly than
roles.json(that renders to https://www.astropy.org/team) can be updated. As a result, there are now roles that do not exist anymore (or inactive) and people who do not really fill existing roles anymore. I would like to submit a series of PRs to update this listing, or at least put the roles in discussion.Depends on:
Also might be relevant:
Existing roles (as of 2023-03-06):
I don't know what this means. If this is simply who holds the DNS account, I think this is overkill and can be removed. If not, please clarify what this role actually does. If this includesAdd Derek and Moritz to website maintainers for sites.json #545sites.json, then Moritz should be on there.astropyalso but we don't list them. Ideas welcome.constants-- This is low-activity and looks about right. No further action needed.convolution-- Is Axel still active? Need to find out.coordinates-- So many maintainers, truly? Need to double check. Remove me from coordinates and utils maintainer role #603cosmology-- Single point of failure though maintainer is active. Looks about right. 😆 No further action needed.io.ascii-- Looks about right. No further action needed.io.fits-- Single point of failure though maintainer is active. Looks about right. 😆 No further action needed.io.misc-- Roles: Remove Ed Slavich from io.misc #612io.votable-- Have not seen Boch in a while. Need to find out.modeling-- Looks about right. No further action needed.nddata-- Matt is still stuck with it but has a plan that is out of scope here. No further action needed.samp-- Yup, no one. Someday maybe Move astropy.samp to pyvo pyvo#155stats-- Single point of failure though maintainer is active. Looks about right. 😆 No further action needed.table-- Looks about right. No further action needed.time-- Looks about right. No further action needed.timeseries-- Have not seen a lot of activities here. Need to double check.uncertainties-- Have not seen a lot of activities here. Need to double check.units-- Looks about right. No further action needed.utils-- I think this is mostly Marten and I nowadays. Need to double check. Remove me from coordinates and utils maintainer role #603visualization-- Looks about right. No further action needed.wcs-- Looks about right. No further action needed.astroquery-- Is Clara still active? Need to double check.astropy-healpix-- This is low-activity and looks about right. No further action needed.photutils-- Need to double check. Roles: update photutils maintainers #599ccdproc-- Is Matt still developing it? Need to double check.specutils-- Some names are no longer active there. Need to double check. specutils: Add Brigitta as maintainer because she already is in the team #548 Roles: update specutils maintainers #601reproject-- Is Stuart still involved? Need to double check.regions-- Looks about right. No further action needed.asdf-astropy-- Looks about right. No further action needed.specreduce-- This entry is completely missing. We need to add this and clean up access. Roles: Add specreduce to Coordinated section #521 and specreduce: Add Kyle and Clare as maintainers because they already are #547