New GitHub Team with triage access

[pllim]

As proposed by @eerovaher in the 2024-09-05 dev telecon. I have agreed to create this issue as a result of that discussion and will put this issue in the CoCo tag-up agenda on 2024-09-16 for further discussions.

Astropy Project or its stakeholders now hire contractors/staff with dedicated Astropy development time (e.g., @neutrinoceros and @jeffjennings). These hires may or may not have a named role in the Project and usually are only paid for a termed position. In such situation, it would be desirable to have a GitHub Team to give these developers triage access so they can label and milestone their PRs as needed (labels also drive the CI), instead of waiting for a maintainer to do it for them.

At the time of writing, there is no existing team for astropy (the core library) with only triage access. The permission scheme seems to jump from read-only (for assignments) straight to write access (maintainers).

Desired outcome: A new GitHub Team called ~astropy-paid-contractors~ astropy-triage with only triage access to astropy repository.

[taldcroft]

Good idea, I only have a quibble with the name astropy-paid-contractors. Seems like the name should more directly reflect the role, namely astropy-triage or somesuch. It seems credible that we might want this permission level for unpaid volunteers.

[kelle]

I had exactly the same response as @taldcroft: please name it "triage-team" or something similar.

[pllim]

OK I updated the proposed team name in the original post. Thanks!

[hamogu]

I wonder if this distinction is necessary. If someone is involved enough to regularly triage things, they likely also write a lot of PRs, contribute to several sub-packages, know how our workflow works, and quickly earn the trust of the community. In other words, I would expect that after a relatively short period, people who do well with triage access would be nominated to becomes general maintainers anyway.

For that, it doesn't matter if they are contractors paid by astropy, RSEs working at some other institution, grad students doing this on the side, or volunteers with no link to professional astronomy.

So, in my mind, this is an unnecessary step: We should just nominat people to become general maintainers. Astropy is all on git - if someone merges a PR too early, we can always back that out (and that's a mistake that can happen to anyone with write access!). With that in mind, I think it's better for our community to promote people to maintainer status early, rather than have this intermediate step of triage access.

[Cadair]

I think there's no harm in having it to use in more unusual circumstances, but I agree, the risk of giving people merge access to a project like ours with many people paying attention is low.

[pllim]

Low but not zero. Only takes one incident for a fire.

[pllim]

Anyway, this issue can be kept open for discussion even if we rather pursue an alternative.

[Cadair]

Yeah but the risk of us being paranoid about not giving people commit access is our maintainer pool dwindles and the project dies, so you know all security is a trade off.

[pllim]

This issue is not urgent anymore due to other events (links below). But some said to keep this open for future discussions.

• astropy/astropy.github.com#626
• astropy/astropy.github.com#629