Blueprints at Launchpad and creating a template for blueprints in the future

zequence at mousike.me zequence at mousike.me
Fri Oct 26 09:02:20 UTC 2012


-- New Blueprints --
Blueprints are now at launchpad
https://blueprints.launchpad.net/ubuntu/+spec/topic-r-flavor-ubuntustudio

I've subscribed ubuntu-dev team to this particular blueprint, and one
subcategory:
https://blueprints.launchpad.net/ubuntu/+spec/topic-ubuntustudio-r-workflows.
At least the main blueprint seemed suitable. I suggest we keep doing
this in the future, and use the whiteboard for sending messages when
needed (informing less active developers, who might want to drop in for
a few random tasks).

The blueprints drafting wiki page is now not to be used anymore
https://wiki.ubuntu.com/UbuntuStudio/PreliminaryBlueprintsDraft1304

I've also created this page to help people orientate among the
blueprints with links to them all
https://wiki.ubuntu.com/UbuntuStudio/RaringBlueprintsCategories (is
added to the UbuntuStudio wiki tree , which is a bit under
reconstruction atm)

Blueprints may yet be added or removed, as we are just getting started.
I'm not totally satisfied with the format, but would encourage everyone
to go with it, if it's not deemed radically badly formatted, for reasons
below.

-- About a blueprint Template --
I've added one work item under developer docs about defining a
blueprints template for future cycles. That would be just a barebone of
blueprints, from which you can start from at each cycle (each cycle will
probably need one or many custom blueprints).
The blueprint template should to some degree reflect on the team
structure, so that those who have a certain expertee, or interest area,
will work on the blueprint(s) best suited for them. This is how the
current set of blueprints is designed.
Also, it will make things easier when the format is more or less the
same between cycles.

As the team has been quite small for some time, a thorough team
structure, a comprehensive developer documentation and a wide array of
blueprints may seem like overkill. But, if we want to be able to catch
new developers, especially inexperienced ones, all of those things will
help immensly as a person can more quickly get into doing some actual
work. And, quite often, the work does not take that much time, if you
have all the tools you need to do the job. 

One ambition for this cycle will be to try get more people involved. And
for that to happen, this is one of the structural details that might
need some consideration.



More information about the Ubuntu-Studio-devel mailing list