As we build towards to the next [Ubuntu Developer Summit](https://uds.ubuntu.com/) in a few weeks, we have been getting our blueprints and plans in place to have a comprehensive set of discussions at the event. Unfortunately I won’t be there, fortunately due to an impending bundle of baby joy that will be entering my life, but I will be [remotely participating](https://uds.ubuntu.com/community/remote-participation/). Be sure to join us there, there is no excuse, people. 🙂

As part of these plans I have been having some wonderful discussions with *Ivo Weevers* who is the head of the Canonical design team and who reports directly to Mark Shuttleworth. Ivo is passionate about helping the design team at Canonical and the community to work closely together, and we have been discussing what problems we need to solve, and how to resolve them. In the past there have been concerns in the community that it is difficult for our community to actively participate in design and Ivo and I are keen to solve these challenges.

There are many topics to be discussed and we are currently fleshing out the schedule for UDS, but I am keen to solicit feedback about one particular piece of this puzzle.

Thankfully we are not trying to figure out the puzzle of opening one of these instruments of frustration.

As many of you will know, Ubuntu is a *meritocracy*; when people do great work, they have more influence over the project. As an example, our developers who work hard and become approved core-dev or MOTU contributors have more influence over our development operations than those who have not put in this level of development work. Now, before the haters start hatin’, I agree that Ubuntu is not a *perfect* meritocracy in that some Canonical staff members have direct influence over Ubuntu in a way that the community are unable to contribute. Examples of this include our infrastructure and systems teams, and to a degree this also includes the design team.

In a world in which everyone has a strong opinion about design, I believe that part of solving this challenge is that we need a means in which we can highlight the great designers from not-so-good designers. To be clear, this does not necessarily mean designers who agree with the Canonical design team, but instead designers who are collaborative, talented, contribute significant and sustained work, and bring their expertise forward to improve Ubuntu…the very same criteria we use to judge other areas of expertise in the project.

In the development world we have a pretty well defined way of assessing the cream of the development crop while still providing an opportunity for *everyone* to be able to ascend and aspire to that level of quality. We have methods of contributing that can build up a body of work that can then be reviewed and direct upload rights can be granted when the quality requirements are met. To do this we have the following:

1. A clear definition of things that prospective developers can do.
2. A simple means in which non-uploaders can contribute their work.
3. Criteria that we can use to assess the quality of this body of work (e.g. technical quality, effectively following our guidelines and principles, providing a *significant and sustained* body of work etc).

I was chatting to Ivo about this and we would like to define the same three equivalent attributes for the design part of Ubuntu. Namely, we need to be able to point to things that people can do, have a means of reviewing this work effectively, and importantly, define criteria of *what makes a great designer*. I would propose that we apply these assessments to create an equivalent to core-dev in the development team but for designers. This way everyone can contribute more widely, but we can have a team of reliable, effective, community contributors that works closely with the Canonical design team and a clear means in which anyone can learn how to gain the skills to join this team.

I wanted to open up this discussion to the community to get your feedback and then we can review the feedback and discuss it at UDS and then start formulating a plan for the 13.04 cycle. In putting forward your suggestions, please bear in mind that we need to make the solution light-weight for everyone involved, both new contributors and those who will be reviewing the work of others.

A few days ago [Stuart Langridge](https://www.kryogenix.org) and I upgraded a machine from 8.04 LTS to 10.04 LTS and then from 10.04 LTS to 12.04 LTS, all over SSH. Both upgrades ran without a hitch. We simply ran `do-release-upgrade` and everything worked great.

Upgrading from a four-year old installation to a current installation with no problem was impressive. For everyone who contributed to making the magic happen, thank-you!

Recently there has been some concerns in our community about the online dash search feature, and these concerns have been orientated around the privacy of your data, the legal requirements for how this data is handled, and the effectiveness of the search.

These concerns have been taken *very seriously* inside Canonical and there has been extensive work going on to ensure we can tend to any outstanding issues ready for the 12.10 release. It is important to remember that this is the nature of how we develop Ubuntu; we often add features that later require additional focus and work based upon feedback in the community. This is just the nature of collaborative community; our community helps us to refine and improve Ubuntu in many ways based on feedback. I want to offer a sincere *thank-you* to everyone who has provided constructive, frank feedback about what we need to do to improve this feature and bring it in-line with the needs and expectations of our users.

So far in this story there has been a series of concerns and actions in response to this feedback. This is summarized as:

* Concern about the usefulness of the feature – to resolve this a toggle switch has been added to the Privacy settings dialog to disable/enable the feature.
* Concern about the encryption of traffic – traffic is now encrypted.
* Concern about adult content being displayed via the lens – significant changes have been made to blacklist certain results based on keywords.
* Concern about the legal requirements of this feature under European law – a Legal Notice link has now been added to the dash to make the terms of use clear for using the dash.

In addition to this, *Cristian Parrino*, our *VP of Online Services* at Canonical, who is basically in charge of Ubuntu One, our affiliate schemes, and who is responsible for the affiliate portions of the dash (e.g. Amazon/Ubuntu One Music Store results) has provide some further responses to these concerns.

Cristian [published a blog entry](https://blog.canonical.com/2012/10/12/searching-in-the-dash-in-ubuntu-12-10-an-update/) – be sure to take a look.

Please feel free to ask any further questions in the comments. Thanks!

Over the last 24 hours the *Canonical Community Team* spent an entire 24-hour period together working, interviewing community members, planning further work, and fund-raising for our six charities; *Oxfam* (Daniel Holbach), *Greenpeace* (David Planella), *Little Kids Rock!* (Jorge Castro), *Autism Research Trust* (Michael Hall), *WaterAid* (Nicholas Skaggs), and *Homeless International* (Myself).

I am delighted to announce that at the end of this period we each raised the following for our charities:

* **£1055** – Daniel Holbach
* **£610.50** – David Planella
* **£898** – Jorge Castro
* **£709.13** – Michael Hall
* **£588.68** – Nicholas Skaggs
* **£1272.39** – Myself

…this totaling **£5133.70** for charity!

Thank-you to everyone who donated, many of whom donated to multiple horsemen; your generosity is hugely appreciated, not just by us, but also by the many people, families, and neighborhoods that will benefit from your contributions.

Throughout our 24 hours online we were joined by many people for interviews and discussions. Thanks to *Stuart Langridge, Gema Gomez, Daviey Walker, Carlos de-Avillez, Chuck Short, Joey-Elijah Sneddon, Laura Czajkowski, Alan Pope, Rick Spencer, Marco Ceppi, Clint Byrum, Ted Gould, Martin Pitt, Mark Shuttleworth*, and *Didier Roché*. Thanks also to everyone in the IRC channel and on Twitter who stayed up to support the marathon and watch the discussions, interviews, see us coordinate projects and UDS work, joke around with each other, and even cook and barbecue together. It was a blast!

Finally, of course, I want to thank *Daniel Holbach, Jorge Castro, David Planella, Nicholas Skaggs* and *Michael Hall* for agreeing to take a full 24 hours out of their life, away from their families, and outside of their comfortable beds to take part in this madness. Spending 24 hours with the same five other somewhat-sleep-deprived people could be a recipe for frustration, but I think I speak for everyone in that it was simply a pleasure to spend time together as a team and as friends. I feel blessed to work with such a talented, hard-working, and friendly team, and the last 24 hours was another reminder of why I feel so fortunate to have such a wonderful job and with such a rocking team.

And with that written up…I am going to bed. Night all!

As part of the [24-hour marathon](https://archivedblog.jonobacon.com/2012/10/04/here-comes-the-horsemen-marathon/) we are doing lots of interviews, as well as some fun sessions, Q+A sessions on more. Here is the first part of the schedule:

• 2.00pm UTC – Gema Gomez – Assuring Quality in Ubuntu – we interview Gema Gomez who is part of the Ubuntu QA Team about how we are growing quality in Ubuntu.
• 3.00pm UTC – Daviey Walker – Ubuntu Cloud in 12.10 and Beyond!
• 4.00pm UTC – App Developer Showdown – we will explain the plans set in store to provide the best App Developer experience to submit your apps to Ubuntu
• 5.00pm UTC – Carlos – community council and bugsquad
• 6.00pm UTC – [tentative] Chris Johnston – Getting involved with Summit development, learn how to get the code running locally, how to make contributions, and what the future plans are for the project.
• 7.00pm UTC – Chuck Short – Ubuntu and OpenStack – Chuck will be talking about some of the awesome work the Server team is doing to bring the latest from OpenStack into Ubuntu.
• 8.00pm UTC – Team Q+A – Ask us about Ubuntu! Bring your questions and ask anything you like to any of the horsemen!
• 9.00pm UTC – The Bacon BBQ Extravaganza – as part of some sessions about what the horsemen do for fun, join Jono Bacon as he starts his six hour smoking session of three racks of Baby Back Ribs. Come and find out how smoking works, check out the pit and the gadgets, and have a little fun!

We will have the schedule for the next part of the 24-hour marathon soon!

**Come and join the fun at [marathon.ubuntuonair.com/](https://marathon.ubuntuonair.com/)** – thanks!

Gangnam Style.

At **10am UTC / 11am UK / 12pm Europe / 3am Pacific / 6am Eastern** on **Thurs 4th Oct 2012** the *Canonical Community Team* will be working for a solid uninterrupted 24-hour session. The marathon will involve *Daniel Holbach, Jorge Castro, David Planella, Nicholas Skaggs, Michael Hall* and myself; six horsemen spread across three different countries hitting the Ubuntu pump hard for 24-hours…all in the interests of raising money for charity while improving and growing Ubuntu and Free Software.

The entire session will be streamed live on [marathon.ubuntuonair.com](https://marathon.ubuntuonair.com/) where you can watch the action and chat to the team as we work and do the marathon.

Importantly, we want to use this as an opportunity for the community to get involved in the marathon too! Let’s use this 24-hour period as a great opportunity to add the finishing touches to Ubuntu 12.10, work on different projects, improve our documentation and translations, and help share knowledge and experience.

Of course, at the core of why we are doing this work is to raise money for charity…let’s see how much money we can generate for the six good causes that we have picked! Please go and **[DONATE](https://marathon.ubuntuonair.com/)**!

So…at **10am UTC / 11am UK / 12pm Europe / 3am Pacific / 6am Eastern** on **Thurs 4th Oct 2012** be sure to head to [marathon.ubuntuonair.com](https://marathon.ubuntuonair.com/) and join the fun – also please tweet about the marathon with the `#ubuntumarathon` hashtag. Thanks!

*Apologies for such a long post, but I want to ensure you all have the necessary information about our focus in 13.04. Please feel free to ask any questions in the comments!*

As we edge towards our next release, I have been preparing my team, the *Canonical Community Team*, for the forthcoming 13.04 cycle and I want to share the process to give you folks an idea of how we decide what to work on. Please note that we are a community management team, so if your favorite feature, bug-fix, or pet peeve is not listed here, don’t be surprised, we are not a normal engineering team who builds features or fixes bugs inside Ubuntu.

The goal of this preparatory work is for me to gather input from our stakeholders, the community, and our team members to get a firm idea of the problems and opportunities that are in front of us. I then take this input into account as I assess what would be the best use of the team’s expertise and resources.

Our team’s mandate is pretty wide…the community is a big place…so it is always difficult to settle on the most critical areas of focus from a wealth of worthy candidates. My apologies that we simply don’t have the bandwidth to focus on more areas, but everyone on the team is always available to help our community leaders and contributors to be successful – if you don’t see your community problems and opportunities listed here, that doesn’t mean we are not here to provide help, guidance, and support – feel free to reach out to us!

You can catch us in `#ubuntu-community-team` on freenode IRC, and feel free to email us or simply leave your comments on this blog entry.

Please don’t reach out this way.

When I have finished gathering this input I then work with the team to map out in a spreadsheet each of their objectives, goals, success criteria, and an overview of the work required for these items. This spreadsheet provides a good overview of the body of work for each horseman, and then when I approve these objectives and goals I ask each team member to register [blueprints](https://launchpad.net/+tour/feature-tracking) for each goal.

These blueprints are public pages on Launchpad that serve a number of important purposes:

1. They form the backbone of the sessions we have to discuss these objectives and goals at UDS.
2. They provide a place in which we can track decisions and further work, right down to the *work item*.
3. They provide wonderful transparency and an easy way for anyone to see changes and updates to each one of our goals – you can *subscribe* to a blueprint and you get emails when they change (including changes to the status of work items).
4. They provide the input to [status.ubuntu.com](https://status.ubuntu.com) where we can get visibility on this work so I can help ensure everyone stays on top of things.

Today I finalized with my team these core objectives and goals and I want to now provide an overview of them. You should expect to see the team follow up on their own blogs with further details and topics for discussion as well as the specific blueprints for these goals that you can subscribe to.

I will also follow up after UDS with a full listing of *all* blueprints we are working on so you can see everything in one place. This blog entry is designed more to provide some background to this work.

Please note: even though we have an idea of the objectives and goals, the final solutions, outstanding questions, implementation details, and other content is not finalized; that is the purpose of the [Ubuntu Developer Summit](https://uds.ubuntu.com/)…to delve into the details and plan how we achieve those goals together as a community.

Let’s now take a look at these plans, divided up into topic areas.

## Quality Assurance

Over the years we have developed standards of practice of not only how we build Ubuntu but also how we strive to encourage the same philosophy in other projects. This has included our focus on *cadence* and *design*; both of these underpinnings in how we build Ubuntu have helped improve the final product, and it has been great to see other projects taking similar approaches.

In the last few years we have made *quality* a core part of these standards of practice, and matched them with neccessary investment from Canonical. This includes the growth of our QA team and I hired [Nicholas Skaggs](https://www.theorangenotebook.com/) on my team who has been doing a fantastic job growing and building our community of testers and quality engineers.

These additional resources have been focusing on growing our automated testing infrastructure, increasing our manual test coverage, and improving our visibility on defects which will ultimately result in resolving those issues and preventing regression. Many of you will have felt the results of this quality investment in 12.04, and the train is rolling on with 12.10 and through to 13.04.

Quality is a difficult thing to show as a picture, so heck, here’s a duck.

Over the last few weeks Nick and I have been talking a lot about two core goals in 13.04:

1. Growing our community of testers.
2. Improving our visibility and predictability so we apply our QA resources and community smarter.

There is important yet subtle distinction in this work. Our goals are to *assure* quality, not just to ensure things get tested. We want to ensure that the right things get the appropriate level of testing so as to assure they work correctly in Ubuntu.

In Ubuntu we typically have two core types of testing going on…*automatic* and *manual* testing. The QA team led by *Pete Graner* have been building out our automated testing facilities and the goal here is to ensure that everything that *can be* tested *is* tested in an automated fashion. For those areas that cannot be tested with an automated test, we lean on Nick to rally our community to help with manual testing of those areas.

### Automated Testing

The QA team have been working extensively on our automated testing facilities. The goal here is simple: for us to provide a comprehensive set of automated tests that are regularly run and provide visibility on regressions and other issues. These automated tests provide an effective means of raising red flags that our developers need to focus on fixing.

Having an automated testing infrastructure is one thing, but it is *nothing without the tests*. With the QA team getting the infrastructure up and running, I have asked *Daniel Holbach* and *Nicholas Skaggs* to **work with our community to encourage and grow our test coverage**. The contribution of automated tests is a wonderful way of assuring the quality of Ubuntu and providing more visibility on where problems may exist so we can fix them, thus producing a better quality Ubuntu.

This work will first involve ensuring that the neccessary documentation is in place, that our community knows which tests are required, and that there is a simple means of contributing tests. We will then have an extensive outreach campaign to encourage our community to participate and write tests; expect outreach about this at UDS and in future community events.

### Manual Testing

When something can’t be tested automatically we rely on human-run manual testing. Currently we have two types of testing:

1. In 12.10 we moved to a twice monthly regular cadence testing (primarily testing the installation experience) – this happens without fault every two weeks with the goal that *all tests are run*.
2. We often have a series of *reactive* test plans to test things such as a new Unity release or problem spots in the distribution.

The challenge with the latter reactive tests is that they sometimes resulted in a bit of a scramble to get things in place. What can sometimes occur is that a new component lands in Ubuntu that either (a) includes significant changes or (b) has problems and Nick works quickly to get out a test plan.

As such in 13.04 I have asked Nick to **provide a more predictable manual testing methodology and to provide greater visibility on the state of QA in the distribution**. Nick is going to work on a *weather report* visualization of where quality issues exist in different parts of the platform. On one hand this will be a data-driven view and on the other this will involve some human input.

The goal here is to provide a simple means in which our community can identify problem spots and then we can tie together greater automated and manual testing based on these needs. This quality report will be augmented with **community growth campaigns to get more people interested and participating in QA**. Nick will also continue to run the cadence testing every two weeks.

It is rumored that the reason for the two week cadence is that it lines up with the next Seinfeld marathon. This cannot be confirmed nor denied.

The culmination of this QA work will result in a **growth of automated tests** and a community who produces these tests as well as **better visibility on where there are quality issues in Ubuntu** so we can apply appropriate automated and manual testing and community growth to relieve those issues.

## Juju

[Juju](https://juju.ubuntu.com/) has seen some wonderful growth in the last year. With Ubuntu’s popularity in the cloud, the Devop crowd have been getting increasingly interested in Juju and the team has been continuing to grow and extend Juju to support the needs of our users.

On my team *Jorge Castro* is there to grow the Juju community. When we started this work the goal was simply to grow the number of charms and active charm contributors. This work involved Jorge flying out and running charm schools, organizing charming competitions, and we spent a lot of time getting the documentation, community governance, review processes and other necessary pieces in place.

Earlier in this cycle we changed gears to really focus on *quality* applied to a target set of charms. A big chunk of this work involved the creation of the [Charm Quality Rating](https://juju.ubuntu.com/docs/charm-quality.html) scale that provides a means in which we can determine what an *awesome high quality charm* looks like. We then applied it to the set of charm targets. Jorge and members of Antonio’s team have been reaching out to upstreams to work together in improving the quality of their software when deployed with Juju.

In 13.04 Jorge will **continue to focus his efforts on this quality initiative and working with upstreams around this work**. Jorge will also **re-focus back on the wider net of charm and community growth** to keep our community growth consistent while we focus on quality.

With every new community I always mentally segment the new community member interface into what I call the *on-ramp*. It looks like this:

Not meant for skateboarding.

This effectively covers the challenges that new community members face when they join a community. First they need to know that they can participate in the first place, second they need to know the skills to participate, thirdly they need to know what to work on, and then finally they need to feel great about their contributions and get the recognition they deserve. This is all part and parcel of how we build a strong sense of *belonging* in communities which increases the stickyness of contributors who want to stick around and participate in the project.

Over the last year Jorge and others have put together these various pieces of the on-ramp as required, but I have asked Jorge to do a **full on-ramp review** to ensure we have each of these parts *nailed*. This is going to involve a blueprint for each part of the on-ramp, a full review of each area, user-testing our resources and community-faces interfaces, and identifying and resolving any deficiencies reported. This will result in a more efficient, more pleasant, and more productive community experience.

## App Developers

In recent months my team have been focusing on improving the app developer experience on Ubuntu, and ensuring that we present a simple, powerful, and flexible platform in which developers can build rich, feature-full apps that integrate neatly into the platform and benefit from the flexibility of Ubuntu. *David Planella* and *Michael Hall* have been doing wonderful work in this area.

To fulfill the needs of app developers we have a few challenges to overcome. I see the app developer experience involving the following pieces in the pipeline:

1. Providing the tools, resources, and skills-acquisition to write apps.
2. Promoting the benefits and opportunities of Ubuntu as a platform for app developers.
3. Providing a simple and effective means of delivering applications to Ubuntu users.

For the first bullet, we are going to continue to make **`developer.ubuntu.com` improvements** to ensure that new developers have all the information they need. We have already scoped out some improvements to [developer.ubuntu.com](https://developer.ubuntu.com) that will provide these important resources for our app developer community. This will include:

* Integrated API documentation for our various APIs.
* A code snippets library that will make it easier to find what you need and get started.
* A video tutorial section.
* [Ask Ubuntu](https://askubuntu.com/) integration.
* An outreach campaign to increase the number of recipes we have on the site.

Our goal is that `developer.ubuntu.com` continues to be a hub of information and support for Ubuntu app developers.

For the second area we are going to continue our **app developer community growth**. Here I have asked *David Planella* and *Michael Hall* to continue to grow the number of app developers who are interested in building apps for Ubuntu and ensure they have the skills and opportunity to deliver fantastic apps to our users. In the last cycle we ran the [Ubuntu App Developer Showdown](https://developer.ubuntu.com/showdown/) and we want to run similar kinds of initiatives. This will include regular Google+ hangouts, an app developer education week, weekly guest hangouts and more.

For the final area, as I [blogged about before](https://archivedblog.jonobacon.com/2012/09/06/opening-ubuntu-up-to-the-world/), we need to improve the ease and pipeline of how developers can get their applications into Ubuntu. Over the last few months we have been working on a [spec](https://wiki.ubuntu.com/AppDevUploadProcess) to solve this challenge. This is a foundational piece of work that will help to significantly ease *publishing* apps to the Ubuntu Software Center. The spec involves many different pieces of work from many teams. The *Security* and *Foundations* teams have already committed to much of this work in the 13.04 cycle, but there will be lots of general coordination of these pieces that we will need to work on. This spec will certainly not be completed in 13.04, but much of the foundational pieces will be worked on.

The new app upload process.

## Developers

Our developer community has always been important to us, and in 13.04 we will continue to focus on and grow interest and participation in Ubuntu development. As usual, *Daniel Holbach* will be coordinating this work, and we have identified some important areas of focus.

First and foremost, 13.04 is going to be all about *growth*. In 12.10 the *Developer Advisory Team* was put into place and there were significant improvements to our packaging guide, and in 13.04 the focus is going to be on **supporting our active contributors in getting through the developer process** and becoming active developers.

This work will not just focus on *Core Developers* but also *MOTU*. Our *MOTU* community is incredibly important to Ubuntu and the work they do in maintaining the comprehensive set of packages in Universe is hugely valuable to our users. Daniel will be be *priming the pump* for every Developer Membership Board meeting and helping to ensure potential candidates have their necessary documentation in place and the DMB are notified of their application.

If you are actively participating in Ubuntu development today and submitting your contributions to the sponsorship queue, get to know this guy, he can help you with anything you need:

if you whisper [email protected] three times magic happens

As part of this developer growth work Daniel is also going to run a **bug fixing initiative** in 13.04 to increase the visibility on bugs for our community contributors so our new developers can feel like their work is fixing the right parts of Ubuntu and feel great about those contributions (also fitting in with our *quality* goals). Daniel will also be working on **a series of educational videos for how to participate as a developer** and be performing a lot of **active developer growth outreach** via Google+ hangouts, *Ubuntu Developer Week* and more.

## Ubuntu Accomplishments

As some of you will have seen, a number of us have been hacking on the [Ubuntu Accomplishments](https://wiki.ubuntu.com/Accomplishments) project in our spare time. The project has made significant progress and is pretty much at a point that is ready for community-wide deployment. This involves moving the validation server over to a Canonical hosted machine, deploying the web interface (which will eventually be `trophies.ubuntu.com`), and getting it packaged and into the *Ubuntu Software Center*.

This work will result in a system that provides context sensitive documentation for how to participate, improves social community connection points (via the web interface), and provides a great method of acknowledging contributions. In a nutshell, Ubuntu Accomplishments makes participation *discoverable* and *acknowledged*. I am excited to see the community utilizing the system and continuing to grow support for different types of accomplishment.

I have asked *Michael Hall* to work with the Canonical IS team to **get Ubuntu Accomplishments deployed** and to ensure the system is **packaged and available in the *Ubuntu Software Center* ready for the 13.04 release**.

## Other Topics

The topics covered above are really just the core areas of focus in the cycle, and a typical cycle for our team involves hundreds of other responsibilities and different pieces of work from *LoCo Teams* to *Documentation* to *Translations* to *UDS*, *improving communications* and more. When UDS is completed and I provide the update with the full list of blueprints I will expand on these additional topics too.

If you got to this point, thanks for reading…I know this was a long post. Please do let me know if you have any other questions or queries. Thanks!