Launchpad blueprints
The question about Launchpad's blueprints (specification) system came up today, so I'd like to open a broader discussion about if we want to start using it.
Basically the blueprints system is a mechanism for tracking specification status. You can also include a link to a web page (such as a wiki or even a pdf) where the spec is written up. For Canonical it's used as a workflow system so people can keep track of the state (needs review, in progress, implemented, finished, etc. etc.) of various development efforts. Blueprints can also be prioritized, like we used to do with RFEs, and linked to bug reports. There's also a review/approval mechanism, which (in theory) is used by management to green light projects for engineers to work on for a release.
The reason I've not brought this up before, is because I recognize it doesn't match to the workflow we use in Inkscape. Aside from the Roadmap, we don't really try to keep close tabs on individual developer's work; we're (largely) a volunteer project, so part of me worries such a system could just be extraneous overhead.
However, I can definitely see the usefulness of this if enough of us were using it. First, the process of writing up a blueprint is good discipline for getting ones thoughts and plans in order at the start of a development project. It's also a good communication tool for letting fellow developers know what the plan is and to gain review feedback on your ideas. And it would certainly make release time go a bit smoother, since we'd be able to query and see the state of all development efforts (or at least those using the blueprint system). Potentially we could also subsume the (admittedly poorly maintained) roadmap into it.
Obviously, this also is obviously analogous to (and clearly synergistic with) GSoC's proposal write ups, which seems to work out quite well.
A more tangible benefit (and the reason I bring it up now), is that we have a lot of RFE's in our bug tracker that we could move over into blueprints. This would reduce our bug count, increase the visibility of the feature requests, and give us better tools for collaborative editing and tracking the proposals.
We've already had a couple (brief) blueprints posted:
https://blueprints.launchpad.net/inkscape/
Here's a couple examples of more fully fledged blueprints (look esp. at the wiki links):
https://wiki.ubuntu.com/DisplayConfigGTK https://wiki.ubuntu.com/DesktopTeam/Specs/ExitStrategy
Please give a look at these and consider if this is something we could benefit from with Inkscape. Should we as a project encourage using this part of Launchpad for handling feature requests?
Bryce
On Fri, 2007-12-07 at 12:30 -0800, Bryce Harrington wrote:
Please give a look at these and consider if this is something we could benefit from with Inkscape. Should we as a project encourage using this part of Launchpad for handling feature requests?
I don't think so, I wouldn't discourage people from using them, but I don't believe that they really match the way we do things. I think they would probably be good for GSoC, but basically the same functionality is provided by Google's project management tool. And we still have to put the data into that one for the students to get paid.
I think that they'd be a good way to discuss major changes, but otherwise I don't think they'd be too useful.
--Ted
participants (2)
-
Bryce Harrington
-
Ted Gould