Mariatta wrote:
It still requires earning trust from at least one core developer who will approve their request, which I don't actually believe is an easy > thing to do.
Agreed, it may be a low bar in comparison to the 66% approval required for becoming a core developer, but it's definitely not trivial to achieve (especially for newer contributors). I think that approval from 2 core devs would be reasonable as well though. So far, the 3 candidates who were approved to join the triage team have had support from multiple core devs. If the requirements are going to be modified, it would be easier to do so while the team is still new. It would be less fair to future candidates if those currently on the team wouldn't have met the new requirements. Mariatta wrote:
All "awaiting ..." labels are meant to be added automatically by bedevere-bot. Even core devs should not try adding/removing them > manually. The "awaiting change" is meant to be added only after core devs reviewed the PR and requested change to it, so it doesn't > make sense for a triager to add this label. It requires a core dev's decision.
That was my previous impression, but then I saw that Brett applied it
manually in this older PR to check if the author was still active:
https://github.com/python/cpython/pull/117#issuecomment-367187316. That's
why I figured it was worthwhile to ask about it.
The most common and usual case for the "awaiting changes" label is for it
to be automatically applied by bedevere-bot after a core dev requests
changes, but it seems like it would also be an effective means to measure
whether or not a PR's author is still active (if it's been several months
since the last update from them).
On Thu, Aug 22, 2019 at 8:24 PM Mariatta
The capabilities of a triager mostly look good except for "closing PRs and
issues". This is a superpower that has traditionally been reserved for more senior developers because it grants the ability to shut-down the work of another aspiring contributor. Marking someone else's suggestion as rejected is the most perilous and least fun aspect of core development. Submitters tend to expect their idea won't be rejected without a good deal of thought and expert consideration.
If most core devs prefer that triagers don't ever close PR/issue, then let's document that and let the triagers know of these boundaries. I'd like to be able to trust the triagers and let them help us, instead of restricting their movement.
Personally I think it's ok for them to close PR/issue, especially invalid ones. That's why we need help. If a core dev disagree with the decision, it is easy enough to re-open the PR.
Anyways, I have created a devguide issue for documenting the guidelines/ethiquette for closing PR/issue: https://github.com/python/devguide/issues/527
Our bar for becoming a triager is somewhat low,
It still requires earning trust from at least one core developer who will approve their request, which I don't actually believe is an easy thing to do.
is it possible to adjust permissions in
the Python project?
Nothing we can do. You can try contacting GitHub about it.
My worry is that it *might* require more trust in a
contributor before giving them the triager role.
Yes, but I don't see this as a bad thing. If we want to make it more strict by saying at least 2 or more core devs approving, that's ok with me too.
We could, if we really really really wanted to. Any of the bots can
be programmed to look for closed PRs from people in triage team (and not the author of the PR) and make policy decision to re-open, ping the relevant core dev, remind the person who did it not do it.
I don't think we should though do it though.
I also don't think we should do it.
would it be okay for triagers to manually add the "awaiting changes" label
on PRs that are suspected to be stale?
All "awaiting ..." labels are meant to be added automatically by bedevere-bot. Even core devs should not try adding/removing them manually. The "awaiting change" is meant to be added only after core devs reviewed the PR and requested change to it, so it doesn't make sense for a triager to add this label. It requires a core dev's decision.
ᐧ