Canonical Voices

Posts tagged with 'ubuntu loco teams'

jono

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. :-)

Read more
jono

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.

Read more
jono

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!

Read more
jono

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.

Read more
jono

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.

Read more
jono

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.

Read more
jono

Just a quick note to remind everyone that our next Ubuntu Developer Summit is taking place this week on Tuesday, Wednesday and Thursday, and is open and available to everyone to participate. This is the event where we get together to discuss, debate, and plan the next three months of work.

The event takes place online from 2pm – 8pm UTC. All sessions will run using a combination of Google+ streaming video hangouts and IRC, and you can see the full schedule on summit.ubuntu.com. Consequently, for those who cannot attend or might miss certain sessions, all sessions will be available pre-recorded from the session pages when the session is complete.

The event kicks off on Tuesday at 2pm with our keynote. We hope to see you there!

Read more
jono

Ubuntu 13.04, the Raring Ringtail, was released today. Go and download it for Desktop, Server, Cloud, and for our Chinese friends, download Ubuntu Kylin. You can find all the details of what is new in Ubuntu 13.04 on www.ubuntu.com.

Ubuntu 13.04 is a fantastic release, and I just want to offer thanks to the many people around the world in our community who helped make it happen. Folks such as developers, app/charm authors, designers, testers, triagers, translators, sys-admins, support providers, governors, docs writers, advocates, and more, all contributed their brick in the wall to delivering Ubuntu 13.04 across Desktop, Server, and Cloud, and continuing to bring freedom and elegance in technology to more people. But this is only part of the story, as behind the scenes, but in full public view, we are continuing to evolve Ubuntu towards our convergence goals. This will be a common theme as we march forward to Ubuntu 13.10, the Saucy Salamander.

I know many of us are tired after a hectic release schedule, so take some time to enjoy the release, get together with other Ubuntu friends, and celebrate Ubuntu 13.04! I will certainly be blowing the froth off a few cold ones tonight. :-)

Read more
jono

Ubuntu is on an exciting journey, a journey of convergence. Our goal is to build a convergent Operating System that brings a uniformity of technology and experience across phones, tablets, desktops, and televisions, and smoothing the lines between those devices in terms of interoperability and access to content. It is a bold vision, but Ubuntu has a strong reputation both in terms of our heritage in the desktop, server, and cloud, and with our passionate and capable community. I just wanted to provide some updates on work that is going on in delivering this vision.

There has been significant work going on in building Ubuntu Touch (the overall name for this convergent platform). The team have marked October in their calendars as the goal to have most of the primary components in the Ubuntu Touch code-base complete so we can deliver a fully converged system in Ubuntu 14.04. The Unity team have been working to centralize the different form factors into Unity Next, which you can play with now (weekly updates on progress coming soon here), the Mir team are making good progress in getting Mir ready for deployment on handsets with a technical preview on the desktop in 13.10 (see the weekly updates), and the Ubuntu SDK team are working towards delivering a beta in the next few months. We have also been working with our community to build the 11 core apps (of which three them are already shipping in the Ubuntu Touch daily development image), the Ubuntu Touch code-base has been ported by our community to and working on 40 handsets, with 25 handsets in progress, and across 19 different brands (of which the 4800+ posts in the XDA Ubuntu Touch forum has helped drive this work), and our app developer community has already grown to 1650 members on Google+ with a huge variety of apps in development, many of which we are pulling together in a PPA. We have also been working to automate the app submission process with a series of AppArmour sand-boxing improvements and tooling changes, we have an eight part tutorial series for writing an app from scratch, and have multiple training events and an Ubuntu App Showdown contest planned. On the business side we have seen tremendous interest from handset manufacturers and carriers, and the business team are in a marathon set of meetings across the world moving the discussions forward.

There is a lot to do, but we have an awesome team and community committed to the opportunity that lays before us. If we stay focused, stay on the ball, and take an organized and pro-active approach to problem solving, we could bring real technological change to the world with Ubuntu delivered via the very devices that form the fabric of most people’s lives. Let’s do it.

Read more
jono

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!

Read more
jono

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.

Read more
jono

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.

Read more
jono

Last week we ran our very first virtual Ubuntu Developer Summit. The event lasted two days and gave us an opportunity to try out a new format and to see how well it worked. Generally it seems we got some pretty favorable feedback, but there are definitely some areas in which we want to sand off the rough edges and improve the structure of the event.

I would like us to get the Virtual UDS format so tight and refined that it could be used to organize any kind of ad-hoc online set of meetings. As an example, I can imagine a similar event but focused explicitly on LoCo teams, or documentation, or translations. We want to make the format reliable enough and repeatable enough that anyone in our (or any other community) can use it. This will help our community to plan more regularly and get together more to do cool and interesting things.

We have been keeping an eye on some of the feedback, a combination of observations from comments and feedback send directly to the organizers. We had an initial chat today to discuss this initial feedback and we have a few changes we want to make already:

  • Wrap-up Session – Many folks seemed to miss a wrap-up session with a set of track summaries. We want to add this for the next event.
  • Remove Launchpad Registration – having to register in Launchpad seems rather futile and doesn’t service much of a purpose. We plan on removing this requirement for the next event.
  • After Hours Session – at the last event there was an ad-hoc free for all hangout session at the end of sessions. This was a fun time to just hang out and be social with each other. We would like to do the same again and publicize it more.
  • Improve Session Pages – the session pages (where you view each session) look rather cluttered right now. We want to tidy them up and also include features such as upcoming sessions and a Twitter stream so everyone can see what is going on at any time. Chris Johnston is currently working with our Web Development community to investigate better layouts.
  • Improve Prep Docs – we discovered lots of useful best practices at the last event such as using the lower third to show the name of the person speaking, checking mic levels, and muting when not speaking. We want to improve and better promote this prep docs for everyone who joins the event.
  • Encourage IRC Integration More – we noticed that in some sessions people pay attention to IRC better than others. I am going to update my introduction presentation to emphasize the importance of this more strongly, and we will build more awareness around the importance of doing this.
  • Fix Page Reloading on Early Terminations – we noticed that on a few sessions there was a problem with the hangout and the session would need to be restarted but the page would not auto-reload the new feed (as the Javascript stops checking when the first hangout is successfully running). We want to fix this.
  • Two Factor Auth! Be Gone! – no-one likes 2FA, it is annoying, so we want to see how we can remove it securely when you access the Etherpad so you don’t need to enter that damn code every-time-you-access-a-session. :-)
  • Integrate IRC/Etherpad Into Hangout Console – for those people in the actual hangout, one problem is that you have to constantly flip between the session screen with the IRC/Etherpad and the hangout window where you are broadcasting from. We want to integrate IRC and Etherpad into the hangout broadcast window to make this easier (and make it easier to keep an eye on IRC).

We Want Your Feedback!

Although some of these conclusions presented here are a great start, we want to make sure we don’t leave any stones unturned! As such, I would like to invite everyone who joined the event to take a few minutes to fill in this survey. This will help us get a better idea of your thoughts on the event, what worked well, and what we can improve. Can I encourage everyone to fill this survey in in the next week so we can start putting some solid plans in place for the next event.

I would also like to organize a community meeting on IRC and invite everyone to join and provide further feedback. I think it would be most beneficial to organize this meeting in a few weeks when folks have had a chance to fill in the survey.

You can also join the UDS IRC channel at #ubuntu-uds and discuss the event there; we all hang out in there.

Want to Help Make Summit Rock?

Virtual UDS is a community event and we want to ensure everyone has an opportunity to contribute to making it as good as possible. One definitive area where folks can help is with our increasingly sophisticated summit.ubuntu.com.

The Summit project is Open Source, and always open to new contributors. It is written in Python and Django, with a large amount of HTML, CSS and Javascript work at well. If you have any of these skills, or are willing to learn them, we encourage you to come be a part of it.

You can get the code and look at bugs on Summit’s Launchpad page. The developers hang out in #ubuntu-website on Freenode IRC, and are available there to help you get a local development environment set up. If in doubt, go and poke mhall119. :-)

Thanks, everyone!

Read more
jono

This week’s live video Q&A is in a slightly later time slot this week on Wednesday at 8pm UTC (click here for the time in your location this week).

As usual everyone is welcome to bring any and all questions to the Q&A.

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

Look forward to seeing you all there!

Read more
jono

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.

Read more
jono

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!

Read more
jono

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.

Read more
jono

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!

Read more
jono

This week’s live video Q&A is back to the normal time slot of every Wednesday at 7pm UTC (click here for the time in your location this week). The day is different this week as I need to join a sprint later this week.

This week I will be running the usual hour long Q&A session as well as talking about some upcoming community projects.

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!

Read more
jono

After missing my weekly live Ubuntu and Community Management video Q&A last week due to exhibiting at CES, I will be doing this week’s live video Q&A on Monday 14th January 2013 (tomorrow) at 7pm UTC (click here for the time in your location). The day is different this week as I need to join a sprint later this week.

I will be kicking off the session with a summary of Ubuntu at CES and a summary of the response to Ubuntu on phones in general as well next steps. We will then get into the Q&A, and as ever, you are welcome to ask me absolutely anything on the show.

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

Look forward to seeing you all there!

Read more