> > 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/XC5IBYYSV3S3VLRB5Y23EBCCZJRB2CMA/
