Response to Steven
Thank you for the detailed reply Steven! I agree that there are plenty of nuances to work out. I’ll respond to the points you’ve raised.
It’s not clear to me why we only care about frequently made
enhancements as opposed to other forms of bug reports.
You are right, we should document anything that ends up in the bug tracker repetitively here. I invite anyone to brainstorm a better name! Here are a few suggestions:
- Frequently Reported Enhancements and Bugs
- Frequently Reported Things
- BPO Frequent Flyers
- Repetitive BPOs
etc…
For example, you mention the CSV module. I don’t recall seeing any
requests for enhancements, but then if I had, I would have probably just
deleted the email and ignored it. Whereas my entirely subjective feeling
is that barely a week goes by without yet another spurious “Python can’t
do maths” bug report.
I think this gets at the fact that everyone has their own pet peeve issues on the bpo. A goal of this document would be to make it easier for core devs and triagers to link to a definitive source about the history of the discussion of an issue without needing to provide an explicit explanation or search up some past example bpo’s as I normally see.
Another issue is that today’s frequently rejected enhancement can be
tomorrow’s accepted feature
I definitely understand this, and of course it’s important to discuss these issues over time. I think that the document should start with a paragraph to contextualize what follows, and to ultimately communicate these points:
- These topics are not “banned” or even discouraged – this is just a knowledge base for frequent (or sometimes repetitive) discussions; HOWEVER
- You should read the former discussions, and see if there are perspectives you haven’t considered
- You should message
python-ideas
(email or discourse), which is a friendlier and more contemplative discussion forum than the python bug tracker. If you can achieve some consensus about a fix or forward-step there, a request for concrete changes in the bug tracker will be much better received.
Benefits and Use-Cases of This Doc
I want to talk a little bit more about the benefits and use cases for this document to further clarify what I’m envisioning.
Strengthen New BPOs
When contributors read this document first, new bug reports about repetitive issues will be stronger. They might take the issue to this forum or the python-ideas
mailing list, or at the very list they will read and be prepared to respond to the ideas in this document. Discussions about these long-running and common problems will be built upon a stronger foundation, which will actually help to push discussions forward faster.
Service Core Dev’s Pet Peeves
I think that a lot of core devs have pet peeve issues that they are tired of dismissing in the same way. Obviously actual core devs will know better than me whether that is actually the case If so, this document can become a definitive source about the problem. If bug reporters appear to not have read the document, they can just link to it without putting too much mental energy towards the issue, and the reporter can follow-up after they have absorbed the additional context.
Index of Related BPOs
Topics in this doc should end with a list of the BPOs related to the issue. Of course, it would be ideal to include BPOs about the issue that have lead to merged pull requests to show that this isn’t an off-limit topic, it just has nuances that must be considered. This would be doubly good, because it provides a model for which reports led to positive changes, versus ones that hit dead ends.
Citing BPOs also ensures that the topics in this document are grounded in real repetitive bug reports. I think it is important to ensure that it doesn’t become a divisive place where people try to shoehorn in the things that they just don’t want to see changed or discussed.
Maintaining this Document
Avoid Pedantic-ism
The document should establish a culture of discussion and provide the context around these complex issues in a neutral way without implying that the problem is off-limits. We also don’t want it to become a place where people try to shoehorn in things that they don’t want to see discussed.
Automation?
I’d be happy to solicit suggestions and then write this document by hand to start with, but I’m thinking that the burden of maintaining this document might be problematic, especially since its purpose is supposed to be to smooth out discussion and save time!
I’m not really an expert in automated workflows, but I’m hoping others might share some bright ideas!