Use of Blueprints + Blueprint Template

[Thierry Carrez]

James Page wrote:
> [...]
> I think that this approach did not work that well - often the spec did
> not get updated throughout the cycle as the primary focus is normally
> on work item tracking in the blueprint - so they age and become pretty
> useless very quickly.
> 
> That said there are a few concepts in the specification template that
> I think would still benefit our use of blueprints.  So I'd like to
> propose bringing in some of the concepts we had in specs to the
> blueprint summary and whiteboard.
> [...]

I fully agree with you that the specs document duplicates information
that is now present (and used) in blueprints... especially
"Implementation" vs. "Work Items", so the Spec becomes stale quite fast.
I support using the blueprint as the only reference.

That said, using the whiteboard to communicate part of the spec is not a
good solution: the whiteboard is editable by anyone, and the history is
not kept. I suggest using the "Summary" section instead (which is
editable only by blueprint owners) and keep the whiteboard as an
open-to-all status communication area.

The main issue with this solution is that the "Summary" would quickly
get big. That's where you'd need some Launchpad changes to support your
move. "Summary" could be renamed "Description" or "Spec", and placed
below "Blueprint information", potentially at the bottom of the
blueprint instead of the top.

Additionally, if the "Description" is used for spec, it should probably
support a bit more markup to ease readability (think titles). To get
some room back, you could get rid of feedback requests, which in my
experience are not really used or acted upon.

There have been talks forever about merging blueprints and bugs. If
that's not coming, I suggest to add a bit more features to blueprints so
that there is no need for a separate spec document.

Regards,

-- 
Thierry Carrez (ttx)
Ubuntu core developer