At the Ubuntu Developer Summit in Orlando in November there were some great discussions about LoCo governance. The LoCo Council has a [blueprint](https://blueprints.launchpad.net/ubuntu/+spec/community-p-lococouncil) but these are some of the highlights:

* **LoCo Twinning** – the goal here is to twin LoCo teams with other LoCo teams to help them get on their feet and moving. Bugs have been created and the LoCo Council are selecting the teams to pair them with. The team chose five teams they felt were large enough to be able to be twinned but not so big that only large teams were going to be able to twin with them. They are then going to chose five un-approved teams and help them during the cycle on how to get their teams up and running, how to organize meetings and events, and get information to other members of the team and explain how the larger Ubuntu community works.

* **[loco.ubuntu.com](https://loco.ubuntu.com) renaming the main team page** – at UDS a compromise was struck between the LoCo Team Portal developers and the LoCo Council to rename the team display page on the portal (this is because many teams have named themselves incorrectly and don’t want to change now as they have things printed). As such they are only changing the display name on the main page and nothing else.

* **Handling large geographic regions** – the LoCo Council have discussed geographically breaking up some of the larger countries such as Canada, Australia and Brazil (they’ve semi done this unofficially). The idea behind was to better conserve resources (such as conference packs) so that we can have smaller regions that can be sent content for events (e.g. CDs).

* **City LoCos** – it was agreed at UDS that City locos would not happen, but as a compromize, a field on teams pages on the LoCo Teams Portal would be created to add a *contact* for a city.

* **Re-approvals** – in early January the LoCo Council will be focusing on re-appaovals for teams; there are nine on their list.

Thanks to Laura Czajkowski for content for this blog entry, and the rest of the council (Charles Profitt, Chris Crisafulli, Greg Grossmeier, Leandro Gómez, and Paolo Sammicheli) for their tireless efforts. Thanks also to Chris Johnston and co. for their wonderful work on the LoCo Team Portal.

I want to use this entry as an opportunity to throw open the floor for discussion and brainstorming of a topic we first discussed at UDS in Orlando. I really welcome your comments, suggestions, and advice.

One of the interesting things about Ubuntu is that there are many different forms of contribution (typically skills such as development, packaging, translations etc) and different types of tasks (such as fixing bugs, creating documentation, packaging new applications etc).

Traditionally Ubuntu has been very much of an iterative method of contributing; we always have *lists of things to do* such as bug lists, translation string lists, merge proposals, the sponsorship queue etc. As such, many forms of contribution maintaining and tending to these lists and chipping away at them. Thankyou to everyone who helps to participate in this way.

One interesting piece of critique we have seen as Ubuntu has taken a more design-orientated direction is that “*it is difficult to participate in design in Ubuntu*”. I am not interested in getting into a debate over this in this entry (although I am sure some of you will want to anyway ;-)); there is some truth to this critique, but there is also some great work going on to help create a more collaborative environment in the design team. Many thanks to the team for doing this work.

When people offer this critique what they are usually referring to when they say “design” is “*unity*”.

In reality though, Unity really isn’t all that interesting. Unity is a tiny part of Ubuntu; the mere frosting around the edges that lets you find and start applications, find and load files, and other bits and pieces. Unity is cool, but Ubuntu is much more than Unity.

“That’s it, I’m moving”.

Ubuntu is really about *experiences*. How can I create a video of my kid’s first birthday? How can I listen to my music on my remote speakers? How can I show my photos on my TV? How can I record a song with my dad? How can I buy an album and listen to it in my car?

## The Architecture Of An Experience

Each of these examples are the kind of things our users look for in Ubuntu, and I am sure you folks can think of many other examples of cool things we could do in Ubuntu.

With Ubuntu being an Open Source collaborative community, every one of us can help to bring one of these experiences to fruition. While Canonical invests heavily in Ubuntu and focuses on certain experiences, there is absolutely no reason why our community can’t create other awesome experiences too, or refine the ones we already have.

If anyone can do it, it is these people.

Making an experience come to fruition requires some coordination though; it is rarely a one-person job. Imagine you want to create an experience to *stream music to a remote set of speakers*. Creating this experience will likely require different pieces at different levels of the Ubuntu stack. For example, it might require certain *ALSA* or *PulseAudio* features, integration in *Rhythmbox* or *Banshee*, and then some UI to expose the feature to users.

Creating and delivering an experience will also require different skills to deliver it. It might require some programming if the features required don’t exist upstream, will need some packaging to integrate it into Ubuntu, and then require testers, documentation writers, bug-fixers and possible translators. Fortunately, we are community; we each bring our own skills to the fold.

As such, when we decide we want to deliver an experience there are set of technologies that fit together and a set of skills required to help connect these pieces together like Lego bricks to deliver the experience.

## Creating Experience Teams

The session we had at UDS was to discuss methods in which we can encourage and support the formation of *experience teams*; that is, create an environment in which our community can form groups easily to collborate and build these kinds of experiences.

Let me give you an example. Imagine we want to create the *stream music to a remote set of speakers* experience that we discussed earlier. I think you could summarize this experience down (and many others) into requiring the following core skills:

* **Project Coordinator(s)** – people to form a team, find others to participate, put together a roadmap for the team, and help people to successfully create the experience.
* **Programmers** – people to write any code neccessary to deliver the functionality in the experience (not required if this functionality exists upstream).
* **Packagers** – people to integrate the different components in the experience together.
* **Testers** – people to test the experience, report bugs, and triage issues etc.

What I would like to open up for discussion here is how we can optimize our community to help people form these teams, have a great time collaborating together to create something, and deliver it in Ubuntu. What tools, facilities, support, and cheerleading can we provide to help make this happen?

That counts.

Off the top of my head I think these are some of the things that could help these teams form:

* An *ideas board* – we would need a place to post ideas for experiences (arguably [Brainstorm](https://brainstorm.ubuntu.com/) already does this, so we could potentially harness that) and help to inspire others in delivering those experiences.
* A *jobs board* – with a place to share ideas, we would need a means in which people can form teams around those experiences. How do provide a means to connect community members with an itch to contribute with projects that need their skills.
* A *project management facility* – I think we really have these tools already in place. We have Launchpad blueprints, the awesome [status.ubuntu.com](https://status.ubuntu.com) which Martin Pitt and Chris Johnson helped to build, and other facilities to run projects effectively.
* Mentoring and Support – I would love to see our leadership teams help to support and provide guidance for these teams in helping them to deliver their experiences.

In a nutshell, we should make it simple for a community member to have an idea for an experience, be able to find others who share a passion for creating the experience, and be able to harness the motivation and support of our community to be successful in creating the experience.

I would like to open this up in the comments for ideas and suggestions for how we could make this happen. How do you think we can provide a place to share these experience ideas and build teams around them? How do we help these teams to be successful? Would you be interested in helping to create these facilities?

I just want to say a huge thank-you to the [Ubuntu Weekly News](https://wiki.ubuntu.com/UbuntuWeeklyNewsletter) team for tirelessly bringing a weekly dose of fantastic Ubuntu news to our community. I know there is a lot of work involved, and while I have not had the time to contribute, I have been trying to contribute recently by spreading the word about the newsletters.

If you have a little time each week and would like to help to make the *Ubuntu Weekly News* even better, see [this page for how to participate](https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Join) and feel free to meet the team in the `#ubuntu-news` IRC channel on *freenode*.