Improving Launchpad bug workflow for opportunistic programmers

I’m a talented software engineer. I have a good deal of application programming experience on Windows, Mac OS, Linux, iPhone, Android, and the Web. I’m crazy about style guidelines, correctness, functional decomposition, self-documenting code, explicit documentation, code review, unit tests, etc. I’m confident that for most application codebases, I could learn my way around quickly enough to make meaningful bug fixes and other improvements.

Despite being good at these things, the barrier to entry for fixing a bug in any given application (paper cuts are a very good example of the kind of bug I’d like to fix) is still very high for me. I am lousy at chasing down dependencies, maintaining clean build environments, generating patches, and dealing with unfamiliar version control systems. I know next to nothing about packaging or publishing PPAs. Some of you may read this and think, “well, that’s your fault–stop complaining and learn these things,” but I contend that there are very many talented, opportunistic programmers just waiting to contribute by doing what they do best–writing code. These eager programmers are similarly hindered by this barrier to entry, and we would benefit more by accommodating them than by insisting that they accommodate us. Furthermore, we have the ability to completely automate the stuff that isn’t software development and hide its complexity from developers–in fact, we’re already mostly there. To illustrate my point, I present my ideal user story for fixing a paper cut.

I want to fix bug #511767, “‘Hash for Duplicates’” is tech-speak.” F-Spot has a great feature for finding duplicate images in your photo library and getting rid of unwanted copies; however, this useful feature is exposed to the user under the label “Hash for Duplicates.” The user likely doesn’t know what hashing is. Besides, the user wants to find duplicates, not hash them–hashing is just an implementation detail. To fix this bug, I click “Quickly fix this bug,” right on the bug report in Launchpad:

Automagically, an application on my machine opens to handle the URL behind the Quickly fix link (e.g. lp://fix/?bug=511767). This application performs the following steps on my behalf:

1. Runs apt-get build-dep f-spot to prepare my machine to build the package affected by the bug.
2. Runs apt-get source f-spot to download a source package that can be built on my machine.
3. Opens the f-spot source in Eclipse*, where the source package is built for me.
4. …and presumably cleans up the mess after I’m done.

* Why Eclipse and not [insert your favorite IDE/editor here]? Because Eclipse is extensible, popular, cross-platform, and supports many different languages, but most of all, I picked Eclipse hoping we could just skip the endless debate where everyone argues that we should use the IDE they wrote “Hello, World” in once.

With the exception of typing my password if needed, the next thing I should see after clicking “Quickly fix this bug” is the F-Spot source package open and built in Eclipse, where I can “quickly fix” the bug: