On Sat, Sep 25, 2010 at 1:12 AM, Antoine Pitrou <solipsis at 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 | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4