FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Server Development

 
 
LinkBack Thread Tools
 
Old 05-16-2012, 08:34 AM
James Page
 
Default Use of Blueprints + Blueprint Template

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Team

I've spent some time with various members of the Ubuntu Server Team
over the last few weeks reviewing how we use blueprints to track
progress during the development cycle.

This was really with the objective of trying to resolve a few
challenges that we have with current usage:

1) It's often hard to evaluate exactly when a blueprint has been
completed.

2) We sometimes have challenges with understanding the use cases for
work.

3) What the overall goal is for a blueprint is not always clear.

4) Endeavouring to bake QA into all work we do.

When I first started contributing to Ubuntu we did try to write
specifications associated with each blueprint (see [0] for the
template).

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.

1) Blueprint Summary

Rationale:

One or two paragraph statement about why we are doing this blueprint.

Goal:

Overall goal for the blueprint.

2) Blueprint Whiteboard

User Stories:

User stories really help thrash our what the requirements are and why
we are actually doing the work. They should try and encompass how you
think the output of the blueprint will be used by real people.

There may of course be multiple stories for more complicated work.

Assumptions:

What assumptions are being made about the delivery of the blueprint.

Test Plans:

This is really about validating user stories; I find its helpful to
think about these as high level processes - then they can either be
hand cranked by people who want to try stuff out or do manual QA OR
they can be automated.

..or they might even be covered by existing automated test cases.

Release Note:

One or more suitable statements that could be included in the release
note for the release associated with the blueprint.

I've worked this into one of the blueprints that I will be driving
this release which is a) simple and b) already well defined - see [1].

So a few comments about the above:

1) Its not going to fit every blueprint we write - but I think it
should cover most of them!

2) I think that having everything in the blueprint will help with
keeping it up-to-date as its the place we all go to see what needs to
be done.

3) Interested people only have to subscribe in one place and they can
then see when stuff is updated. Has anyone ever subscribed to a spec
in the wiki?

4) The original Specification template also included a section for
'Design' - I personally think that Design should really live past the
lifetime of a single blueprint and should be delivered as
documentation - probably in the wiki - and referenced from the blueprint.

I will be doing this for my blueprints this cycle - it would be great
if other people could try this out as well as they write up their
blueprints from sessions at UDS.

One feature that is currently lacking in the whiteboard is the ability
to track changes over time (although you could do this through
diligent monitoring of blueprint email spam). Its possible that we
might start managing the whiteboard content in a bzr branch and
updating the blueprint periodically - but that's still work in progress.

Cheers

James

[0] https://wiki.ubuntu.com/SpecSpec
[1] https://blueprints.launchpad.net/ubuntu/+spec/servercloud-q-tomcat7
- --
James Page
Ubuntu Core Developer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJPs2aUAAoJEL/srsug59jDg2wQALfgoz/9BX7WrT7mDqexXDbY
4XA9aMjuVrbMIOgh4/qGN0eGPrGdbxBpOWCYeGphoXdYeaEp9D9VXsH/bywVYjHn
VVlfgo2ewar/wRIOHNXG+JWDLrHLhDUxLSywEof4g/5UPl3ybRjyr72U3eTZ2RCv
VS6OHd4MchBfl/CF+ZyyIaraFQxLBskXxh8AsLDj4eBrpiwopaYnTddcOLvAUkXH
jxhHbXeLX6I6RgUIbVpVHhnnWBSf72EvXue39g4+pxy/rjgBY9LIxUk6iBAMiRIN
Wo6sLUHG+Ibg/k8w50sCPPSMpObHbqVStWGb5gcejUrScpsSsv//u8tYYtYkLtJi
owcIjzj8pDLIdQY0L0NWpzs/+KN3jXRYJATX9/5eLc1Dm9qWnv5gW6iF/0GqHMs0
tgB1rxq5mMIDyG35e7SLedB/mZkV6/OO/vZl6dw0FtPGyuxFf4bEeUR+49AkORUR
63tch+nNoRkjPMe93SKZrhiSIvcf5837Q6kWu9ZLlvUDgpv0xm wSoDcPjs+6hdZJ
uMyUYlRTtdRBsHiVLEYC3EJCYES+AGjnb2hJmEz7PDxvyJITwP LqRnxotTSY4FKl
WqOBCU2v18VA4IEjLOM+kYq022Sh+Pco+JUk0BNL6TzaI0TzZm l7mGkhzP9tnIE1
cverNrgeB8j05pM7BVaX
=I+IH
-----END PGP SIGNATURE-----

--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 
Old 05-16-2012, 11:19 AM
Thierry Carrez
 
Default Use of Blueprints + Blueprint Template

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

--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 

Thread Tools




All times are GMT. The time now is 06:36 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org