launchpad developmentBug reports and feature requests are a continuum with no definite boundary. Trying to impose a boundary has little benefit, and significant costs.
<fouadbajwa> hi, who should i post a feature request to for launchpad? |
Quite a number of specifications on the list should really be wishlist (or above) bug reports on the appropriate package ... |
Use the bug tracker (not blueprints) here to report bugs, request features, and contribute patches. |
-- Exaile, a Launchpad "featured project" |
The most obvious cost is that people often waste time reporting an issue in the wrong application, shuffling issues between one application and the other (examples 1, 2, 3), or wondering which to use in the first place. For example, often a seemingly simple bug is reported, but the developers realize that fixing it will be complicated enough to need a specification. To humor Launchpad's data model, you then need to (1) write the specification on a separate wiki, (2) include a link to the bug report in the specification, (3) register the specification under Blueprints, (4) put the tracked blueprint's URL in the specification itself, (5) update the bug report to mention the blueprint, so that the reporter doesn't think nothing's happening, (6) implement the specification, and record it as being implemented, and (7) remember to mark the bug as fixed. It would be simpler and quicker if the specification could be written, edited, and tracked right there in the original report.
(The flip side of this problem is that the existence of "Blueprints" as a separate category encourages people to report ill-thought or incomplete ideas, consuming the time of developers.)
[I] was tracking this work as a spec, unaware that there was already a bug |
Looking at Launchpad, I see a system that loves to throw weird terminology at me, blueprints, drivers, WTF? Especially its hard separation between features and bugs, notion and treatment of "delivery" milestones, approvals and assignments, busts the hell out of me. That may be suitable for your company's business product development and perhaps understood by you and your co-workers after having had a workshop or completing the Launchpad certificate™, but how does that remotely apply to Drupal's flexible and successful usage of issues with various transitioning states...? |
Second, scheduling is slower and more error-prone, because bugs and features are prioritized separately, such that it's not obvious which thing a developer should work on next. FogBugz addresses this directly: "The best way to use priorities is to have a single, global priority scheme across all your projects, bugs, and features, so that every team member can always work down their list of cases in order of priority." Similarly, in Google Code Hosting: "The issue tracker can be used for feature requests, support requests, or any other type of development task that a project needs to track". And in Trac: "tickets are used for project tasks, feature requests, bug reports and software support issues".
Launchpad could address this issue with separate to-do lists or task lists, but that would be adding even more complexity. With a combined issue tracker, the list of open issues would be the task list. This would not require projects with well-established separate specification processes (such as Python or Plone) to start using Launchpad for both bugs and feature requests simultaneously; they could adopt a "bugs only, please" policy if they wished. But for those projects using Launchpad for both, it would become much easier for developers to track all the things they are assigned to do.
Third, there is slower development of Launchpad itself. Having one fewer application would not only simplify Launchpad's codebase, it would also make Launchpad's bug-tracking and feature-tracking abilities both more feature-complete. Bug reports have comments, tags, multiple contexts, privacy, attachments, duplicates, easy linking to/from other bug reports, branch registration, product/package subscriptions, batched notifications, e-mail filtering by header, list sorting, and advanced search; blueprints should have all these things too, but currently don't (bug #3522, bug #3552, bug #58408, bug #49698, bug #68206, bug #72669, bug #113752, bug #126721, bug #137397, bug #147394, bug #147404, bug #218272, etc). Conversely, blueprints have feedback requests, and registration for sprints or hackfests; bug reports should have both these things too, but currently don't. And there are other features missing from both applications that will, if Bugs and Blueprints are kept separate, have to be implemented twice. We should be spending more time implementing awesome stuff, and less time implementing basic stuff multiple times.
Now that the Malone identity has been retired, there is not even any branding benefit in keeping the applications distinct.
Real-world examples
Liu Qishuai implemented Internet sharing in Gnome's network-admin, and wanted to tell Ubuntu developers about the new code. Reasoning that this wasn't a bug, it was a feature, Liu registered a specification in Launchpad, but then found no way to attach the patch. Tragedy ensued.
In theory, the Landscape developers use Launchpad's bug tracking features, while tracking specifications solely using a wiki. In practice, they end up entering mini-specifications into bug reports, because it's so easy to do.
Dan Lipsitt had an idea for different behavior in Launchpad, but he didn't know whether to request this as a bug report or a specification. Nobody else knew, either.
- Jeff Bailey found a confusing page in Launchpad, but said: “I don't know where to file this, since it's not a bug (the page works), [and] not a support request (I know how to make it work).” So he e-mailed me (mpt) about it instead.
Andrew Frank wanted to report problems with Ubuntu’s documentation. He mistakenly concluded that Launchpad did not have an appropriate place for this: “finding a problem in documentation is neither a bug report nor a new feature, so i suggest to add a new heading for such issues”.
Alan Pope expressed a similar sentiment on the first episode of the Ubuntu UK Podcast, when discussing Brainstorm: “Some things you wouldn’t consider a bug, wouldn’t consider a feature request/blueprint … I mean one I’m just looking at now, whilst I’m talking, is ‘Do not install support for Palm devices by default’. Now to me, that’s a valid point. I don’t own a Palm OS device, why would I want support for it? But I wouldn’t be able to consider that a bug, and I wouldn’t be able to consider that really a feature request.”
