On Sat, Sep 25, 2010 at 1:12 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > >> > But how should a performance improvement be filed? Bug? Feature request? >> > Or should "feature request" be renamed "improvement"? >> >> It's a feature request (since we won't backport it unless there is a >> genuine performance problem being addressed as a bug fix). Whether >> that warrants changing the name, I don't know. > > I think most people won't intuitively file performance issues as > "feature requests", since it doesn't sound like a feature.
Agreed. >> A third option for >> "other improvement" may also work (since that would also cover things >> like clarifying doc wording, fixing comments, adjusting code to be >> more readable/obviously correct, etc). > > But then why not keep a clear categorization of these "other > improvements"? Because it's asking people to make a decision too early in the process. The clear categorisation as to what *kind* of bug/feature/improvement it is can be supplied later on by selecting the appropriate components and keywords. > By the way, doc wording fixes and cosmetic code changes often get > backported. :) Yep, hence why I think the basic "bug, feature, other" split may be a good way to go. It's a quick and easy decision most of the time (including a clear choice for "I don't know if this is a bug or not"), and makes a meaningful procedural distinction (bugs are usually backported, new features are not, and other changes may be backported depending on the details). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
