Launchpad itself

Feature requests in seperate area instead of bugs

Asked by Craig Hewetson

Wouldn't it be better to have feature requests listed seperate to bugs.

Blueprints are a bit of a overkill when it comes to feature requests or suggestions.

These feature requests can be linked to blueprints if some developer decides to implement it... this also allows the person who suggested the feature to track and comment on the blueprint.

The tabs for each project in launchpad would therefore read:
Overview Code Bugs Feature Requests Blueprints Translations Answers

Question information

Language:
English Edit question
Status:
Solved
For:
Launchpad itself Edit question
Assignee:
No assignee Edit question
Solved by:
Craig Hewetson
Solved:
Last query:
Last reply:
Revision history for this message
Celso Providelo (cprov) said : 		#1

Hi Craig,

I'm struggling to see why a feature-request deserves a separate facet/sub-system. To me a feature-request is still a bug from the user point of view, something is not working as expected, they have an *issue*.

From a product maintenance perspective, you also should not expect users to have enough knowledge to categorize their issues at the level of broken-code, regression, feature-request, etc. This criteria belongs to the developers not the users.

Surely you can use tags to categorize your bugs in a way that suits you better, that's not a problem right now.

Also blueprints do not necessarily represents new features, they simply describe a implementation plan in details. It can be a feature request, but it can also be a migration procedure, a refactoring or even a complex bug fix.

Maybe it's just a matter of elaborating more your use-cases in order to legitimate a 'feature-request' tracker, I just can't see it right now.

Revision history for this message
Craig Hewetson (craighewetson-deactivatedaccount) said : 		#2

Hi Celso

I suppose I'm just used to working differently when it comes to they way I view bugs and features. The users of the software I work on usually sign a specification document that describes each feature of the software in acceptable detail.
When the user encounters an issue or unexpected behaviour he/she can take it back to the specification and shows the development team where it didn't meet the requirements/spec and therefore gets classified as a bug.

On the other hand if the user would like additionally functionality (for whatever reason) then its regarded as a feature request.

There are at least 2 advantages that I can think of right now, for doing this way:
1) The quality of the software can be more accurately shown (number of bugs still open). If the project has 100 bugs opened on it and 50 of them are feature requests then splitting features and bugs would give one a better impression of the quality of the project.
2) The developers can prioritize their efforts (fix bugs first then implement features etc).

Ok, enough said. If I'm the only one with this view on things then I suppose I could just use tags to separate the feature requests from the bugs.

Revision history for this message
Celso Providelo (cprov) said : 		#3

Thanks for the detailed use-case, Craig. Let's see if other people will manifest interest on something similar.

Revision history for this message
Alexander Wolf (alexwolf) said : 		#4

I agree with Craig and would also like to see the possibility to create feature requests

Revision history for this message
Jonathan Harker (jesusaurus) said : 		#5

I believe there is a fundamental difference between a bug and a feature request: a bug signifies that code does not work as expected, a feature request signifies that code does not work as desired. With a feature request there is no broken functionality to be fixed, and most developers consider the distinction to be very important. If the launchpad maintainers insist on using the same facet/sub-system for both bugs and feature requests, then perhaps the facet/sub-system should be renamed to something more all-encompassing such as "issues."