Recently we had our online Ubuntu Developer Summit where we discussed a range of topics, defined next steps, and documented work items. The very last session at the event was an overall summary of the tracks (you can watch the video here), but I wanted to blog an overall summary too. These notes are quick and to the point, but they should give an overall idea of decisions made.

Client

• Content Handling -

  • Siloing apps.
  • Main applications will define a “main repo” and provide an API to deliver, share and access the data in the main repo.

• X.org

  • Want to update to 1.14 or even 1.15 if the video ABI doesn’t change.

• System Settings

  • Focus on the phone settings defined here.

• Scopes

  • Scopes that didn’t land in 13.04 should land within 2 weeks.
  • Several scopes will be migrated from Python to either C++ or Go for memory purposes.

• Chromium

  • Expressed interest in moving to Chromium as default for a better user experience. Gathered feedback on the possible move. Next steps are to take discussion to the mailing list.

• Unity 8/Mir Preview in 13.10

  • Want to have a preview of Ubuntu 8 (Phablet UI) running on Mir as an optional session (installable from universe or PPA, most likely).

Foundations

• Reviewed the current 13.10 release schedule found several changes made in 13.04 that mistakenly hadn’t been carried over, such as later freeze dates and one fewer alpha; Adam Conrad will be syncing all this up and sending mail to the ubuntu-release list for review.
• We discussed the positioning of the development release in light of some conversations last cycle, and put some more flesh on the design for making it easier for people to follow along with the development release all the time.
• This cycle, we’ll be bringing up a new 64-bit ARM architecture based on cross-building work done last cycle, and we’ll update developers on that once we get closer to the point of starting up builds in Launchpad.
• Moving forward with click packages. Fleshed out ideas on source package provision, integrating with existing client package management stacks, and clarifying some other things like the security model.
• For image based upgrades, the team held a demo and Q&A for the current proposed solution, which is split into client, server, and upgrader; client is going well and expected to land by the end of June, server is currently blocked on infrastructure but should be ready around the same time, and Ondrej Kubik has been making good progress at tweaking the CyanogenMod recovery environment for the upgrader.
• Firmed up the plan for packaging Android components for Ubuntu Touch images.
• Upstart will be used as the standard way of spawning desktop apps for Unity on touch devices and ideally on desktop too (Unity 7 and 8). This will let us make sure we only have one instance per app, and will make it easy to apply AppArmor, seccomp and cgroup confinement consistently to all apps.
• Defined a goal to reduce the amount of time it takes to prepare, test and make a Checkbox release, automating more of the process. This will benefit people who use the Checkbox tool as part of their daily work. It’s possible that Checkbox may move to Universe, although this needs some more discussion.
• The server certification tools are being reengineered to use the new plainbox engine as their core. This will preserve the existing UI, but we’ll have co-installable packages with the new core, and will eventually switch over to the new tools.
• The cert tools and test suite are being upgraded to work well on ARM for our hyperscale and mobile work, fixing any issues so we can get full, clean test runs on ARM servers. MaaS will be used for provisioning, and tested as a part of the ARM server solution.
• We will be basing the primary kernels for 13.10 on Linux 3.10, but will strongly consider 3.11 depending on timing. For Ubuntu Touch devices, we already have kernels available for Nexus 4 and 7, and plan to also bring up kernels for Galaxy Nexus and Nexus 10. We’ll provide a 13.04 hardware enablement kernel in the 12.04.3 point release.
• In terms of Ubuntu Touch power management, we have some preliminary baselines against Android on Nexus 4 and will replicate those on other devices, although they won’t be entirely meaningful until things like Mir land. We’ve written some new utilities such as eventstat to track down problems here. On power management policy, we agreed key requirements for the system power manager and we’ll extend powerd to serve our immediate needs.

Community

• Community Roundtable:

  • Approved LoCo teams are no more, will be verified teams.
  • Bringing back fortnightly leadership meetings.
  • Ubuntu Advocacy Kit is driving to 1.0.
  • Gathered UDS feedback.

• Ubuntu Community Website

  • Great discussion which clarified everybody’s involvement in the project.
  • Clear roadmap for completing the content and design in the next few weeks.
  • Design and web team have the templates we need to finish the work.
  • No discussion with IS yet around deployment – this will be coordinated next week.

• Ubuntu Womens Session

  • Several events planned to get more people involved and the word out (Career Days, UOW, etc.).
  • Discussion about a women in technology themed event at CLS.

• Ubuntu Status Tracker

  • The status tracker is many things to many different teams, but we managed to figure out a number of issues we can tackle, which should make everybody’s lives easier.
  • Removal of kanban view.
  • Add links from team pages to milestones pages.
  • Set up a meeting to discuss setting up an “ongoing” dev series.

• Ubuntu On Air! Discussion

  • Issues with supporting multiple hosts.
  • Discussion about building support into summit and re-using vUDS components to support more shows and multiple hosts.
  • We want to open it up to more contributors, so we get more variety into the shows.

• Development Onramp for Touch / Unity Next

  • Goals to improve docs.
  • We will track contributions to all the projects to see how we improve.
  • Increased focus on testing, coordination with the SDK team.

• Documentation Team

  • Update Getting Started Page, review current docs and previous mailing list feedback.
  • Regular doc review cadence and more health check meetings.
  • Focus on content in the UAK.

• Ubuntu Enterprise Desktop Discussions

  • Another meeting will be planned to get more input from users of enterprise desktops.
  • Some common issues were identified and discussed:
  • outdated cfengine package
  • access to Firefox/Thunderbird packages before publication (resolved)
  • support for livemeeting/linc

• More Ubuntu Touch images

  • We identified the current blockers and will simplify thingsby using an image without firmware blobs, so they can be added by a local tool afterwards.
  • After the rebase to saucy we will also update the docs accordingly.
  • Kernel images for devices will first live in PPA, afterwards probably in universe.

• Regular Ubuntu Development Updates

  • Organise regular Ubuntu on Air Hangouts to which we invite people from news sites as moderators.
  • Briefly summarise work from the last week(s).
  • Ask engineers to demo/showcase interesting developments.
  • Do Q&A sessions.
  • Also invite members of governance teams along.

Cloud and Server

• Openstack Next Steps

  • Looked at some high level areas for this cycle, avoiding digging into areas covered by other sessions. We decided that at current, moving over to Git for our packaging work doesn’t add value. We also agreed to clean up on some cruft within the packaging branches.

• Cloud Archive Status Check

  • Decided we had to support Grizzly for 12 months, which exposes a 3 month support gap from the backing Raring release. Need to discuss with the security team about how to fill this gap. Reviewed proposal for SRU cadence and tentatively rubber stamped.
  • Better co-ordination around trumping by Security dates, specifically if it covers more than one project.
  • Looked at using updates as a reason to increase our messaging.

• 12.04.x images with LTS Enablement Kernel

  • The cloud images currently only contain the Precise (3.2) kernel. Discussed adding the kernel HWE stack to cloud images. We need to document how to enable backports, clearly state the support, and possibly tool cloud-init to handle updating the kernel on boot if folks need a more recent kernel on boot.
  • We will not be creating new images with the HWE kernel for the default images. The HWE kernel will be used for Clouds that have a high velocity of change in the Hypervisor (i.e. Windows Azure). For the regular images, we will investigate tooling in cloud-init and other places to make the ingestion of the HWE kernels easier, such as enhancing the documentation, allowing for easier enablement of backports, and making it easier to enable the HWE kernel at boot time.

• Cloud-Init for Vagrant

  • We will create a good Ubuntu development workflow for Vagrant users (cross platform OSX, Windows). Ben Howard will investigate cloud-init tooling as well as the best method to enable the DKMS modules.

• Cloud Init & Cloud Image Development for Saucy

  • We will define the development work to improve cloud-init and cloud images for the saucy cycle.
  • Discussed work on pre-cloud init phase, vendor hooks, cloud init plugin, and rebuding tools.

• Juju Core Development

  • 1.10 version of juju available in backports for 13.04, and should be available in precise backports soon.
  • Look for releases in juju/dev ppa updating weekly, juju PPA monthly, and have stable release go into backports (couple of times per cycle).

• OpenStack Hypervisors

  • HyperV support is currently untested.
  • VMWare support in charms, but not primary supported charms.
  • We need a matrix to demonstrate interoperability and support of each variation.
  • Need to work out additional hardening support.

• Openstack QA

  • Building on our great history, moving away from per commit hardware testing to a more fluid multi virtualised separated environment, allowing greater interoperability testing. Hardware Cert term showed interest in getting more involved. The scope of this will be ratified when the interop matrix is created.

• Flag Bearer Charms

  • Will improve flag bearer charm integration testing.
  • Implement list of reference charms.
  • Develop Percona backup XtraBackup flag bearer charm.
  • Document flag bearer and reference charm criteria in best practices.
  • Discuss flag bearer charms on mailing list.

• Charm Policy Review

  • Add into policy for a charm to provide a config option to specify the version. The other items such as installation location (ie /srv), implementation of common subordinates, backups are to be added to best practices. The 3 ack on charm reviews is still under discussion.
  • Split Juju docs best practices and policy sections.

• Audit Charms

  • Discussed re-reviewing the current charms in the charm store to ensure accurate readmes, tests, functionality, rating, categories, and icons. The workflow was discussed for queues, and which charms to tackle first.

• Charm Development Tooling

  • Discussed gathering all the different charm development tools into one central package. These charm development tools include charm-tools, charmsupport, juju-gui,openstack-charm-helpers. Folks also discussed how the tools could be improved, and used as a singular set.

• Juju Framework Charm for Server Application Technologies

  • Discussed further building out of the Django, Rails, Node.js, and possibly Java.

• Improve Juju Documentation

  • Make a better user and charm developer experience for juju.ubuntu.com/docs. Discussed getting a permanent beta site going, methods to get documentation contributions. Hopefully a revamped docs will be in production in the next couple of weeks, and if not we’ll have a beta site very shortly (days).

• Juju Charm Testing

  • Currently jenkins.qu.u.c has graph testing showing reliable results. Marco will be landing integration soon (days), with a more formal testing framework to follow (weeks).
  • Some ideas discussed were to gate charm store commits on testing, showing testing status in the GUI, and pre-deployment testing. Test examples will be made available along with a charm testing school.

• Add User Feedback loops and Social Networking to Charm Store Charm Pages

  • Discussed making sure users have a method to give and receive feedback on a per charm basis. We currently have social networking (+1s, Likes, Tweets) in addition to downloads, quality rating, bug links, and testing status. Some ideas were to get clarification from design on showing social networking numbers, as well as a ‘leave feedback’ form.

• Juju GUI Development

  • Discussed development done, and upcoming work. Covered ideas such as design, bundles, diagnostics, user data, juju feature parity, maintenance and support.

• Improving QA for seeded server packages

  • Established three distinctive areas of testing, these are upstream test suites which typically run at build-time, integration tests via dep8 and service level testing which often requires multiple nodes and is conducted using juju.
  • We established that there is the regression test suite that can be included in many of the packages directly, with the requirement that we package some of the common ubuntu testing libraries.
  • Discussed some areas of standardisation for dep8 testing.

• Fastpath installer work for 13.10

  • Established what FPI is, and the processes which are part of it.
  • Fast Path installer will be delivered as a installable package in Ubuntu, most likely in python. The interface to it will we yaml formatted configuration.

• OpenStack Charm work for Saucy/Havana

  • Migrate all charms to be python based.
  • Consolidation into new charm-helpers nextgen library.
  • Complete SSL/HTTPS support into charms.
  • Integration of wiki and help documentation, upstream series aligned with upgrading notes.
  • Design around how proprietary+1 plugins will be integrated into core charms for Cinder and Quantum.

• Investigate alternatives to mysql

  • Agreed that the best course of action was to maintain mysql for this cycle, and try and support other flavours of mysql getting into Ubuntu via Debian.

• Ceph activities for Saucy

  • Dumpling release will be out in August (co-incides with FF for Saucy) so will be target for this release.
  • Lots of incremental improvements in efficiency and performance, full RESTful API for RADOS Gateway admin features, block device encryption for data at rest.
  • ceph-deploy (upstream cross platform deploy tooling) will be packaged.
  • Implementation of more automated testing during Saucy.

• HA Openstack charms V2

  • Reviewed the current state of HA support in Openstack charms. Percona has volunteered to charm their offering, allowing great coverage by their mysql HA variant for active/active clustering.
  • Work also on active/active and brokerless messaging options (ZeroMQ) and incremental improvements for service check monitoring in load balancers.
  • Cluster stack (Corosync/Pacemaker) to be reviewed and upgraded for Saucy in preparation for 14.04.

• MongoDB activities for Saucy

  • File Main inclusion report for Mongo to support Ceilometer and Juju use cases. Raise a Micro Release Exemption (MRE) to the techboard, as point releases are bug fix only.
  • Upstream armhf enablement patches. Re-sync with Debian. OpenSSL license exception.

• Virtualization Stack Work for Saucy

  • If debian libcgroup maintainer finds time, we’d like to merge cgroup-lite into libcgroup. For per-user configuration, first make it default-off optional, conditional on userns sysctl being enabled.
  • LXC work is going well on track to 14.04 (and lxc 1.0) roadmaps. For this cycle, we’d like to get user namespaces enabled in the saucy kernel with a new off-by-default sysctl controling unprivileged use, and complete the ability to create and start basic containers without privilege; add console, attach and snapshot to the API, complete the create API function, and convert all of the lxc-* programs to use the API; write a libvirt driver based upon the API, and a patch to enable testing it with openstack; write loopback and qcow2 block device drivers; Get the subuid (user namespace enablement) patches into the shadow package; discuss with the community the maintenance of stable trees; improve the API thread safety; and work our distro lxc tests into the upstream package (akin to how it is done in netcf).
  • In edk2, we want to contribute to the implementation of the ability to save and restore nvvars from the ovmf bios from qemu. We’ll fix the apparmor bug preventing the block device mounting in libvirt-lxc, which is blocking use of that feature by openstack.
  • We intend to merge libvirt at least at version 1.0.6, qemu at 1.5, and hopefully xen 4.3. We’ll follow up on citrix’ plans for xcp. The blueprint lists additional xen work planned. We’ll also look into default use of openvswitch bridges in libvirt.

Quality Assurance

• Core Apps

  • Autopilot testcases written for ubuntu core applications will be checked to ensure they pass before auto-landing updates in the ubuntu touch images.
  • The quality community team will help core application developers develop a suite of manual testcases for each ubuntu core application. These will be run as part of the verification process for the 1.0 stable release of each application.

• Testcases

  • Add testcases so all default desktop applications for each flavor are covered.
  • Expand and improve server testcases to allow more participation by those who might lack domain specific knowledge and/or hardware.

• Growth/Experience

  • Make available documentation more accessible by linking to it from the tools we use for testing, like the qatracker.
  • Continue holding testing ‘how-to’ and knowledge sharing sessions during UDW, UOW, as part of UGJ, and on ubuntu on air.
  • Add testing achievements to the ubuntu accomplishments project.

• Ubuntu Touch

  • Ubuntu Touch images will be smoke tested using the pending/current model already in use for other images. This ensures no image is published for general consumption that doesn’t pass a set of tests ensuring basic functionality of the image.
  • Current Ubuntu Touch autopilot tests for the core applications will be investigated for use as part of these smoke tests.
  • The concept of smoke test is going to be expanded to cover a no regression build.

• Autopilot

  • Autopilot 1.3 is now released and will be available in raring and saucy. No quantal support is planned. Precise support is being examined, but requires further investigation and backporting work.
  • Autopilot developers will now be available on #ubuntu-autopilot — no need to always ping thomi!

• Mir

  • Planned tests for stressing mir to ensure good behavior during stressed conditions for things like OOM, memory leaks and race conditions.
  • Stress tests targeted to be run as often as possible, but might be limited due to time constraints of wanting to run the tests over a longer period of time.

• UTAH

  • UTAH will be expanded to include automated upgrade testing capabilities. UTAH jobs will be created for bootstrapping base images, for performing upgrades, and running post-upgrade tests. The old auto-upgrade-testing tool can still be used by flavors if desired.

• Dashboard

  • Create high-level views of the state of quality in ubuntu by aggregating results of test runs. This will allow for ‘problem’ areas within ubuntu to be more easily identified and targetted for further testing or investigation by interested parties. You can follow this work on the QA dashboard here.

• Upstream

  • autopilot-gtk will now be maintained by the upstream QA team. Bug fixes and outstanding issues will be solved in order to allow for the autopilot desktop tests to run
  • Once running properly, the autopilot desktop tests will become a part of daily image testing
  • Continue development on umockdev to add support for more exotic networking tests (eg, 3G) and research sound testing

As ever, you can track progress on work items on status.ubuntu.com and we hope to see you at the next UDS in three months.

Recently there was yet another storm in a teacup that distracted us from creating and sharing Ubuntu and our flavors with others. I am not going to dive into the details of this particular incident…it has been exhaustively documented elsewhere…but at the heart of this case was a concern around the conduct in which some folks engaged around something they disagreed with. This is not the first time we have seen disappointing conduct in a debate, and I wanted to share some thoughts on this too.

In every community I have worked in I have tried to build an environment in which all view points that challenge decisions or decision makers are welcome with the requirement that they are built on a platform of respectful discourse; this is the essence of our Code Of Conduct. Within the context of an Open Source community we also encourage this engagement around differences to be expressed as solutions with a focus on solving problems; this helps us to be productive and move the project forward. This is why we have such a strong emphasis on blueprints, specs, bugs, and other ways of expressing issues and exploring solutions.

Within the context of this most recent issue I saw three problems (problems I have seen present in other similar arguments too):

1. Irrespective of the voracity or content of an opinion we must never forget to be respectful and polite in the way we express and engage with others, irrespective of whether you are a volunteer, Canonical employee, or otherwise. Respect must always be present in our discourse, irrespective of the content of our opinions; without it we become a barbaric people and lose the magic that brought this wonderful set of minds together in the first place. There is simply no excuse for rudeness, and inflammatory FUD that has no evidence to back it up other than presumed ill-intent serves nothing but to demotive folks and ratchet up the flames, as opposed to resolve the issue and make things better.
2. Trust needs to be earned, but trust should always be built within the wider context of a set of contributions and conduct. Unfortunately some folks consider decisions they disagree with to be a basis for (a) entering into a paranoid debate about the “real reason” the individual or company made that decision (and typically not believing the rationale provided by said decision-maker) and (b) seemingly forgetting about all the other positive contributions that the person or company has contributed. I can assure you there is no nefarious scheme at place at Canonical; our goals are well known in the community. If I felt Canonical was fundamentally trying to demote and shut the community out, I wouldn’t work here; I have no interest in working for a company that doesn’t understand the value of community, and I am not worried about finding suitable employment elsewhere. I work at Canonical because I believe our goals with Ubuntu are just and the company’s commitment to our community is sincere.
3. Ubuntu is not a consensus-based community. Consensus communities rarely work, and I am not aware of any Open Source project that bases their work on wider consensus in the community. It would be impossible and impractical to notify our community of every decision we make, let alone try to base a decision on a majority view, but we do try to ensure that major changes are communicated to our leaders first (this is something we have been driving improvements in recently). We always need to find the right balance between transparency and JFDI, and sometimes the balance isnt’t quite there, but that does not mean there is some kind of illuminati-ish scheme going on behind the scenes.

Ubuntu is a community filled with passionate people, and I love that we have folks who are critical of our direction and decisions. If everyone agreed with what we are doing, we would not always make the right decisions, and our diversity is what makes Ubuntu and our flavors such a great place to participate.

As I said at the beginning of this post, it is important that all viewpoints are welcome, but we have to get the tone and conduct of some of these debates under control. The sheer level of sensationalist and confrontational language that is often in place in these disagreements doesn’t serve anyone but hungry journalists looking for page hits.

Now, I am not suggesting here that anyone should change any of their viewpoints. If you vehemently disagree with an aspect of what we are doing in Ubuntu or at Canonical, that is fine and of course, welcome. What I am appealing to everyone though is to treat others like you wish to be treated, with respect and dignity, and lets keep the sensationalism out of our community and focus on what we do best…building a world-class Free Software platform and its rich ecosystem of flavors.

As many of you will know, our goal is to get the Ubuntu phone in a state where it can be used on a daily basis for testing, and importantly, finding bugs, UI issues, and other details that help us to refine the overall Ubuntu Touch experience. Progress is on-track for the end of May.

I decided to start dogfooding a little early (please remember, we are shooting for the beginning of July to be broadly in shape for dogfooding, so if you try, don’t expect things to be ready right now), so today I put my SIM card in my Galaxy Nexus with Ubuntu Touch and things are working pretty well so far. It seems that my data is no longer getting wiped on image updates, which helps testing significantly, so I am regularly upgrading with the daily images.

As ever, if you decide to test, you are doing so at your own risk…don’t be surprised to see bugs, crashes, and potential data loss (although I have not seen any data loss so far).

Some notes about my experience dogfooding:

• Making and recieving phone calls works well. I am using T-Mobile as my network.
• Sending and recieving texts works well too. Messages appear chronologically.
• Contact syncing is not in place but Sergio blogged about how to sync your contacts from Google. This has made my phone infinitely more useful and rather nicely, it pulls in the avatars too so I can see who is calling me.
• Browsing and connecting to wireless networks works well.
• The browser works well overall, although currently requires wifi (3G browsing coming soon).
• Camera works well (for still photos, video not implemented yet) and I can browse my pictures in the gallery.
• Many of the community-written core apps are present and working. Calendar lets me save and browse calendar events (although syncing with a calendar service is not there yet). Weather shows me the weather for my area right now and a week long forcast. Calculator is working and largely feature-complete. Other core apps are on their way to the daily image soon.
• Overall the core Unity UI is working well. I can search for apps, load them, quit them, multi-tasting works well, and the indicators work (for adjusting volume etc).

The primary blockers in my way right now for normal use out and about are:

• The screen does not auto shut-off. This means if the screen gets turned on in my pocket it never turns off and the battery dies.
• Speakerphone not wired into the UI yet.
• Can’t set the time on the phone yet. Also, the alarm feature in the clock doesn’t work; I need this to get me up in the morning.
• Not so much a blocker, but the phone is still filled with example material and contacts. They need to be removed.

All of these are on the TODO list for completion by the end of the month.

I have been filing bugs for a bunch of the issues I am seeing on a day to day basis and the team are working hard to hit the end of May goal. Overall progress is looking good.

Although I have been using the daily images for quite some time on a phone without a SIM card, using as an actual phone is even more motivating than before. I can feel the phone coming together and when we get many of these issues fixed, it is going to deliver a far superior experience than the Android phone I was using before.

A while back I started a project called the Ubuntu Advocacy Kit. The goal is simple: create a single downloadable kit that provides all the information and materials you need to go out and help advocate Ubuntu and our flavors to others. The project lives here on Launchpad and is available in this daily PPA. If you want to see the kit in action just run:

sudo add-apt-repository ppa:uak-admins/uak
sudo apt-get update
sudo apt-get install uak-en

Now open the dash and search for “advocacy”. Click the icon to see the kit load in your browser.

We discussed the UAK this week at UDS and I want to get the kit to 1.0 level of completeness. This doesn’t require a huge amount of work, just getting a core set of content written up in a concise, simple, but detailed fashion. I want to complete this work and then get the kit up on loco.ubuntu.com as something people can download to get started advocating Ubuntu and our flavors.

I have created a blueprint to track this work and I am stubbing out a bunch of pages in the kit for pages that I think we will need as part of a 1.0 release.

And why are you telling me this?

Well, I am looking for help.

If you enjoy writing and have a knowledge of good quality advocacy, I would like to invite you to write some content. If you can just reply to this post in the comments (or anywhere else I tend to look, such as email or IRC), we coordinate who works on what and I will update the blueprint where appropriate.

Thanks for reading!

Recently the Technical Board made a decision to sunset Brainstorm, the site we have been using for some time to capture a list of what folks would like to see fixed and improved in Ubuntu. Although the site has been in operation for quite some time, it had fallen into something of a state of disrepair. Not only was it looking rather decrepit and old, but the ideas highlighted there were not curated and rendered into the Ubuntu development process. Some time ago the Technical Board took a work item to try to solve this problem by regularly curating the most popular items in brainstorm with a commentary around technical feasibility, but the members of the TB unfortunately didn’t have time to fulfill this. As such, brainstorm turned into a big list of random ideas, ranging from the sublime to the ridiculous, and largely ignored by the Ubuntu development process.

Now, some folks have mused on the decision to sunset brainstorm and wondered if this is somehow a reflection on our community and our openness to ideas. I don’t think this is the case. While it is always important to build an environment where ideas are openly discussed and debated, ideas are free and relatively simply to come by, and the real challenge is converting that awesome vision in your head into something we can see and touch and deliver to others; this is not quite so free and simple. While Brainstorm provided a great place to capture the ideas, and we had no shortage of them, the challenge was connecting brainstorm to the people who were happy and willing to perform the work, and it didn’t really serve this purpose very well.

There were two problems with this. Firstly, picking up other people’s popular ideas is not how Open Source traditionally works. Open Source is built on a philosophy of scratching your own itch, traditionally fueled by programmers fixing their annoyances and building features and applications they want. Now, this is not to say a non-programmer can’t rally the community around their idea and build momentum around an implementation, but doing this requires significantly more effort than a fire and forget submission into brainstorm. In other words, just because an idea is popular doesn’t necessarily mean it is interesting enough for a developer to want to implement it. Secondly, brainstorm started to garner an unrealistic social expectation that popular ideas would be automatically added to the TODO list of prominent Ubuntu developers, which was never the case.

Today at UDS we had a discussion about these deficiencies in brainstorm in traversing the chasm between idea and implementation and Randall Ross had an interesting idea. With brainstorm retired we should re-focus the brainstorm URL and provide some guidance for tips and tricks for how to take an idea and rally support around it to develop an implementation. As an example, over the years I have discovered that taking an idea and building a well formed spec with detailed UI mock-ups and architectural diagrams, a detailed blueprint, regular meetings, and burndown charts, all significantly help to taking ideas from fiction to fandom. Equipping our community with the skills and tools to bring these ideas to fruition is a better use of our time.

So, the TL;DR of all of this is…brainstorm was a great idea at the time, but it didn’t effectively drive the most popular ideas in our community to fruition and delivery in Ubuntu. We want to help provide guidance and best practice to help our community be more successful in converting their ideas into development plans and getting people interested in participating.

Hot on the heels of my last post showing Unity 8 running on Mir on a Macbook Pro Retina, there were some folks who were curious about how well Unity and Mir work on a phone.

Well, thanks to your friend and mine, Kevin Gunn, you can see a video of Unity 8 on Mir running on a Galaxy Nexus (which is by no means a super-powerful smartphone these days):

Can’t see the video? See it here!

Again, just to emphasize, this has not been through a round of performance optimizations, so you can expect additional performance improvements in the future, but I think this demonstrates that we are heading in the right direction.

If you are interested in participating in Mir development, click here and if you are interested in participating in Unity 8, click here.

Recently the Mir and Unity Next teams got Unity 8 up and running on Mir. Now, this work is still very early in development and neither Mir nor Unity Next are finished yet, but I reached out to Michael Zanetti, who is on the team, and asked him to put together a short video demo to show the progress of this work. This demo shows the phone/tablet part of the Unity 8 codebase; the final desktop version will come later.

Here is is:

Can’t see the video? Click here!

As you can see, impressive progress is being made; this demo is running on a MacBook Pro Retina utilizing the full resolution of 2880×1800 pixels and using Intel HD 4400 graphics. The performance is already looking great, and the team haven’t done a deep dive into performance optimization yet.

If you are interested in participating in Mir development, click here and if you are interested in participating in Unity 8, click here.

As a pretty simple-minded person, I am a big fan of simplicity. The world is filled with too much complexity and too much detail. Many often feel the detail is necessary for particular outcomes or to solve particular problems. The lesson I have learned as I have gotten older though is that while the skill is in matching the level of detail to the mind of the observer, the real elegance is in delivering the same level of detail but in a way that feels simpler than expected to the observer. This results in delightful experiences.

Ross Gardler recently quoted Einstein who said “everything should be made as simple as possible, but not simpler“. This so beautifully summarizes my view of the world; life should be as simple as we can make it, but we should not compromise in our goals merely to make things simple. In other words, if we can boil our projects, processes, interfaces, and ideas down into simpler parts that still let us be productive, they become more enjoyable to engage with and thus more successful. Of course, making complex things simple is…complex. It is though, worthwhile, and for many (myself included), a fun challenge. I am sure I am not alone.

As we step into our Ubuntu Developer Summit this week I would like to encourage everyone to think about ways in which we can simplify all aspects of how create and deliver Ubuntu to others as a means to further the project and experience. This doesn’t just apply to user interface design though. How do we make our teams easier to navigate and participate in? How do we make it easier to create your first app, charm, bug fix, translation, document, mailing list post, question, answer, or otherwise? If we can make in-roads this week in simplicity, I am confident it will continue the bold stride Ubuntu is making into the future of devices and the cloud.

Recently Microsoft Open Technologies celebrated their one year anniversary. I just wanted to offer my congratulations on this important milestone.

Now, it could be tempting for some of you to become a little snitty about Microsoft wanting to engage more openly with people, but I believe that this project (as well as the OuterCurve Foundation; a different but similarly themed entity) should be celebrated. These are important steps in Microsoft evolving into a more open future, and folks such as Gianugo Rabellino from Microsoft Open Technologies and Paula Hunter and Stephen Walli from the OuterCurve Foundation are doing wonderful work in treading these careful steps forward. All three of these folks have been tremendously supportive of Open Source, community (including sponsoring the Community Leadership Summit multiple times), and demonstrate a real commitment to delivering those values in a historically proprietary culture. I can imagine that this is not particularly easy work, and I commend them for their commitment, and Microsoft for their evolution as a company.

Open Source has had a profound impact on the world, and for a company with such a philosophically different history to commit staff and resources to exploring a more open future, well, I think this is a fantastic step forward for Microsoft, Open Source, and wider interoperability.

The Microsoft Open Technologies team will be celebrating on Thursday in Silicon Valley with their anniversary party. Be sure to head over there; unfortunately I am unable to join due to another commitment.

Congratulations, Microsoft Open Technologies!

I just wanted to talk about a busy week of community management and leadership related content I will be involved in in July 2013 in Portland, Oregon.

Community Leadership Summit 2013

The Community Leadership Summit is the primary annual event that brings together community leaders, organizers and managers and the projects and organizations that are interested in growing and empowering a strong community. The event pulls together the leading minds in community management, relations and online collaboration to discuss, debate and continue to refine the art of building an effective and capable community.

The Community Leadership Summit 2013 takes place at the Oregon Convention Center in Portland, Oregon on 20th – 21st July 2013, which is rather conveniently the weekend before OSCON.

At the heart of Community Leadership Summit 2013 is an open unconference-style event in which everyone who attends is welcome to lead and contribute sessions on any topic that is relevant. These sessions are very much discussion sessions: the participants can interact directly, offer thoughts and experience, and share ideas and questions. These unconference sessions are also augmented with a series of presentations from leaders in the field, panel debates and networking opportunities.

I can’t quite believe that this is the fifth anniversary of the Community Leadership Summit, and I am determined to make this the very best year yet! We already have an awesome list of pre-registered attendees, and this is shaping up to be yet another fantastic example of the primary place for community managers and leaders to get together to discuss, share, and learn best practice.

The event is completely free to attend, you just need to register first. I hope to see you there!

Community Management Training at OSCON

Speaking of OSCON, which takes place the week after the Community Leadership Summit 2013, I am also delighted to announce that I will be running my very first community management training class.

As some of you will know, I wrote The Art of Community published by O’Reilly (now in its second edition), which has rather fortunately become the best-selling book on community management and leadership.

For some time now I have wanted to deliver a training class that takes many of the concepts of the book, but extends them with detailed problem solving discussions, workshops, Q+A sessions, and more to provide an intense, detail-rich class about how to manage and lead communities, be them small and local or large and global.

On Monday 22nd July 2013, the day after the Community Management Summit 2013, I will be delivering this one day community management training class.

Topics in the class will include:

• Welcome and Introductions
  • Discussing how the class will work, student introductions, and facilities information.
• The Core Mechanics Of Community
  • Read/write communities.
  • Understanding the social dynamics.
  • Building retention and generational growth.
• Planning Your Community
  • Understanding where to focus community management.
  • Gathering stakeholder and community requirements.
• Building a Strategic Plan
  • The importance of a crisply defined strategic plan.
  • Structuring and documenting goals and objectives.
  • Delving down to the work item level.
• Building Collaborative Workflow
  • Understanding the collaborative needs of your community.
  • Building effective communication channels.
  • Determining infrastructure and tooling needs and how to resource them.
• Defining Community Governance
  • The role of governance.
  • Governance styles: dictatorship, delegated leadership, and enlightened dictatorship.
  • Assessing the governance needs for your community.
  • Building, codifying and documenting your governance structure.
  • Growing effective leadership in your community.
• Marketing, Advocacy, Promotion, and Social Media
  • Assessing marketing, advocacy and promotional needs.
  • Building a buzz cycle.
  • Using social media effectively.
  • Tracking publicity work and re-aligning for efficiency.
• Measuring Your Community
  • Knowing what to measure.
  • Defining useful growth and health metrics.
  • Understanding to how to read and react to metrics to provide more focused strategy.
• Tracking and Measuring Community Management
  • The importance of building credibility from good work.
  • Planning for different visibility needs: stakeholders, the community, and your team.
  • Tracking projects, using burndown charts, and reacting to project changes.
  • Tracking growth and decline.
  • Tracking community health and building a network

Find out more about and book your seat in the class by clicking here. Space is limited, so be sure to reserve your seat as soon as possible!

Burnout and Bickering: a Community Manager’s Guide to Conflict

I am also pleased to announce that I will be presenting a brand new presentation at OSCON on Wednesday 24th July 2013 at 2.30pm in D137.

The talk is entitled Burnout and Bickering: a Community Manager’s Guide to Conflict, and here is the description from the talk page

One of the most challenging aspects of growing community is managing conflict and burnout. While we often see the effects of conflict, getting to the heart of the issue is often more challenging.

In this new presentation from Jono Bacon, the Ubuntu Community Manager and author of The Art of Community, he presents a comprehensive guide to conflict and its many different causes.

The presentation explores how to identify these different causes (such as stress, personality differences, language/age/cultural barriers, and more), how to identify when problems are happening in a scalable manner, and how to resolve conflict in a progressive and repeatable way.

Bacon will also cover preventative measures to reduce the potential for both conflict, stress, and burnout, and wrap the content in a set of practical tools you can use in your own community.

All of this will be delivered in Bacon’s amusing anecdote and story filled style, delivering practical recommendations and techniques in a fun and contextual presentation.

I am excited about this presentation. As some of you will know, I have talked before about burnout and managing stress and conflict in communities, and this presentation provides extensive coverage of the topic. I am looking forward to presenting this at OSCON.

See more about the talk by clicking here.

As you can see, quite a week for community management and leadership! I hope to see you there!

Continuing with the work to refine and improve how we build Ubuntu in an open, transparent, and collaborative way, I want to take a few minutes to discuss some work going on to improve the regularity of our planning and the benefits this brings.

Traditionally planning for Ubuntu has worked like this.

• We ship a release.
• Shortly before a release we rapidly prepare blueprints for the next Ubuntu Developer Summit (UDS). Everyone is welcome to participate.
• We discuss topics at the UDS and jot down work items into blueprints.
• We then execute on those work items over the course of the six month period.
• We track this work on status.ubuntu.com and use burndown charts to visualize this progress.

While this has served us well, there are a few problems with this approach. The most notable issue is that we work in software, and a lot changes in software in a six month period. This means we define a set of work items, prepare the burndown, and then if requirements or direction changes it can be difficult to reflect those changes across our community and we have to go and postpone a bunch of work items and re-build our burndowns. This means that even though the changes are made to open blueprints, it can cause folks across our community to be out of sync. It also presents the misconception that everything at UDS is locked in for the duration of the six month cycle. If something changes in our strategy or a new opportunity opens up, it can be difficult to change course with everyone on the same page.

Solving this is part of our theme of making Ubuntu engineering as transparent and agile as possible.

One approach we are experimenting with in the Ubuntu Engineering Management team at Canonical is to increase the regularity and transparency of how we plan. Instead of locking in every six months we will do it like this:

• We host the virtual UDS (vUDS) every three months and use the event as a means to plan out the next three months of work. All discussions are open, everyone is welcome to participate.
• Blueprints will be used to track that work and work items will be divided up into monthly milestones.
• On the last week of every month we will review the work performed in the last month to see how well it was completed and then plan the forthcoming month’s work. This provides an open opportunity to identify blockers, define new goals, and change coarse if needed.
• A new burndown chart will be generated on status.ubuntu.com and we will host a Google+ Hangout presenting the goals for the next month to ensure that everyone is fully up to speed on what is going on.

Now, to set expectations clearly: this is just an idea for how to improve this workflow, and we are doing it for the first time this week, but the idea is that it will dramatically increase the transparency of which teams are working on what, making it easier for others to (a) know what is going on and (b), participate in areas of interest.

My team is currently preparing the work items for April and you will be able to see the final burndown here when it is complete. From there you will be able to see all the blueprints.

I will provide plenty of feedback on what is working well and less well, and your feedback is welcomed, as ever, in the comments.

Building Re-usable Processes

As I mentioned in my previous blog entry, we want to make virtual UDS an event that is repeatable and useful for not just UDS but also for domain-specific events too (such as a LoCo themed UDS). The goal is that this event format is repeatable for our wider community.

Likewise, the monthly planning process is also designed to be repeatable for our wider community too, making it simple to get everyone on the same page for planning and executing on awesome projects.

As ever, feedback is always welcome, but I think this combo of a wider planning event every three months combined with monthly work item sync-ups and planning will result in a pretty effective formula for helping Ubuntu to be as effective, transparent, and collaborative as possible.

Our community is at the heart of how we build Ubuntu. Recently there were some concerns expressed about some aspects of our community and I have been working with various community members and internally at Canonical to resolve some of these issues to make things smoother.

I just wanted to summarize some updates:

• Regular, transparent planning – we want to improve how we plan the delivery of work items, and make that planning more nimble. While the major decisions are reserved for primary discussion at UDS, we want to regularly and transparently checkpoint progress on those projects, and ensure things are moving along. To do this the engineering managers at Canonical will perform this planning on a monthly basis with our community. An an example, with my team, we will decide at UDS what major projects we will work on and document the work items in those blueprints, and every month I will ask the team to commit to delivering an agreed set of work items that month and update the blueprints accordingly. This will make it easier to understand who is working on what, what needs to be done, and areas in which people can participate. This entire process will be completely open and transparent and I would like to encourage our wider community to use the same approach. As an example, this could be a useful technique for our LoCo community to use for planning their work too around advocacy campaigns. All of this work will continue to be tracked openly in status.ubuntu.com.
• Training our engineers – our engineers at Canonical are expected to openly and transparently perform all work that is not considered customer/company confidential. While this expectation is clear, there are sometimes cases when this doesn’t happen (e.g. if someone joins Canonical without the experience of working in an open environment and isn’t really sure how to do this). I have prepared an internal slide deck with these expectations and workflows clearly laid out; my team will be working to ensure everyone gets the deck, reads it, and gets an answer to any of their questions.
• Regular leadership problem solving meetings – one problem we have today is that we don’t have a regular problem solving meeting in our community in which our governing leaders are present at. Instead our different leadership boards (e.g. Community Council, Forums Council) tend to resolve issues pertinent to that specific board. We think it could be useful to have a meeting every two weeks that has representatives from our different governance boards and our community can join and raise topics for discussion. We are going to run the first one of these sessions tomorrow (Tue 19th March 2013) on Ubuntu On Air at 8pm UTC. We invite you to bring your topics there on IRC for discussion.
• Online UDS refinements – as I blogged about last week we have released a survey to gather feedback about how to refine and improve UDS. We have already made some plans for some improvements but I plan on organizing a community meeting to discuss this more next week (I can’t later this week as I am at an event). I think there is an opportunity to refine the format of UDS into a form that becomes a useful and repeatable way of coordinating meetings in a community.
• Weekly Updates – I have reached out to the engineering managers on some of the core projects at Canonical and asked them to provide weekly updates of work going on. We have already seen the first updates for Ubuntu Touch and Mir.
• Prepping announcements better – while the major announcements are now out, one piece of feedback I received is that our community felt ill-prepared around things such as the Ubuntu Touch announcement, and people such as our IRC/Forums/Community councils were inundated with questions and didn’t have good answers to those questions. If we need to make future announcements in the same way again, I am going to ensure our core governance boards are clued up first and we provide a FAQ for our community to refer to when getting these kinds of questions. This should relieve this concern.
• Improving our community on-ramp – one area where I want to drive some improvements is making it easier for people to join the community. We started some work a while back to improve the community landing page on ubuntu.com and I have asked Daniel Holbach to drive that work to completion. I am also working with the Ubuntu Touch and Mir teams to ensure that they have awesome documentation and guidance for how people can participate. A good example of the progress being made here is the Mir documentation. If you would like to help improve these docs, then feel free to dig in and help, or share your ideas on the mailing lists.

I want to get as much feedback on these steps moving forward as well as other ideas and areas in which we can focus. You can always grab me on IRC on freenode (my nick is jono) and I hang out in #ubuntu-community-team. Also feel free to drop me an email and join my regular Q+A session every week. Unfortunately, this week’s Q+A session is canceled as I need to be at an event, but I will be back in the regular slot next week on Wednesday at 7pm UTC on Ubuntu On Air.

Recently there has been some fire flowing about Canonical in the community. These concerns started off as sporadic at first and then we saw a small blog avalanche (blogalanche, if you will) as a number of folks piled onto the ride.

I feel somewhat trapped in the middle of all of this. On one hand I work at Canonical and I believe Canonical are acting in the honorable interests of Ubuntu in helping to build a competitive and forward-looking Free Software platform, but I also feel a sense of personal responsibility when I see unhappy members of our community who are concerned with different aspects of how Canonical engages. Essentially, I sympathize with both sides of this debate; both have the best interests at heart for Ubuntu.

From my perspective there is a balance that needs to be struck. Our community needs to be transparent and open, but also nimble to react to opportunities (such as the convergence story), but also Canonical play an important role in helping us to drive Ubuntu to the masses. We need to be able to work in a way that maintains our Ubuntu values but also gives Canonical the opportunity to get our platform out to the market effectively to reach these users.

I believe one cannot exist without the other; Canonical cannot deliver this vision without our community and Ubuntu would be significantly debilitated if there was no Canonical providing staff, resources, and other investment into Ubuntu. Canonical is not evil, and the community is not entitled; we all just need to step back and find some common ground and remember that we are all in the circle of friends.

This symbol is as potent to me as it was back in 2004.

When I got interested in Linux back in 1998 and wanted to make it my career, my primary motivation was to bring freedom of technology to everyone. This is what attracted me to Ubuntu and ultimately working at Canonical. I don’t want to be rude to other distros who are quite happy within their remit of making a great OS for Linux enthusiasts, but I frankly don’t want to settle for that. I want Ubuntu to be the choice for Linux enthusiasts, but for us to not stop there and also bring Free Software to people who have not yet been blessed by it, and who may be new to technology and the opportunities it provides.

Achieving that goal is not just as simple as making the source code available for the platform and setting up a bunch of mailing lists. It means delivering simple and elegant user experiences built for the needs of our users, consistent and beautiful design, professional-grade quality, strong hardware and software partner relationships, certification across a range of hardware profiles, training, responsive security, diverse marketing and advocacy campaigns, and many other areas. Both Canonical and the community contribute extensively to provide these things that we need to get over that chasm, and importantly, each provides things that the other cannot.

It turns out that building this simple, ubiquitous Free Software experience for everyone is hard. We can’t just settle for the tried and tested approach of pulling the latest upstream software and integrating it into a single Operating System. That is tough, intensive and grueling work in itself, but to achieve the goals I mentioned above we need to be constantly challenging ourselves to innovate and go faster in how we deliver this innovation to our users. We need to always challenge the status quo…not for the sake of being different, but for the sake of not restricting ourselves to tradition and instead helping us to be better at what we do, and ultimately achieve our goals of getting Ubuntu into the hands of more people.

We saw this challenge with Unity: that was a tough, but necessary decision. While we suffered over the firestorm around Unity, I think it ultimately put us in a better position, and now we have a single convergent user interface that spans across multiple devices and we will soon have a single convergent Unity code-base across these devices too. In an era where desktop shipments are down due to the impact of phones and tablets, we are no longer trapped in a form factor that has had a decreasing scope of opportunity for us; the desktop is just one part of our wider convergence vision. This opens up the market for Ubuntu and the Free Software and Open Source values we encompass. While some people in some comment boxes will still bring the hate about Unity, I think that overall it has put us in a position to get Free Software in the hands of more people than if we didn’t make that difficult decision, and the sheer level of interest in Ubuntu for the phone, tablet, TV, and desktop is testament to that.

Put it in my pocket, on my lap, on my desktop, and hang it on my wall.

While making tough decisions is important, it is also important that we maintain our Ubuntu values too. One core value is that our platform and community are open for discussion and participation, so everyone is welcome to help put their brick in the wall. Our archive has long been open and there are many ways to contribute, and while some of these projects were secret before-hand, now everything is out in the open and available for participation. Some may disagree with the rationale of keeping things private, but particularly in the case of Phone and Tablet, the “big-reveal” helped us to have a big splash and generate more press interest and partner inquiries, and thus help us along to our vision.

Importantly though, we made the source and community on-ramp available as soon as we feasibly could. The code for Unity, Ubuntu Touch, and Mir is publicly available, and we are eager to invite people to join and shape those projects. This week we also ran our very first online UDS, with the goal of making the Ubuntu planning process as open and accessible to all as possible, not just those who could travel, and on a more regular cadence. All of the videos, notes and blueprints from that event are archived here. I am confident for the next event we will have an even smoother, better-run UDS, with even more participation.

We are now in a position with a clearly articulated vision around convergence and cloud orchestration, full source availability, daily builds of images, and public mailing lists and IRC channels to have those conversations. Everything is available in public blueprints and tracked at status.ubuntu.com, and we have many outreach campaigns to help our community participate in this vision, such as the core apps project, port-o-thon, regular cadance testing, charm quality improvements, SDK participation, and other areas. Our community should expect our projects to be open, accessible and collaborative, and if they are not, please raise your concerns with the Canonical engineering managers, or talk to me either publicly on my weekly Q&A video hangout at 7pm UTC every Wednesday on Ubuntu On Air, or privately at jono@ubuntu.com, or by contacting me on Freenode IRC – my nick is jono. My door is always open.

Things are never perfect in a community, and I am not suggesting we are perfect either, but I believe we are at the cusp of an incredible opportunity to get Free Software and open technology into the hands of the masses, not just by wishing it to be true, but because there is genuine market opportunity for it to be true.

I just wanted to post a quick blog entry thanking everyone who joined the first day of our inaugural online Ubuntu Developer Summit today. Overall we didn’t see many glitches in our plan of how to run the event, and we also gathered some fantastic feedback for things we can improve and extend upon next time.

If you want to see what happened in the sessions today, you can view the schedule and view any of the recorded hangouts.

Before we get into the second day tomorrow, I just wanted to invite any comments and suggestions for what worked well, what worked less well etc, to see if we can make any adjustments for the second day. Thanks in advance for your suggestions!

If I don’t see you until tomorrow, we look forward to beginning Day 2 at 2pm UTC tomorrow! Be sure to see the schedule and join us in the sessions!

Tomorrow we will be running our very first online Ubuntu Developer Summit. The event will take place over two days and span a range of different tracks: Community, Client, Cloud & Server, App Developers, and Foundations. We have never run an event like this before, but we have prepared extensively to deliver the best online UDS experience we can. When UDS is complete we will then review any rough edges and fix those up for the next event in May.

With this being a new event, I wanted to share some key tips about how to get participate.

For Everyone

UDS takes place on Tues 5th – Wed 6th March 2013 from 2pm UTC. Please note: the original time was 4pm UTC, but we brought the event forward by two hours.

The full event is taking place online and everyone is welcome to join, irrespective of whether you are an active contributor to the community, a partner, a business, an enthusiast, or anyone else. We will be using Google+ Hangouts On Air to stream video from the active participants in the session, and we also provide quick embedded access to IRC, note-taking, and more.

The event will kick off on Tuesday at 2pm UTC with a keynote session. There will then be two hours of sessions, then an hour of plenaries, and then another two hours of sessions. On the Wednesday we will kick off into sessions at 2pm, and have lightning talks in the normal plenary slot. Jorge Castro is taking care of the plenary talks and lightning talks; reach out to him if you want to run a lightning talk.

There are five tracks, with each (apart from Foundations) having two video streams. Each track has two track leads:

• Client – Jason Warner, Sebastien Bacher
• Server and Cloud – Antonio Rosales, Daviey Walker
• Community – Jono Bacon, Daniel Holbach
• App Developers – Alan Pope, David Planella
• Foundations – Steve Langasek

You can find all sessions listed at summit.ubuntu.com. Just visit the session you are interested in at the time of the session to view it; everything is included on the session page. You don’t need anything other than a web browser to view sessions but you will need a Google+ account to actively participate in a hangout.

For Track Leads

You should have all received an email from me about how to schedule sessions and how to start and stop the video streams.

Remember to ensure your Google+ is verified (Michael Hall should have checked this with you).

You and your co-track lead should pick one of the two tracks you have for your track and take care of setting up those streams.

Five minutes before a session (e.g. 1.55pm) is due to begin you should start the video stream and update the session in summit.ubuntu.com with the hangout and broadcast URLS. Likewise, 55 minutes into a session (e.g. 2.55pm), be sure to stop the hangout. We need to start and stop the video streams to ensure the recordings are broken up into the different hour long chunks. Required participants will automatically see a link on the session page to invite them to join a hangout – this page does not auto-reload though, so you may want to ask them to refresh the page to join.

Please keep an eye on the sessions on your track and interact with the session leaders to ensure that any required participants can be invited to the session as needed. There may be times as the session is running that people will need to be invited to join the hangout (e.g. IRC participants) – you need to be available to do this when the session leader needs you. If you are not actively participating in the session, feel free to just mute your mic and keep an eye on IRC or listen for when you are needed.

Instructions for starting and stopping the streams is at https://wiki.ubuntu.com/UDS/Sessions.

For Session Leaders

As a session leader your responsibility is to run a quality session, and to ensure that the topic gets a good level of discussion, work is planned and distributed, and the blueprint gets updated with the agreed work items.

Some tips:

• Make sure your Internet connection and computer are working well in advance of the session. We recommend you stop any software or services that is using your net connection (e.g. switch off any downloads or other video streaming).
• The video hangouts will be started and stopped by the track leads (see above) – if you need to invite a new person to a hangout, ask the track lead to invite them.
• In your session you will have people in the hangout speaking as well as people on IRC offering their contributions too. Be mindful of the IRC contributors, and repeat comments and statements of interest from IRC.
• Think of the hangout as the inner ring of the fishbowl at a physical UDS. Unfortunately there only 10 seats on the hangout, so we need to ensure the most active participants are in the hangout. People in the hangout should be speaking and actively participating. If you have an active participant on IRC and have free seats on the hangout, be sure to invite them to the hangout. Likewise, if you see someone who is not contributing on the hangout and there is someone active on IRC, ask the hangout person to move to IRC to open up a slot to invite the IRC person and bring them into the hangout.
• At the beginning of the session, explain the goals and purpose of the session and encourage people to take notes in the embedded etherpad.
• Have the discussion in the session, and be sure to help everyone participate as much as possible. Remember, you should try to keep the most active members in the hangout.
• 10 minutes before the end of the session summarize the key decisions and log work items on the blueprint that are assigned to people. This will provide a great set of next steps to move forward with that blueprint.

For Attendees

Joining a session is easy – just look at the schedule and click on a session to view it. On each session page you can see the video stream, the embedded IRC channel, and the embedded etherpad collaborative note taking. You can also see links to the blueprint and other related content.

You don’t need anything other than a web browser to view sessions but you will need a Google+ account to actively participate in a hangout.

If you want to chat to others in general about UDS, you can also join #ubuntu-uds on freenode.

All sessions will be recorded and available on the schedule when they are completed.

Big shout out to the awesome community over at XDA Developers who have been getting involved in the Ubuntu Touch Port-o-thon to bring the Ubuntu Touch images to more and more devices. Daniel Holbach kicked off the port-o-thon the day after we released the code and images last week, and we are already seeing fantastic work going on.

When the initial announcement hit their forum it generated over a 100 posts within a day and there is currently 101 pages of posts on that thread. There is also an Ubuntu Touch Subforum which has seen over 4000 posts already. We are just blown away by the level of interest.

As you can see on the devices wiki page we are already seeing some fantastic work going on to port Ubuntu Touch to additional devices. Here are some great examples of this work (click each link to see the XDA Developers thread):

• Galaxy Nexus (toro)
• Galaxy Nexus (toroplus)
• Sony Xperia S
• Sony Xperia T
• Samsung Galaxy Note II
• Samsung Galaxy Note
• Asus Transformer Infinity
• Nexus One
• Galaxy Tab 2 10.1 Wifi
• Asus Transformer Pad TF300T

Awesome work!

I asked David Planella and Daniel Holbach on my team to kick off a regular engagement with XDA Developers to help us grow an great relationship together. The first call was today and we are kicking some ideas around of how to work more closely together. Stay tuned for more!

Some of you may have seen the news about us transitioning to an online Ubuntu Developer Summit and running the event every three months. If you didn’t see the news, you can read it here. I just wanted to share my personal perspective on this change.

For a long time now I have been attending Ubuntu Developer Summits as part of my work, but for the last event in Copenhagen my wife was about to give birth and so I attended the event remotely. As someone who has been heavily involved in the planning and execution of UDS for the last 10 or so events, I was intimately aware of the remote participation features of the event, but I had never actually utilized them myself. I was excited to dive into the sessions remotely and participate.

For the sessions I dialed into I found the remote participation worked well, but not as well as it could. Sometimes it was a little difficult to hear people (despite us alway encouraging speakers to sit near the middle of the fishbowl), and for the sessions I wasn’t able to actively participate in (due to the timezone differences), only some of those sessions had videos available that I could review after the session had ended. As such, this made it something of a challenge at times to get an overall view of the event; it depended on attendees taking good notes (which generally happens), but I missed the specifics of the discussions.

Remote participation has always been a critical part of UDS and I think it worked efficiently as it could, but these issues were primarily due to the challenge of delivering an in-person event to an online audience and the practicalities therein.

Of course, the real challenge is getting you people to eat these things.

The move to an online event effectively solves the majority of these issues: every single session will be recorded and available for viewing after the fact (which is awesome for not only attendees, but also for the press, partners and others), and with everyone in the hangout facing a webcam and a microphone, the quality of the content should be better too.

For those people who can’t join the session hangout video stream, IRC participation is available, and those IRC discussions will be logged too and provided in addition to the video of the session and the Etherpad notes. This provides a great overview of all the content and discussion in the session.

An online event is also going to open up the event to more potential participants. There are many folks who either can’t physically travel or justify the travel expenses or time away from their work and family commitments who can now participate in the event by simply opening their web browser. With the wide focus in Ubuntu across the desktop, devices and the cloud, we need more specialists rather than fewer to guide us on our mission, and the online event will make it easier for those folks to attend. I think that this will result in wider and more diverse discussion, ultimately helping us to do a better job planning UDS.

Some folks have expressed a concern about not having as much face-to-face time as in a physical event. Of course, video-conferencing will never ultimately replace being in the same room as someone, but I think much of that personal connection is still shared via hangouts. As an example, my team at Canonical used to have team meetings on Skype or a Conference Call and ever since we switched to Google+ Hangouts the sense of personal connection and team spirit has skyrocketed. Sure, it doesn’t replace being in the same room, but when we balance out the benefits of an online event for the reasons I mentioned earlier, it seems like a reasonable trade-off to me.

Iterative Improvements

One thing that many folks don’t see from behind the scenes of planning the physical UDSs is that we have always taken an really rigorous approach to improving and refining the event. This not only includes the structure of the event, but we have iterated after every detail to improve room layouts, A/V needs, timing, remote participation requirements, scheduling patterns, and more. Every detail of UDS has been scrutinized after every event, and the survey we send out is reviewed with a fine tooth comb, all with the goal of squeezing out as much efficiency as possible so the time everyone commits to UDS is as worthwhile as possible.

We are still exploring the alleged productivity-enhancing benefits of light ping-pong.

With UDS previously happening every six months this has helped us to build a pretty bullet proof formula for the physical event, and many attendees comment at each UDS about just how efficient it is and how much gets done. This is largely due to this iterative refinement process.

The first online UDS takes place next week and I think we have a pretty good plan for it, but we are going to go through exactly the same process for reviewing how each event goes and buffing off the rough edges so that works better and more efficiently each time. With us now doing a UDS every three months it should not take too long to get us into a winning formula, and our community are an essential part of helping us to refine these different pieces. As I mentioned in the announcement blog, after the second event we are also going to take a general look to see if an online UDS is serving the needs of the project well in terms of how we plan Ubuntu development.

Got Questions?

I am sure many of you will still have questions about the new format of UDS. Tomorrow (Wednesday) at 7pm UTC. I will be doing my usual weekly Q+A videocast on Ubuntu On Air and will dedicate part of the session to covering how the online event will work and answering your questions. Feel free to bring your UDS and any other questions to the session!

A few days ago we announced Ubuntu for Tablets; the next piece on our wider Ubuntu convergence story. The tablet joins the Phone, TV, Ubuntu for Android, and the Desktop. See an excellent hands-on video review of the current developer build from Engadget.

Today the source and images for Ubuntu for Phones and Tablets (collectively known as Ubuntu Touch) was released.

I know there is some anticipation regarding this release and I just wanted to share a few facts to ensure we are all on the same page:

1. Both Phone and Tablet code and images are available – today we are releasing two things for both the phone and the tablet. Firstly, if you simply want to run the software on a spare device, you can install the images on your device without caring about the code. If on the other hand you want to see the code (and contribute to it) we are also making this available too so that you can build, explore, and hack on it.
2. This is unfinished and in-development software – it is important to remember that this is in-development software and as such is not finished yet. You are going to find that some features and applications are missing, and you will likely find bugs. We wanted to release the code and images early so that our community can try the software, provide feedback, and be able to join the development effort. With this goal to get the content out early we just want to ensure everyone fully understands that this is not yet a final product. I strongly recommend you only install the code/images on a spare handset/tablet and not your main phone/tablet due to the fact it is in-development code.
3. A limited set of devices are supported – the images are only available for the Galaxy Nexus, Nexus 4, Nexus 7, and Nexus 10; these are the devices that our development team has been working towards. We appreciate that you may have a different phone or tablet, but unfortunately support for other devices is not currently planned. We will however be kicking off an outreach campaign soon to encourage and support our community in porting the code to other devices. Stay tuned for more!
4. A new SDK is available also – in addition to the release of the code and images we have also released a new version of the SDK which includes a number of new features, most usefully the ability to deploy a QML app to a device so you can run it!
   • Ubuntu SDK application templates and wizard
   • QML2 UI designer
   • Templates for testing framework and internationalization
   • Deploy QML applications on an Ubuntu Phone/Tablet device
   • Basic terminal (ssh, adb) connectivity tools to the device
5. Know where to find help – if you have questions or queries you should post your questions to Ask Ubuntu by clicking here.

I am sure you are now chomping at the bit to grab the images, check out the code, and get the new SDK release! Go and find all the details here.

video platform video management video solutionsvideo player

See the video here

The Community Leadership Summit 2013 brings together community leaders, organizers and managers and the projects and organizations that are interested in growing and empowering a strong community. The event pulls together the leading minds in community management, relations and online collaboration to discuss, debate and continue to refine the art of building an effective and capable community.

This year the event takes place on 20th – 21st July 2013 (the weekend before OSCON) in Portland, Oregon and is the fifth anniversary of the event and I am determined to make it bigger, better, and more valuable than ever. Over the previous four events CLS has become the primary annual meeting place for community leadership, and every year we get an absolutely wonderful and diverse attendance spanning technology, education, government, science and more.

At the heart of Community Leadership Summit 2013 is an open unconference-style event in which everyone who attends is welcome to lead and contribute sessions on any topic that is relevant. These sessions are very much discussion sessions: the participants can interact directly, offer thoughts and experience, and share ideas and questions. These unconference sessions are also augmented with a series of presentations from leaders in the field, panel debates and networking opportunities.

Sponsorship

I am currently getting the wheels in motion for the sponsorship for CLS13 and I just wanted to invite any organizations reading this who might be interested in sponsoring the event. CLS is not a particularly expensive event to put on, but I want to expand the usual sponsorship this year to add a little more polish than usual to the event. As such, I am looking for companies or might be interested in supporting the event and getting exposure to community leaders across a range of industries, but with a strong focus on technology.

One of the messages I emphasize in my opening plenary is that the sponsors of the event don’t buy editorial direction or influence (as the event is very focused on being free, open, and attendee-content driven), and as such sponsorship of CLS is very much an affirmation of support of the event for the right reasons. As such, association with CLS as a sponsor has typically reflected very well on those companies who have sponsored in the past. Such companies have included Intel, Microsoft, Black Duck, Oracle, O’Reilly, OpenNMS, and others.

If you are interested in supporting CLS, please drop me an email to jono@jonobacon.org. Thanks!

This week’s live video Q&A is in the normal time slot of every Wednesday at 7pm UTC (click here for the time in your location this week).

As ever, you are welcome to ask me absolutely anything about Ubuntu, Free Software, Community Management, Technology, or anything else. The only questions I don’t accept are tech support questions – Ask Ubuntu, IRC and the Ubuntu Forums are better resources for that.

To join, head over to Ubuntu On Air at 7pm UTC on Wednesday and you can ask your questions in the embedded chat box.

Look forward to seeing you all there!