Ubuntu Open Week - Blueprint - Kiko - Fri, Apr 27, 2007
(02:03:42 PM) kiko: hello hello hello (02:04:27 PM) kiko: it's so much easier when it's a Q&A session :) (02:04:38 PM) kiko: hello everyone, welcome to my second UOW session (02:04:49 PM) kiko: (frying wrists to attest to it) (02:05:20 PM) kiko: I'd like to do a quick overview of blueprint, what it's useful for, why you want to use it for your own projects, and then have more or less half the session for questions (02:05:41 PM) kiko: I'm more interested in your questions, in particular because I want you to help us decide where we want to move blueprint next (02:05:49 PM) kiko: but let's start from the beginning. (02:06:13 PM) kiko: I joined canonical 3 years ago because I wanted to help the Launchpad team scale and deliver on-time (02:06:52 PM) kiko: one of the problems we had at the time was that it was very difficult to provide everybody with a good idea of what needed to be done, and there wasn't a mechanism to allow us to double-check if the technical plan was in line with the requirements (02:07:17 PM) kiko: one of the solutions we put into place at the time was having written specifications produced (02:07:26 PM) kiko: now I come from a software engineering background (02:07:43 PM) kiko: and was really familiar with spec processes and how horribly heavyweight they usually are (02:08:01 PM) kiko: so we all made a serious effort to ensure that the process was as lightweight as possible (02:08:36 PM) kiko: basically all you needed to do was write down a summary, rationale, one or more use cases, and a strategical and technical argument for moving ahead with it (02:08:57 PM) kiko: the spec would be written by an engineer or by a customer or by both in concert (02:09:19 PM) kiko: and once written you'd have a sign-off process in which the spec would be approved and ready to be scheduled for work (02:09:43 PM) kiko: this caught on and by the end of the year we had a lot of different projects using specifications to define and track their work (02:10:12 PM) kiko: we used wikis to store the docs, and used little wiki tags to specify metadata about the documents themselves (02:10:43 PM) kiko: now this was high-overhead in management, and at the beginning of 2006 Mark set out to write a better specification management system, which is where Blueprint comes from. (02:11:16 PM) kiko: Blueprint is just a cute name for a specification, though my friend SteveA says it's the proper noun to be used in this context (02:11:45 PM) kiko: and essentially, what the Launchpad blueprint tracker does is capture and track metadata related to a textual document (02:12:22 PM) kiko: the actual document itself can be kept anywhere, and while there are plans to offer a spec hosting facility as part of Launchpad, you can keep the specs wherever it is convenient for you to maintain (02:12:32 PM) kiko: the blueprint tracker requires only you have a URL to point to. (02:13:07 PM) kiko: there is quite an assortment of metadata that can be associated to a particular spec, and I don't want to go through an exhaustive list (02:13:17 PM) kiko: but effectively you can track separately: (02:13:29 PM) kiko: - people: author, approver, developer (02:13:43 PM) kiko: - priorities and target series and release (02:13:50 PM) kiko: - status of document completion (02:13:53 PM) kiko: - status of implementation (02:14:16 PM) kiko: - whether or not the direction of the document is approved (02:14:28 PM) kiko: - any bugs which are related or relevant to the spec (02:15:10 PM) kiko: in association with the specification concept, Launchpad has one additional feature that is useful for managing events around specifications, and that's the sprint management system (02:15:33 PM) kiko: the sprint management system was born totally out of the need to better coordinate Canonical's own meetings (02:16:02 PM) kiko: but perhaps unsurprisingly a number of other teams and OSS projects get together regularly to plan ahead and to specify solutions to existing problems (02:16:25 PM) kiko: the idea behind the sprint tracker is to help organize people and timeslots for discussing different specifications (02:16:40 PM) kiko: it's cool that in a way this ensures that some written record of the sprint itself survives (02:17:41 PM) kiko: but it's also a massive help when you have a large number of participants and want to maximize the value of the meeting to people, ensuring that they are able to attend the meetings they would appreciate and contribute to the most (02:18:13 PM) kiko: soooo (02:18:27 PM) kiko: that is a general overview of blueprint, the launchpad application. (02:18:47 PM) kiko: in a way blueprint is one of the least interconnected apps in Launchpad, because a blueprint is associated to one single project (distribution or upstream) (02:19:04 PM) kiko: but there is richness in the way it links to the Launchpad population (02:19:18 PM) kiko: and also to bugs and other specs (via dependency graphs) registered in Launchpad (02:19:59 PM) kiko: ah (02:20:26 PM) kiko: I didn't mention that specs have subscribers, which will get notified of changes to the specification (through a cunning robot subscriber) or to its metadata (02:20:36 PM) kiko: specs also have whiteboard that reviewers and developers can use to communicate status (02:20:49 PM) kiko: finally, specs can be linked to implementation bzr branches (02:21:12 PM) kiko: which allows you to hop from requirements to code in a simple step (02:21:27 PM) kiko: and which allows you to get great traceability inside your project. (02:21:42 PM) kiko: finally I want to spend a minute or two to discuss why specs might be useful for your project. (02:22:11 PM) kiko: so the reason why Canonical and Ubuntu decided to use specifications is related to the problem we all face in OSS (02:22:37 PM) kiko: and that's the fact that we have very little face to face time, and a lot of complex and detailed issues that need to be looked at and solved. (02:22:56 PM) kiko: specs are really a great way to convey this knowledge across a distributed team (02:23:06 PM) kiko: allowing people to collaborate on specifying the problem and its use cases (02:23:18 PM) kiko: and then taking stabs at providing alternative solutions to the problem, in increasing detail (02:23:46 PM) kiko: they are also easy to write, which lets people just kick one off by writing a few sentences on a text document (02:24:12 PM) kiko: (ease of starting a spec is part of the reason the process was so successful at Canonical, IMO) (02:24:35 PM) kiko: specs allow us to try and manage the ambiguity that exists in other communication (02:24:54 PM) kiko: and also allows us to stack up a repository of useful developer documentation about individual features (02:25:23 PM) kiko: when a new hacker joins the Launchpad team, part of his initial time is spent reading through existing specifications (02:25:33 PM) kiko: and in hindsight their comments are often surprising (02:26:01 PM) kiko: because they will have seen how bits were proposed and how they effectively implemented and rolled out (02:26:06 PM) kiko: it's fascinating (02:26:22 PM) kiko: aaaaaaaanyway (02:26:57 PM) kiko: I believe that any project which is larger than two people can really benefit from having written documents that describe how and why its new features are designed (02:27:02 PM) kiko: and starting with Launchpad's blueprint tracker makes that easy (02:27:23 PM) kiko: so you can join when you like and try it out without committing to moving your docs en-masse. (02:27:34 PM) kiko: finally, we can help assist migrate your specs into Launchpad (02:27:53 PM) kiko: and with that remove a barrier to adoption that you may find with the tool (02:28:27 PM) kiko: there's a lot more I'd like to discuss, but this is the general overview of Launchpad Blueprints (02:29:54 PM) kiko: I'd like to at this time request interesting, controversial, difficult and unexpected questions (02:29:59 PM) kiko: about blueprints in particular (02:30:21 PM) kiko: but also about launchpad, and if time allows, to the incredible world of professional cycling (02:30:24 PM) kiko: err where did that come from? (02:30:33 PM) kiko: blueprints and launchpad I meant
<samgee> QUESTION: How do you migrate external specs to Launchpad?
- we have a spec importer that we massage into the metadata format that your spec system offers. in the simplest case it just registers remote URLs with a name and a person, but there are richer alternatives if you have a metadata format encoded, such as Python's PEPs or Zope's specifications. the custom code is managed by us, but if you have specs you'd like to import, irc-ping or email me and we'll sort it out for you.
<illu45> QUESTION: I understand that Launchpad and Blueprints is mainly designed for developers, but are there also ways for non-developers/non-coders to get involved?
- definitely yes. in a way neither Launchpad nor Blueprints are /really/ for hardcore developers. developers are an important user group for the bug tracker and the code management system and in some ways to blueprints, but more often than not we have end-users, customers or managers involved in producing and enginering specifications. sure there is some level of technical ability necessary. but even without technical proficiency you can do well in presenting a rationale and end-user use cases which an enginner can work on afterwards. end-users should definitely be involved in defining specs and I look forward to more of them participating.
<auTONYmous> QUESTION: Does either launchpad or blueprint support things like WebDAV/CalDAV/RSS for extenstion to/from outside sites or desktop apps?
- we do have RSS export of certain bits of data. blueprint I don't believe does, but it'd be easy to write and export. so that you could try the latest blueprints registered and changed and a person's currently assigned set of blueprints. in general Launchpad will evolve to be more machine-friendly this year, after the 1.0 release.
<Monika|K> QUESTION: Is Blueprint only for textual specifications or also for graphical ones like UML?
- you can track basically /anything/ which can be made available via a URL. we don't really look at the contents of the URL today, though we may do some things optionally. we won't relax the fact that you can point to any URL from there, though.
QUESTION: What projects are using Launchpad/Blueprints other than Ubuntu?
- whew good one. check some of these out:
<Amaranth> Perhaps I should narrow that to "large projects" aha, you want to get tricky, so Launchpad uses blueprints
<Amaranth> I remember hearing about zope and python, for example. and while I don't think the Zope specs have been finally imported they are also set on using blueprints for it. we have a spec importer for Python PEPs that we will put in action later this year not so many projects formalize specs, but I bet that as we move on more of the ones that choose to will find Launchpad to be a good alternative
<Monika|K> QUESTION: How does the karma system work?
aieee. you really want to get me fired. the canonical description is https://help.canonical.com/KarmaCalculation. currently we decay karma throughout the year. while I know it doesn't decay rapidly I don't know exactly what the speed is, but nominally we want to ensure that people stay active on the system to retain the privileges that more kama entails.
QUESTION: Why is Launchpad so awesome? :)
- that looks like a question looking for a karma boost! I think launchpad is very cool because it's the first time we've actually tried hard in OSS to provide a good way for projects to share and communicate between themselves. intra-project communication has always been a strength in OSS, but inter-project is much harder, and can give us the benefits if we find out how.
QUESTION: What do you want to see for launchpad in the future? What plans do you have for launchpad in the next 6 months, etc?
- phew! I'd like to see OOPSes and timeouts down to zero; currently we're really good but I liked it when we were perfect. this requires the translations side of things being refactored, among other things in terms of features, there are a lot of things I want to see done.
- - comprehensive external bugtracker linking and communication - searching through translations - end-user package repositories - bzr integration throughout - better management of the project registry - more interactive UI designs
there are a lot of specs registered on the launchpad project. if you don't believe me, see https://blueprints.beta.launchpad.net/launchpad-project for an idea of how many items are lined up and pending release
<Amaranth> (most of us can't see the beta version)
grumble. https://blueprints.launchpad.net/launchpad-project. that's what I meant!
(02:58:04 PM) kiko: okay, since you didn't let me discuss how flecha has finished three times in the top three for the past three years in paris-roubaix (02:58:13 PM) kiko: I will thank you all for our time and attention (02:58:27 PM) kiko: and invite you to come along to #launchpad and ask me to import all your specs! (02:59:19 PM) kiko: there are a lot of friendly launchpad developers around that can help you with your migration if you have made up your mind (02:59:19 PM) kiko: and we can set up evaluations on test servers if you want to see what things are like. (02:59:23 PM) kiko: let me know via IRC or email (kiko AT canonical DOT com) if there's anything I can do for you (02:59:57 PM) kiko: and enjoy the next session.. but remember that while enjoying yourselves you should not share needles! (03:00:07 PM) ***kiko waves and blinks out