*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!
