As many of you will know, there is a lot of work going on to get the core Ubuntu Desktop running on the Nexus 7 tablet.

Thus far we have focused on the 8GB and 16GB tablets, but now the 32GB Nexus 7 can be used too. This tablet is available for around $299 if you don’t have one.

We want to encourage as many of you to test Ubuntu on the Nexus 7, report bugs, and get involved in making Ubuntu rock on it. To get involved, simply follow the installation instructions (don’t worry, you can roll back to Android if you need to) and be sure to ask for help if needed.

If you find bugs, be sure to report them with ubuntu-bug, here’s how.

Thanks for helping!

With so much going on at UDS it can be difficult to get a crisp summary of the key decisions, plans, and goals for the next release. Even if you are attending in person, you only get to see a small sliver of everything that is going on, so a broad set of summaries is useful for those both at UDS and those who could not attend.

I have created this wiki page where we can document these summaries, decisions, and conclusions. Please go and contribute to this page – if we can divide and conquer in getting most of the content landed this week we can then tidy it up next week and release it.

Thanks!

It has been interesting listening into the UDS sessions remotely (find out how to join remotely here) this week. While I wish I could join more sessions (unfortunately the timezone difference is pretty brutal) there have been a number of key topics and themes discussed this week, of which a few in particular have caught my attention in the Community track.

Two topics in particular appear to be LoCo Teams and Communication. In a nutshell some of the feedback from UDS is that our LoCo Teams provide tremendously valuable advocacy for the Ubuntu project and but we could do with helping and harnessing these teams more. In terms of communication there is a desire for better communication regarding how announcements are made and how widely news is disseminated across the project. There was also feedback about improving community involvement in Canonical projects but I will dedicate another blog entry to that.

I am in full agreement with both of these points of feedback, and I agree these are valuable areas for us to focus on in 13.04 and I am going to commit my team to help drive improvements in both of these areas.

Next week when UDS is finished I will be spending a few days syncing up with my team to get more details about the discussions that I could not be part of due to the timezone, and then I am keen for us to put together a plan with our community. These plans will naturally take into account the discussions and suggestions put forth at UDS and we will coordinate with many of the participants in the sessions around the plans for 13.04.

I would also like to put together a small community team that my team can have a regular call with to check in and ensure this work is on track, make any adjustments and improvements as we execute it, and be able to bounce ideas and discussion points off. We may break this into two teams: one to coordinate around the LoCo work, and one to coordinate around the communications work.

I do have a few thoughts about these two areas I wanted to share below as points for further discussion. If you are at UDS please do discuss these topics there and feel free to share your thoughts in the comments below.

LoCo Teams

The Myanmar Loco Team.

There is no doubt that our LoCo Teams are a tremendous part of our community. There is also no doubt that we can help Loco Teams more to help and support their teams in being successful.

From the perspective of the Canonical Community Team I feel a bit guilty about this. In previous cycles we have spent more time on LoCo Teams, but the last few cycles we have not had as much time to devote to helping teams be successful (the last few cycles have been hectic to say the least). As some of you will know, I used to have weekly calls with some LoCo Leaders and I want to get that back on track in 13.04.

In my mind there are three strands of LoCo Team work that we can focus on in 13.04:

• Leadership – as with previous cycles I think there is a great opportunity to continue to support, inspire, and motivate great leadership in our LoCo Teams. There is no doubt that a team with a great leader (if not a formal leader, someone who inspires work and contributions and coordinates projects) typically ends up being a happier and more motivated team. As such, for us to increase the number of happy, motivated teams, helping our LoCo Teams to develop great inspirational leaders is a great area to focus our efforts.
• Participation – one area in which I think we have done a pretty poor job in recent cycles in involving our LoCo Teams in activities surrounding the next release. As an example, on my team Nick Skaggs is going to be growing the number of manual testers, Daniel Holbach will be working with Nick to grow the number of Automated testers, and Michael is going to be growing the number of people participating in the skunkworks project. These are great areas in which we can reach out to our LoCo Teams for active participation, to share skills, and take part in wider campaigns. All to often we have focused on the specific communities in that work (e.g. the testing community in the QA work) and we should widen this to involve our wider LoCo Team community. As an example, I can see Nick reaching out to and support LoCo Teams to participate his his regular cadence testiing every two weeks.
• Sharing Stories – when a community reads awesome stories of LoCo Teams doing great work, it inspires and encourages great work too. A few cycles back we implemented changes to loco.ubuntu.com to highlight many of these stories and I think it would be wonderful for us to continue this work and make the site a hub of exciting storytelling and discussion. I would like to get this back on track.

Do you think these are valuable areas of focus? What other areas do you think we can help make LoCo Teams be more successful?

Communication

Communication is definitely an area in which we can drive some improvements. Within the context of the discussions at UDS, it seems the primary concern here is to improve (a) how new features, policies and information is communicated to the wider community and (b) improve how that information is disseminated so as many people as possible see it and people don’t miss it because they didn’t read a particular mailing list, blog, Twitter feed or otherwise.

In terms of (a) you can break these announcements down into (1) announcements from the community (e.g. governance voting, CoC changes etc) and (2) announcements from Canonical (e.g. new features that might be landing, changes in policies etc).

For (2) this is something I am passionate about improving in the 13.04 cycle. I have already reached out to Mark Shuttleworth and the Product Strategy / Online Services leads about improving how these big new features and changes are messaged outwards. As part of these improvements I am maintaining an internal spreadsheet with when these features and policy changes are going to be ready. This will give my team more time to prepare for this work, help us to provide other community teams with a heads up (e.g. the Community Council and the News Team), be able to plan resources and documentation, and be able to plan the discussions and feedback loop better. I am confident that this will improve significantly in the 13.04 cycle. Mark and the Product Strategy/Online Services leads are all on board to participate in this work.

For (b) we started getting into this discussion in the community roundtable yesterday and I think that this deserves a longer discussion. Ideally we want to find a way in which we can utilize existing communication channels but be more efficient in how we message out to our wider community. As an example, the Fridge serves a useful purpose as a community orientated blog, but we need to ensure that the information and announcements get posted there more often (something that we can improve in my team). We also have other potential resources such as mailing lists and Twitter/Google+ feeds and we need to find the best way of merging these different resources together into a more scalable strategy for how we message outwards.

I am keen to hear of any further discussions on this topic at UDS and for us to continue the discussion next week and put in a place a plan. Comments and feedback are welcome!

This week the Ubuntu Developer Summit is taking place in Copenhagen from Monday – Thursday. This is the event where we plan the features and goals for the next release of Ubuntu, Ubuntu 13.04 Raring Ringtail.

Unfortunately I won’t be there in person this week in person as my wife, Erica, and I are expecting a stork to fly into our house and deliver a baby (at least that’s how I understand how it works), so I am at home in California on stork duty. I am not going to deny that although being here is absolutely the right thing to do, I am pretty bummed that I can’t be there in Copenhagen with our community.

Some of you may not be able to attend in person too, but fortunately you can still participate in every session at UDS by joining in remotely.

How do I Remotely Participate?

You can find all the details of how to remotely participate right here, but in a nutshell you can view the schedule here (obviously all times are in local European time) to see the list of sessions and which rooms they are in and then hear the session audio feed from the appropriate room. You can communicate with the room by connecting to the Freenode IRC network and then joining one of the following rooms that corrospond to the session you are in:

• #ubuntu-uds-b3-m1
• #ubuntu-uds-b3-m10
• #ubuntu-uds-b3-m2
• #ubuntu-uds-b3-m3
• #ubuntu-uds-b3-m4
• #ubuntu-uds-b3-m5
• #ubuntu-uds-b3-m6
• #ubuntu-uds-b3-m7
• #ubuntu-uds-b3-m8
• #ubuntu-uds-b4-m5
• #ubuntu-uds-b4-m6
• #ubuntu-uds-b4-m7

If you connect to a room and can’t hear people loudly enough, don’t hesitate in asking the room to speak up or certain speakers to sit closer to the microphone.

How do I Watch the Plenaries?

Every day there are a series of plenaries; these are short presentations that are presented to the full UDS audience. Apart from the keynote plenary on Monday at 9pm, the main plenaries take place every day at 2pm and then a final set of track summaries is presented in the last hour of UDS on Thursday at 5pm.

You can watch the plenaries every day by viewing the live video feed.

This is the schedule of plenaries:

Monday

• 9.00am – Jono Bacon – Introduction to UDS

• 9.10am – Mark Shuttleworth – Keynote

• 2.00pm – Ivo Weevers – Design and Community

• 2.15pm – Drew Bliss – Valve
• 2.30pm – David Planella – Ubuntu and App Developers
• 2.45pm – Nick Skaggs – Growing The Ubuntu QA Community

Tuesday

• 2.00pm – Chris Kenyon – VP of Sales and Business Development
• 2.30pm – HP

Wednesday

• 2.00pm – Flavors Roundtable
• 2.30pm – Evan Dandrea and Matthew Paul Thomas – Reliability and Ubuntu

Thursday

• 2.00pm – Lightning talks (an hour of short, topical talks covering a range of areas).
• 5.00pm – Track Summaries – each of the track leads will summarize the key decisions and findings from their tracks. This provides a great summary of the topics discussed at UDS throughout the week.

I hope you all have a wonderful and productive week at UDS, and I hope many of you can join in remotely too!

A core goal for Ubuntu 13.04 is to get Ubuntu running on a Nexus 7 tablet. To be clear, this is not going to be a tablet Unity interface running on the 8/16GB Nexus 7, but instead will focus on getting the current Ubuntu Desktop running on the Nexus so that we can ensure pieces such as the kernel, power management and other related areas are working effectively on a tablet device.

Topics such as battery life, memory footprint, and support for sensors are all areas in which needs and expectations vary widely between a PC and a mobile devices. The 13.04 cycle will very much be focused on this exploration and learning and this is why we want to focus our efforts on getting the existing Ubuntu Desktop running on the Nexus 7. This will mean that some user-facing parts of the experience won’t make a lot of sense on the tablet, but we want to get the foundations optimized before we focus on these higher level challenges.

Naturally we want our community to be involved throughout this exploration and I want to talk more about how you can get involved both as a tester and as a developer.

As a Tester

To help with testing you will need an 8/16GB Nexus 7 tablet and be willing to replace the Android Operating System with Ubuntu (as such, please be sure to back up any valuable data on your tablet).

You can follow instructions of how to install Ubuntu on your device by reading the instructions at https://wiki.ubuntu.com/Nexus7.

If you have any questions about the installation and setup, please post on Ask Ubuntu; we will use the mobile tag to track these questions. The Mobile development team will be regularly monitoring the questions, and we would like you folks to help answer the list of questions too if you have the answers.

When you find bugs, please use ubuntu-bug to file the bug (more details about using ubuntu-bug can be found here). Please also tag the bug with mobile so we can find them more easily.

You can also get in touch with our wider testing community in #ubuntu-testing on the Freenode IRC network.

As a Developer

If you are interested in contributing to making Ubuntu work flawlessly and optimizing the Ubuntu Desktop core for the Nexus 7, we would love to have you participate in this work.

You can find details of many of the areas that we would like to focus on over at Victor’s blog; this provides some great food for thought for performance and functionality goals.

Much of this work will be discussed at the upcoming Ubuntu Developer Summit taking place in Copenhagen from 29th Oct – 1st Nov 2012.

If you are unable to participate in person you can join the sessions remotely. For instructions of how to participate remote, see this page for instructions. You are also encouraged to join #ubuntu-arm on Freenode to discuss this work.

The following sessions are scheduled. Please note times may change, so be sure to click the link below to ensure the date/time is up to date. You can also find the appropriate blueprints linked from the links below too:

Monday – 29th Oct 2012

• 10:00 – 10:45 in B3 – M8 : Setting your Ubuntu Mobile Dev environment
• 11:00 – 11:55 in B3 – M9 : How do I know my code is not consuming too much power?
• 12:00 – 13:00 in B3 – M8 : How do you debug your environment in a target?
• 15:00 – 16:00 in B3 – M4 : Boot & Resume time measurement and improvements for ARM devices
• 16:15 – 17:00 in B3 – M8 : How do I know my code is not consuming too much memory?
• 17:05 – 18:00 in B3 – M6 : Reduce footprint on arm devices

Tuesday – 30th Oct

• 09:00 – 09:55 in B3 – M6 : Trying to reduce session footprint for better battery life and RAM usage
• 09:00 – 09:55 in B3 – M5 : Improve the cross-compilation story in Ubuntu
• 17:05 – 18:00 in B3 – M5 : Discussion of methods for measuring and testing power consumption in arm devices

Wednesday – 31st Oct

• 10:00 – 10:45 in B3 – M9 : How do I write a test and get the test into the test suite?
• 11:00 – 11:55 in B3 – M9 : What does it take to run Ubuntu Desktop on mobile devices?
• 11:00 – 11:55 in B3 – M5 : Startup Disk Creator support for flashing fastboot images
• 12:00 – 13:00 in B3 – M9 : How do I report a bug for the Mobile OS, what is the process?

Thursday – 1st Nov

• 10:00 – 10:45 in B3 – M5 : Support generating Android ROMs on cdimage.u.c
• 16:15 – 17:00 in B3 – M8 : Compiling Ubuntu binaries for mobile

Thanks for reading!

Regarding Mark’s post about participating in private projects, I just wanted to weigh in on a few things.

First, let’s take a look at how Ubuntu is developed today.

Like other Linux distributions, we take a range of upstream components and assemble them together into an integrated system. Throughout this integration work our community actively participates in a range of different areas – development, testing, bug-fixing, translations, documentation, and more.

Now, over the years Canonical has invested extensively in building components to help grow and improve the Ubuntu experience. Examples of this include Unity, Juju, Launchpad, Bazaar, Ubuntu One, and various other projects. The majority of these projects are fully open and anyone can participate in them.

In some of these projects Canonical prefer to keep some new features secret until they are released. Now, I know some of you have a fundamental ethical objection to this, and a subset of those folks deem this so reprehensible that it warrants an abandonment of Ubuntu.

Just don’t abandon Ubuntu gangnam style.

As part of my job, I have had consistent feedback from a small number of unhappy people about these private projects, and I have communicated these concerns to Canonical as appropriate. Now, like many of you, I always like to opt for an open by default approach to Free Software, but in some cases there is reasonable justification for keeping things secret until they are ready. Examples of such reasons can include keeping the development and design focused to get a first version together, having a big splash with the feature (and thus waiting for the splash), or if the feature is being created for a partner product and then later added to the main platform if appropriate.

Now, I can hear some of you balking at these reasons, and you have every right to disagree. I have personally always seen it this way though: when sometime decides to create Free Software either as an individual or as a company, they have the right to create the first iteration of that feature however they choose. Their investment of time, money, or both in building Free Software earns them a right to put together a first cut that meets their needs…this is the very nature of scratching an itch.

Taking the analogy too far…choose your own tree, or bear.

Contributing Earns Decisions

Let me give you an example. Some time ago I built the first cut of Ubuntu Accomplishments. I spent a few weeks hacking like mad getting the vision into a runnable form that I could then share with others. Now, as soon as I mentioned it publicly, some people were very complimentary of the work, and some decided to question every decision I made. Why did you use Ubuntu One as the back-end? Why are you not supporting Mozilla Open Badges? Why are you using GTK3 for the client? Why don’t accomplishments allow you to do XYZ?

The way I saw it was pretty simple. I took a few weeks out of my life to build Free Software that I would share with others, and as far as I was concerned, I had earned the right to make my own decisions about the project and how it would be constructed.

Importantly, this right does not extend to the full history of the project; the social expectations change when you release a project and want people to participate. Continuing my Ubuntu Accomplishments example, as soon as I had released my first cut and was asking people to participate, I could no longer just make unilateral decisions as I could when it was just me; for me to attract others to my project I needed to be collaborative.

Collaboration…gangnam style.

Shortly after I announced the project, Rafal Cieslak joined and started contributing code. Rafal and I had a series of discussions about the core system, discussing every decision I had made previously. I considered Rafal’s feedback on this strategic focus of the project as an equal to my own; Rafal deserved the right to have a say because he too had now taken time away from his family and friends to contribute to this Free Software project.

For new Free Software feature development, Canonical (or Red Hat, or Collabora, or Xamarin etc) has every right to keep things private to get the project in shape if they wish to. If the company is investing in hiring people to write a new piece of Free Software, they have earned the right to decide on that first cut. When the company then releases the project and if they want to have the community participate, the company then has a responsibility to be collaborative in their work with these active contributors.

Ubuntu Will Always Be Open

Getting back to Mark’s post, Ubuntu is not becoming less open; you can still participate in pretty much every part of Ubuntu if you choose to. The point of his post is that there are indeed some projects (some, certainly not all) in which Canonical is creating new features in which these projects are private, and we want to open up and include community participation in those projects. This is a step towards increased community participation, not less.

Now, again, I know some of you will be boiling in your boots about the fact that these projects are not open from the beginning. You are welcome to slam me in the comments if you choose to, but I don’t make the decisions on keeping those projects private, so you might as well save your fingers.

What I am going to be responsible for is helping to get these private projects in a position where community folks can participate, where participating is fun and enjoyable, and and helping to get the right community people connected to the right projects. As Mark mentioned in his post, Michael Hall (who is mhall119 on IRC) is going to be the point-man if you want to take part in these projects, and Michael sits on my team. We have already fleshed out an on-ramp for how community members can express interest in this and we will be following up more this week about how to get involved.

Thanks for reading!

After a busy six month release cycle, we can all step back and look at the result of our efforts with Ubuntu 12.10. Many people from all around the world, from all walks of life, each bringing their own passion and talent, all contributed to this release. Thank-you for your wonderful contributions; if it wasn’t for our wonderful community, Ubuntu would not be what it is today, both in terms of technology and awareness.

Now we have the release out the door, in the coming weeks you will be hearing more from the community team about our focus and goals for 13.04; you can read a summary I posted a little back, but we will be following up with plans for UDS and our efforts to continue to grow our community, evolve and grow Ubuntu, and make Ubuntu a fun place to spend your time and contribute.

In the meantime though, everyone enjoy the release, and take the time to celebrate in whatever way you enjoy. Thanks, everyone!

As we build towards to the next Ubuntu Developer Summit 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. 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 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 – be sure to take a look.

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

Just a quick note for our wonderful worldwide collection of LoCo Teams…you can find out how to order your Ubuntu 12.10 DVDs right here. We look forward to hearing about the wonderful work you are doing to share the DVDs with people. Rock on.

I just want to let you folks know about a new addition to ubuntu.com.

For a long time now, many of our users have wanted to financially contribute to the Ubuntu project. For some of our users who don’t have the time to contribute in other areas (such as development, documentation, translations etc), this provides a nice means of supporting the project.

Although these contributions to Ubuntu were possible, the details of how to do so was pretty much buried in a growing ubuntu.com and many folks missed the link. In addition to this, the granularity of how you could contribute was limited; you could contribute an amount of money to the project, but there wasn’t really a way to indicate how you wished that money to be used (such as using it for growing Debian/upstream relations, for desktop improvements, or other areas).

Inspired by the wonderful folks at the Humble Indie Bundle, we now have a contributions page that provides a clearer means in which you can not only contribute but also where you want the money to be used. It looks like this:

Now helping to financially support Ubuntu is easier than ever.

The way the page works is that you can use the sliders to select how much you contribute to the following areas:

• Make the desktop more amazing
• Performance optimisation for games and apps
• Improve hardware support on more PCs
• Phone and tablet versions of Ubuntu
• Community participation in Ubuntu development
• Better coordination with Debian and upstreams
• Better support for flavours like Kubuntu, Xubuntu, Lubuntu
• Tip to Canonical – they help make it happen

Currently the page only accepts PayPal, but other payment mechanisms are currently being explored as we speak. The page appears on the site before you download an ISO (thus making it easier to find) and it provides the opportunity to contribute. For those who don’t wish to contribute in this way you can simply click the Not now, take me to the download › to bypass the page. Obviously our users are not required contribute. You can download Ubuntu here and see the page in action.

When a contribution occurs, Canonical will act as a steward for the money and ensure it is managed fairly and in accordance of the user’s wishes…ensuring it goes to the part of the project outlined in the form. Importantly, Canonical will not be using the money for any Canonical business-orientated functions; all of the contributions will be used to fund the Ubuntu project and continue it’s growth and development.

Some of you may have preferred there to be a finer-grained set of places to contribute, but in the interests of efficiency, the above areas were chosen to ensure that it covers the major areas that our users will be interested in financially supporting.

Naturally I would like to encourage you all to contribute. Over the years Ubuntu has grown to serve more people around the world than ever before with a powerful Free Software Operating System. For us to continue to grow, improve, and evolve Ubuntu we need to ensure we have the resources available to do this work. On one hand Canonical contributes extensively to this work, and this contributions page provides an opportunity in which you can contribute too. Your money will help go towards improving the areas of Ubuntu that you are passionate about, and help us to continue to bring a simple, efficient, safe, and elegant Free Software platform to the world. Thanks!

If you folks have any questions, feel free to post them in the comments.

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 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/ – 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 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!

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 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 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 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…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 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 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 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 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 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 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, 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 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 daniel.holbach@ubuntu.com 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 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!

…I am willing to do stupid things in exchange for money while fund-raising for my charity at our 24 hour Ubuntu marathon on Thursday. We have raised £1515.95 but we need more!

DONATE HERE and suggestions welcome in the comments!

It has been a little while since I last talked about Ubuntu Accomplishments, but there has been ferocious work going on in the project. The new release includes a number of important features and refinements.

The goal of the 0.3 has been to focus on quality. Our intention here was to raise the reliability and quality of the core system and provide another good solid iteration towards a 1.0 release. As such many of the features in this release are not particularly visible, but you can really feel the improvement in quality.

Let’s first take a look at the end-user improvements. Firstly, we improved the My Trophies view to include filtering to show you the different collections as well as which trophies you got most recently:

A core philosophy with the project is to keep our interface clean and uncluttered.

These new filters make it much easier to navigate your trophies when you have a large collection. It also makes the client feel more dynamic when displaying trophies in chronological order (this is grouped by ‘Today’, ‘This Week’, ‘This Month’, ‘Last Six Months’ etc).

Thanks to s-fox we now have Social Media integration build into the client. When browsing your trophies you can click one then click the Share button to easily share it across your social networks. This integrates neatly with Gwibber so it uses your online accounts settings.

A large chunk of the 0.3 cycle was spent by the awesome web team building a web front-end for displaying and browsing accomplishments. Thanks to Janos Gyerik and Gabriel E. Patiño for their extensive work on this code-base.

An in-development shot of the web gallery.

This web gallery will eventually be visible at trophies.ubuntu.com. The code lets you browse different opportunities, view the documentation, and then also show your trophies to others. We integrated support for the web gallery into the desktop app to switch on support for this with a single click (you have to opt-in to share your trophies online).

We have all kinds of interesting plans for building in social functions into the web interface to help make our community feel better connected in terms of what people work on and how people can find help in participating. I am really looking forward to seeing this deployed in a production environment in the next few months.

In addition to this work we also added a number of new accomplishments to continue extending the system to cover as much of the community as possible.

Quality

A big chunk of the work in this release however was much less visible with the goal of assuring quality.

Thanks to Matt Fischer we now have a comprehensive suite of unit tests. We are now regularly running these tests and running them against new contributions to assure the quality of our code-base and not regress.

We also did a full review of our API, and we tidied up our code-base significantly. Creating effective APIs is hard and intensive work, and thanks to Rafal Cieslak for his excellent efforts in driving much of our API clean-up. We have a far more mature API now.

As part of this work in assuring quality I spent some more time hacking on a tool I wrote to check the quality of our accomplishments (the tool is accomplishments-battery). I pretty much re-wrote it for 0.3, added different output formats, included checking for accomplishment schema completeness, and made it more modular. We use this tool to run a full daily check of all accomplishments to ensure they work correctly.

A test run on the Ubuntu Member accomplishments.

We as a team also spent a lot of time generating API documentation both for contributors and for accomplishments writers. We want to provide two types of documentation: docs for people consuming the technology to write clients and accomplishments as well as docs for people who want to hack on the core accomplishments system. This is still on-going work, but we are in much better shape than we were.

Part of our documentation designed for client authors.

We also vastly improved our documentation for how people contribute to the project.

Trying The Release

To get started using the release, please see our installation instructions. You will need to be using Ubuntu 12.04 or later to use the 0.3 release. Fortunately, the most recent versions of our flavors (e.g. Xubuntu) can now also run Ubuntu Accomplishments too!

If you have any questions, feel free to post them using our Ask Ubuntu tag, or ask in our support channels (more on this below).

Next Steps

Our next step is to get the system production ready. I have tasked Michael Hall on my team to take this pretty mature code-base and deploy it in a production environment and work with the Canonical IS around these logistics (the IS team has already approved this work). Michael will be working on getting the system up and running over the coming weeks. This will include both the validation server and the web gallery.

While this work is going on we hope to have a preview version of trophies.ubuntu.com ready to go. We already have the integration with the desktop application in the code-base (just not exposed in the user interface). We will then continue to refine our core system, grow our library of accomplishments and start rolling the system out to our wider community. Exciting times!

We need your help though! If you are a programmer, tester, writer, translator, or just want to help in another way, please our getting involved page, join our mailing list, and be sure to join our IRC channel in #ubuntu-accomplishments on Freenode. We hope to see you soon!

Thanks to Rafal, Matt, s-fox, and the many other folks who helped make this release such a success!

The other day I announced our 24-hour horsemen marathon. In a nutshell, we in the Canonical Community Team are going to work for a continuous 24-hour session on Thursday next week. Each of us has picked a charity that we are going to support and I wanted to share some words on why I picked mine…Homeless International.

A few years ago Erica and I were driving through a city and we saw an old guy, bleeding, with no coat, walking along the street in the rain, clearly exhibiting schizophrenia. We both immediately stopped the car and I got out to go and help the guy. I got chatting to him. He was a veteran, he had a son that he had lost touch with, and that day he had given his coat to a lady so she wouldn’t get wet in the rain.

Shortly after I got chatting to a family friend who works with the homeless and he started telling me the true extent of the problems with homelessness and poverty all over the world (he organizes charity events to help the homeless here in the Bay Area). I started looking online more and more into the issue and became more and more passionate about the issue.

Most importantly, homelessness and poverty doesn’t just affect other people. Mental illness, health problems, disability, family issues, escalating drug/alcohol problems and other issues are often the causes of why someone ends up on the streets. It could affect you, your family, or your friends.

Homeless International work to provide support and help to the homeless and poverty stricken all over the world. They do wonderful work in many countries, and they work to provide housing, resources, aid, and other support. They are a truly valuable cause and I am proud to be supporting them.

For more information on the marathon and why you should donate your money to my charity, see the video:

Can’t see the video? Watch it here!

CLICK HERE TO DONATE*.

If you donate you will have love, success, and and unlimited supply of bacon (despite the global shortage) in your life. Who could argue with that?

A quick update on the online dash search feature.

The shopping lens feature is currently in the 12.10 development branch and undergoing extensive testing; thanks to Nick Skaggs for rallying folks around this additional testing to assure quality.

You will be able to disable the feature if you wish. There is work going on to have a toggle switch in the settings to disable it. Note that this will affect all online searches (e.g. Gwibber). The user interface looks like this (shown in French due to Didier’s campaign for French as a global first language):

As I mentioned the other day, the search traffic will be encrypted ready for release, and you can read more details on how the searches work here.