[Python-Dev] Re: Announcing the new Python triage team on GitHub
On Thu, Aug 22, 2019, at 6:06 AM, Victor Stinner wrote: > Hi, > > Oh, I just wrote a similar email to python-committers, I didn't notice > that Mariatta wrote to python-dev and python-committers. > > https://mail.python.org/archives/list/python-committ...@python.org/message/53K5MJAKLRGY2F34ZCYGL3WPWSJ4C5M2/ > > My worry is more about closing pull requests. > > > Le 21/08/2019 à 22:13, Raymond Hettinger a écrit : > > 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. Our bar for becoming a triager is > > somewhat low, so I don't think it makes sense to give the authority to > > reject a PR or close an issue. > > Closing an issue (on GitHub) is not new compared to the previous > "Developer" role on bugs.python.org. When I gave the bug triage > permission to a contributor, I always warned them that closing an issue > is the most risky operation. I asked them to ask me before doing that. > > In practice, I don't recall a triagger who closed an issue, but someone > else complained that the issue should be reopened. In a few specific > cases, the original reporter was in disagreement with everybody else and > didn't understand why their issue was not a bug and will not be fixed, > but it wasn't an issue about triaggers ;-) > > The risk of closing an issue by mistake is quite low, since the bug > remains in the database, it's trivial to reopen. Closed bugs can be > found using Google for example (which doesn't care of the bug status), > or using bugs.python.org search engine if you opt-in for closed issues > (or ignore the open/close status in a search). The topic has been > discussed previously (sorry, I don't recall where), and it was said that > it's ok to give this permission (close issues) to new triaggers. > > Now there is the question of giving the "close pull requests" permission > to new triaggers ;-) But, is that really any different from being able to close issues with attached patches (in pre-github-era)? What I am coming from is that what one has permissions to do and what one should do has been different. We caution people with permissions to use them judiciously. Some possible use case of a triager having permissions to close PRs that I can think of is old PRs that are abandoned/don't apply (no replies after repeated pings on the PR). I understand that there are use cases where the abandoned PRs can use some love and be rebased/fixed, but that information links don't go away if the b.p.o issue is still open. A person interested to look for motivation from old implementations can still find the linked PRs from bpo. Or, if the issue/feature request was rejected by a Core Dev in b.p.o or the related b.p.o issue is already closed, it is okay I guess to close the PR, with proper reasoning of course. Especially given that closing an issue doesn't close all the associated PRs. > > Victor > -- > Night gathers, and now my watch begins. It shall not end until my death. > ___ > 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/ADUP3UDMKOGCZ6MSUIMRZRY6M7VHBW62/ > -- thanks, Abhilash Raj (maxking) ___ 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/PBVT6Y5PHXDGT2VE7Z4SEBGWZZABIHEY/
[Python-Dev] Re: python-ideas and python-dev migrated to Mailman 3/HyperKitty
Wes Turner wrote: > Thanks for getting these upgraded. IMHO, being able to copy URLs from list > message footers as references in e.g. issues will be a great boost in > productivity. This is possible to do using "$hyperkitty_url" in the message footer. You can request the list owners to add that. > > On Friday, June 7, 2019, Stephen J. Turnbull < > turnbull.stephen.fw(a)u.tsukuba.ac.jp wrote: > > > Barry Warsaw writes: > > On Jun 6, 2019, at 09:15, David Mertz > > > > > > > The old URL is definitely a lot friendlier, even apart from the length. > > > > Unfortunately, the old URLs aren’t really permanent. > > True. That could be addressed in theory, but it would be fragile (ie, > > vulnerable to loss or corruption of the external database mapping > > messages to URLs). Calculating from the message itself means that if > > you have the message you can always get where you want to go. > > > > The new URLs are guaranteed to be reproducible > > from the original > > message source. The downside is that they are less friendly. > > They could, however be made more friendly than they currently are. > > There's no reason (in principle, of course it requires changing code > > and the DNS) why your message, currently given the Archived-At URL > > > > https://mail.python.org/archives/list/python-dev@python.org/message/ > > EFHTPGCSB5VZSRS3DDXZN6ETYP5H6NDS/ > > > > couldn't be given (A is for Archives) > > > > https://a.python.org/python-dev@python.org/EFHTPGCSB5VZSRS3DDXZN6ETYP5H6N > > DS/ > > > > which gets it down to an RFC-conformant 76 characters. ;-) Of course > > many lists would overflow that, and I agree with David that > > > > https://a.python.org/python-dev@python.org/2019/06/ > > EFHTPGCSB5VZSRS3DDXZN6ETYP5H6NDS/ > > > > would be better still. Although the risk of collision would be orders > > of magnitude higher (the date buys us some leeway but not much, we > > could make the ID-Hash be 2019/06/B5VZSRS3DDXZN6ET (arbitrarily chose > > middle 16), giving > > > > > https://a.python.org/python-dev@python.org/2019/06/B5VZSRS3DDXZN6ET > > > > (67 characters, allowing a few more characters for domain names and/or > > list names -- note with the current scheme, a domain name which is 1 > > character longer probably uses up two more characters of space). > > Are these message IDs or hashes? > Do they have to be (is this) base-36? > Could they instead be base-62? (26+10+26) > > > > > > None of this is very attractive to me, for reasons I will go into on > > Mailman-Developers or gitlab.com/mailman/mailman/issues if you want to > > file one. Briefly, people who want bit.ly-length short URLs won't be > > satisfied, and the proposed URLs are more useful but still ugly. > > We shouldn't just drop extra date information from the URL and only lookup > by the messageid unless we add a redirect to the correct dated URL; because > caching and trickery. > > > > > > Personally I think we should all just switch to RestructuredText- and > > Markdown-capable MUAs, and kill off both ugly visible URLs and HTML > > email with one big ol' rock. > > While I personally prefer .rst and .md, hovering over URL anchor text takes > unnecessary time (and I'll remember whether I've been to the actual > http://URL, but not 'here' and 'there'). > So I'm fine with ridiculous, preposterous long links (even in the middle of > the email; without footnotes to scroll back and forth to) > > > > > > Steve > > ___ > > Python-Dev mailing list -- python-dev(a)python.org > > To unsubscribe send an email to python-dev-leave(a)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/O3T27UUHKKXATOPJT4KEQHREUGYVMELV/ > > ___ 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/BIGAWAPAQZXQ4B6NGDA34VYKUS3ULC3N/
