Ubuntu Wiki

Background

At the beginning of a new development cycle, Ubuntu developers from around the world gather to help shape and scope the next release of Ubuntu. The summit is open to the public, but it is not a conference, exhibition or other audience-oriented event. Rather, it is an opportunity for Ubuntu developers -- who usually collaborate online -- to work together in person on specific tasks.

Small groups of developers will participate in short Forum and Workshop (formerly called "BoF"/Birds-of-a-Feather) sessions. This allows a single project to be discussed and documented in a written specification. These specifications will be used for planning the new release of Ubuntu, as described in FeatureSpecifications and TimeBasedReleases.

Participating

• All attendees should register their participation in Launchpad.

• People who are physically attending should see the local participation pages.

• Remote attendees who want to follow along remotely should see the remote participation pages.

• Everyone is encouraged to subscribe to these wiki pages for changes.

Tracks and Track Leads

UDS is broken down into 9 "tracks" that cover all aspects of Ubuntu. These tracks are run by a track lead, who is responsible for scheduling and running sessions in the tracks. these are the people that drive UDS forward - if you have any questions about a session or the schedule you'll want to get a hold of a track lead. See the individual track pages for more information.

Proposing Blueprints for Discussion

Video Walkthrough!

If there is a blueprint that you would like to propose for discussion that is not already on the UDS specification list:

• https://blueprints.launchpad.net/sprints/uds-m

Subject to a few constraints, it'd be great if you could register your own blueprints and propose them for discussion. We'll have our magic auto-scheduler find time for the required people in one of the spare rooms.

The constraints are:

• the specification must be assigned to somebody attending UDS
• that person must have agreed to implement the specification
  • (ie. don't assign it to someone who you saw on a mailing list without asking!)
• all required participants are attending UDS, or able to participate remotely

The deadline for proposals to be received is TBD, at that time we'll begin reviewing the proposed list and accepting chosen discussions onto the schedule.

(If you miss the deadline, there will likely still be plenty of time and space at UDS to have your discussion - it just won't appear on the official schedule).

Here's what you need to do:

1. Make sure you have a Launchpad account, that you've confirmed your attendance to UDS and expressed interest in relevant tracks and topics. (See above)

2. Go to https://blueprints.launchpad.net/sprints/uds-m and make sure that your specification (or a similar one) has not already been scheduled.

3. Go to https://blueprints.launchpad.net/ubuntu/ and click the "Register a blueprint" button.

4. Fill out this form, with the following particulars:
   

   • Name: the "launchpad name" of the blueprint, it's common practice to begin this with track name and letter, so "desktop-m-monoflamewar".
     Title: a more human-readable title equivalent of the name. e.g. "Improved iPhone support", "Remove Mono Flamewar"
     Specification URL: a wiki URL to the specification, common practice is to turn the "launchpad name" into a Wiki name. e.g. http://wiki.ubuntu.com/Specs/ImprovedIphoneSupport, http://wiki.ubuntu.com/Specs/KarmicMonoFlamewar
     

     • The URL should be created with the SpecTemplate but you should *not* start writing it yet! You need to have the discussion first!
       

     Summary: a single paragraph summary to explain what you want to discuss and/or implement.
     Definition Status: set this to "Discussion"
     Assignee: this must be set to somebody attending UDS, and should often be yourself. Don't assign a spec to someone without asking them if they're willing to implement it first!
     Drafter, Approver: Approver needs to be the track lead, otherwise they won't get the email to schedule your session! Drafter is the person writing the spec.
     Propose for sprint: uds-m
     (if you already have a blueprint registered, you need to make sure the details match the above, and use the "Propose for sprint") link on the right).

5. You probably want more than just yourself to attend, otherwise it'll be a lonely discussion. Give your Launchpad URL to people and ask if they would use the "Subscribe yourself" link to express interest.
   • They may use "Participation essential" if they absolutely want to come, this will only allow the discussion to take place when all "essential" parties are available. Beware though, the more essential people, the harder it is to schedule!

How to Run a Session

• Ensure key people who are needed to be at the spec are present. If not, send runners to track them down before you begin.
• Designate at least one person as a scribe. They will be responsible for:
  • Creating a document on Gobby and taking notes during the session, enforcing the per-track naming method (see below).
  • Transcribing details from the whiteboard into the Gobby session.
  • Involve the people in IRC in the discussion by asking questions that get asked in IRC to the participants
  • If the scribe is also participating in the session then you want at least two people taking notes or things will be missed
• Ensure the IRC channel is displayed on the projector so that remote participants can be seen by the attendees.
• Set an agenda for the session
• Stay away from tangents; if there needs to be further discussion, create a new session on the schedule
• Focus on what can be done for this release, don't waste time talking about a long term plan unless that is part of the goals for that session
• At the end of the session, update Launchpad to reflect the status of the specification.
  • If more discussion is needed, the status should be set to Discussion
  • If discussion is complete, but time is needed to work on the specification, set it to Drafting
  • If the specification is written and ready for review, set it to Review
• After the session, use the notes to draft a specification document
  • It is crucial that the discussion be documented so that the conclusions are recorded and shared with the community
• Gobby Best Practices
  • Save early, save often. If you can, have multiple people saving it.
  • Naming your document:

    • To keep the document list sane, name your documents as $trackname-$letter-$title. Examples: community-m-forums-outreach, server-m-ldap-auth, or kernel-m-bugs.

    • Since gobby keeps this list alphabetized it will keep the document list neat and easier to use.