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 <maria...@python.org> wrote: > 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. > > > ᐧ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HA5UFFO2TYKLPEKSQL5FIK3WC26NWN6Y/
