Handout

We are making a handout booklet for people with information on UDS so they are aware of the resources available. If you are a UDS stakeholder then please add things here that you think UDS Attendees should know. If you have any questions ping: JorgeCastro

Intro

Welcome to the Ubuntu Developer's Summit, we hope the information in this handout is useful to you to help you get around the venue and enjoy your stay.

The Basics

• Watch your stuff - Please do not leave your laptop and other belongings in an insecure location.

• Please take some time to fill out our UDS Survey at the end of the week - https://wiki.ubuntu.com/UDS-M/Survey

• Tags to use:
  • Photos - uds-m
  • Blogs and Microblogs - #uds
• Check wiki.ubuntu.com/UDS for updates. We recommend you just subscribe to the pages.

Venue Information

• Contact Information

• Maps
• Important phone numbers

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. It's incredibly important that the scope of the session is well-defined and you can remind participants of that when they stray away.
• 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. If you get the feeling that the team is discussing plans that will never get implemented, ask "Who would be willing to work on this?", "Which current problem would this solve?", "Can I note you down for an action item?"
• Note down action items, while they come up. Encourage everybody to spell out action items in a fairly fine-grained manner, that way they are much more achievable and the chance that somebody helps out is much higher.
• If 15 minutes before the end of the session you have no action items yet, stop and review the current notes to transform the notes into action items.

• Also make sure you bring work items into an order where you can easily milestone them. WorkItemsHowto explains how to do that.

• 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-$title. Examples: community-forums-outreach, server-ldap-auth, or kernel-bugs.

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

Network/IS Stuff

• Wireless ESSID: Ubuntu

• Schedule: http://summit.ubuntu.com/

• Gobby server: gobby.ubuntu.com
• IRC: #ubuntu-uds on freenode (redirects to #uds-m)
• Icecast: icecast.ubuntu.com
• Local mirrors:
  • archive.conference
  • ports.conference
  • releases.conference
  • cdimage.conference