A few people had messaged me saying they’re interested to help out and be added to the new Python Triage team. Thank you all for your interest, but I feel like I’m unable to further help you
I’m looking for feedback from core devs and steering council of what are the criteria for promoting contributors to the Python triage role.
And how should I seek approval for the “promotion”? Do I open a poll in python-committers, similar to the promotion process of a new core dev?
I was thinking that it would be great to also remove inactive triagers in bpo. But maybe this is not as important, so maybe we don’t need to bother with it now?
We’ve typically been much freer in handing out triage privileges, since there’s not really any way that a triager can cause irreparable harm (committers can’t really do that either, but they can cause much more difficult-to-fix harm). It basically comes down to whether triage privileges will make it easier for someone who’s already been doing a lot of the work of triage to do more and whether you as the person handing out privileges trust them not to abuse their newfound powers. If a triager missteps we can correct them; if they run amok we can remove their privileges and reverse what they did.
We have few enough triagers on bpo that I don’t think it’s worthwhile to audit them at this point.
Personally, I’m in favor of having opening a discussion and/or poll in python-committers, but with significantly less strict criteria than a core dev promotion. If the feedback is mostly positive and multiple core devs think the candidate would provide a significant improvement to the workflow, that should be adequate. I think it would prove to be beneficial to have some input from the core devs and it would help to serve as a formal introduction of sorts if there are some who are not as familiar with the candidate.
Also, since the process is in motion for moving away from BPO in the somewhat near future, I don’t think it would be an overly worthwhile time investment to remove the inactive triagers over there. The active ones will likely be interested in joining the Python triage team.
Does this mean polling existing bpo triagers also ? Am thinking this undermines the decision taken by whichever core dev gave triage rights in the first place on bpo. I want to think we trust the decision of the core team in giving these roles. or this applies to new people to be considered for the triage role?
From my understanding, this primarily applies to those who are newer to the role. However, the responsibilities on GitHub differ somewhat from bpo. The goals are ultimately similar, but it would be reasonable to require some amount of experience with reviewing PRs, rather than immediately promoting anyone on bpo with the triager/developer role.
The options to me seem to be (in order of the amount of work):
Nothing changes; core dev vouches for someone and they get it
Core dev asks the steering council if they would block the person from becoming a triager, if they don’t object then the person becomes a triager
There’s a vote and as long as 50% vote “yes” the person becomes a triager (don’t know how long the vote would be for)
Same as a core dev; week-long vote and requires super-majority/66% voting “yes”
I do think PR triaging is a bit more involved than bug triaging since you’re now dealing with people’s work rather than a bug someone reported, so the investment of the people involved is a bit higher. But I don’t know how involved others would like to be in the decision process.
I’m finding myself in favor of this option. I had initially suggested the idea of polling, but it might be a bit too time consuming and excessive for the role.
Also, there might be a significant number of core devs who are not as familiar with the candidate. By the time someone becomes a core dev candidate, they have built up a significant reputation across most of the Python development community. It would require some experience and reputation to become a triager, but not quite as much.
If a core dev vouches for someone and the steering council doesn’t explicitly block it, that should be more than adequate. Perhaps another option could be a direct vouch from a steering council member (not mutually exclusive, but as an alternative route).
I would agree that those with triage privileges on bpo should be able to transition that into the GitHub triager role, but it should require some level of experience with PR review. As Brett said (this may have been for a different context, but it still applies):
to be promoted to Python Triageteam on GitHub: there will be no polling. Any core dev can request to the org administrator on GitHub to invite someone to the Python triage team.
people who are already a Developer in bpo (already a triager) can transition to the Python Triage team. They can make such request to any core dev. The core dev can pass the request to the administrator.
people not already a Developer in bpo can also self-nominate to be added to the Python Triage team. They can make such request to any core dev. If the core dev agrees, the core dev can pass the request to the administrator. In this case, they should also be added as Developer in bpo.
If my summary sounds right, I can make a PR in devguide to document this process.
To reduce traffic to the core team, is there a problem or risk with current bpo triagers publicly opening
an issue in core-workflow with details confirming they have triage rights on bpo already and requesting to be added to the Python Triage Team?
I replied in the PR, but for greater visibility: Promoting and recognizing contributors and triagers are responsibilities of core developers.
If for some reason core devs find this too noisy, can they can filter out Github email notification containing “Request for Python Triage membership”
Should that individual be specifically documented on the same page? I’d imagine that would be something which could change over time, which would result in that section having to be continuously updated. Personally I think it’s okay for that section to be more generic, and then list the GitHub admin to contact somewhere on the experts page.
I guess my own problem is I don’t even know who the admins are
I only know @EWDurbin is an admin. Not sure if Ernest should be the only one who can invite people to the org, or are there more than one GitHub admins who we can ping for the triage situation?
You mean option 1?