LTTng (Linux Trace Toolkit - next generation) is a highly efficient system tracer that allows tracing of the kernel and userspace. It also provides tools to view and analyse the gathered trace data.  So let's see how to install and use LTTng kernel tracing in Ubuntu. First, one has to install the LTTng userspace tools:
sudo apt-get update sudo apt-get install lttng-tools LTTng was already recently added into the Ubuntu 13.10 Saucy kernel, however, with earlier releases one needs to install the LTTng kernel driver using lttng-modules-dkms as follows:

sudo apt-get install lttng-modules-dkms It is a good idea to sanity check to see if the tools and driver are installed correctly, so first check to see the available kernel events on your machine:
sudo lttng list -k And you should get a list similar to the following:
Kernel events: ------------- mm_vmscan_kswapd_sleep (loglevel: TRACE_EMERG (0)) (type: tracepoint) mm_vmscan_kswapd_wake (loglevel: TRACE_EMERG (0)) (type: tracepoint) mm_vmscan_wakeup_kswapd (loglevel: TRACE_EMERG (0)) (type: tracepoint) mm_vmscan_direct_reclaim_begin (loglevel: TRACE_EMERG (0)) (type: tracepoint) mm_vmscan_memcg_reclaim_begin (loglevel: TRACE_EMERG (0)) (type: tracepoint) .. Next, we need to create a tracing session:
sudo lttng create examplesession ..and enable events to be traced using:
sudo lttng enable-event sched_process_exec -k One can also specify multiple events as a comma separated list. Next, start the tracing using:
sudo lttng start and to stop and complete the tracing use:
sudo lttng stop sudo lttng destroy and the trace data will be saved in the directory ~/lttng-traces/examplesession-[date]-[time]/.  One can examine the trace data using the babeltrace tool, for example:
sudo babeltrace ~/lttng-traces/examplesession-20130517-125533 And you should get a list similar to the following:
[12:56:04.490960303] (+?.?????????) x220i sched_process_exec: { cpu_id = 2 }, { filename = "/usr/bin/firefox", tid = 4892, old_tid = 4892 } [12:56:04.493116594] (+0.002156291) x220i sched_process_exec: { cpu_id = 0 }, { filename = "/usr/bin/which", tid = 4895, old_tid = 4895 } [12:56:04.496291224] (+0.003174630) x220i sched_process_exec: { cpu_id = 2 }, { filename = "/usr/lib/firefox/firefox", tid = 4892, old_tid = 4892 } [12:56:05.472770438] (+0.976479214) x220i sched_process_exec: { cpu_id = 2 }, { filename = "/usr/lib/libunity-webapps/unity-webapps-service", tid = 4910, old_tid = 4910 } [12:56:05.478117340] (+0.005346902) x220i sched_process_exec: { cpu_id = 2 }, { filename = "/usr/bin/ubuntu-webapps-update-index", tid = 4912, old_tid = 4912 } [12:56:10.834043409] (+5.355926069) x220i sched_process_exec: { cpu_id = 3 }, { filename = "/usr/bin/top", tid = 4937, old_tid = 4937 } [12:56:13.668306764] (+2.834263355) x220i sched_process_exec: { cpu_id = 3 }, { filename = "/bin/ps", tid = 4938, old_tid = 4938 } [12:56:16.047191671] (+2.378884907) x220i sched_process_exec: { cpu_id = 3 }, { filename = "/usr/bin/sudo", tid = 4939, old_tid = 4939 } [12:56:16.059363974] (+0.012172303) x220i sched_process_exec: { cpu_id = 3 }, { filename = "/usr/bin/lttng", tid = 4940, old_tid = 4940 } The LTTng wiki contains many useful worked examples and is well worth exploring.

As it stands, LTTng is relatively light weight.   Research by Romik Guha Anjoy and Soumya Kanti Chakraborty shows that LTTng describes how the CPU overhead is ~1.6% on a Intel® CoreTM 2 Quad with four 64 bit Q9550 cores.  With measurements I've made with oprofile on a Nexus 4 with 1.5 GHz quad-core Snapdragon S4 Pro processor shows a CPU overhead of < 1% for kernel tracing.  In flight recorder mode, one can generate a lot of trace data. For example, with all tracing enabled running multiple stress tests I was able to generate ~850K second of trace data, so this will obviously impact disk I/O.

What does every development team want? New contributors!

I'd like to suggest a simple process that can turn visitors to your website, list or IRC channel into a successful part of the development team. When people actually contribute, they quickly feel like a valuable part of the group. New people bring fresh energy, and new ideas.

At your next sprint or meeting, start dreaming. Is your user documentation well-written and up-to-date? Do you need promotion, or video guides? How about art or diagrams for your website? Speaking of your website, when was the last time all the links were tested, and it was checked for spelling and grammar? Create a nice, friendly list of tasks for your newcomers.

Could your codebase use some grooming, for common misspellings, for instance? (EBN is a great source for these). When you run across a bit of code which needs pruning or refactoring, or normalizing signal-slot stuff, the easy thing is to fix it while it's in front of your eyes. Instead, consider which of these small tasks can be filed as a "Junior Job", created for the purpose of getting those knowledgeable people to move from faithful user, to part of the team.

The Bugsquad and Quality Control teams can likely suggest more ideas, too.

KDE Junior Jobs can be easily found: http://kde.org/jj. Teams can create their own shortcut links too, such as Amarok has done, listed in the #amarok IRC channel topic: http://tinyurl.com/amarokjjs. Other tasks can be blogged about, posted on a trello, on the Community wiki; whatever your team likes to use. For more ideas, see http://community.kde.org/Getinvolved.

The Kubuntu team has a list of tasks in Trello, which works well.

So, when you feel like not fixing a little issue, don't feel lazy. Feel responsible! File a bug, make it a JJ, and call attention to those issues when new folks show up and ask, how can I help?


PS: Thanks to the #kde-www team for suggesting this blog. Einar77, neverdingo, mamarok; you are wonderful.

PPS: How LibreOffice does it: https://wiki.documentfoundation.org/Development/Easy_Hacks

After three Nights of Xubuntu, the Xubuntu team is able to present you a quick overview of some of the planned features and improvements for Xubuntu 13.10. Enjoy!

Software and development

On the software side, apt-offline will be included in our default installation after a few cycles of preparing and writing documentation for it. This will help our users who have impaired-bandwidth situations and usage documentation is already present in the 13.04 offline documentation. The team is also considering the possibility to add a keyboard shortcuts overlay to help new (and why not old) users with their shortcuts-fu. Finally, the team is looking to improve the Pavucontrol user interface to make it more intuitive.

The team also discussed if a heads-up display (HUD) would fit to the Xubuntu paradigm and if it would be viable to implement. The team decided that including or working with one should be postponed until after the long-term support (LTS) release since there isn’t a proof of concept of a HUD suitable for Xubuntu ready and developing one would take a lot of developer time. Further inquiry can take place, though.

Besides the additions and improvements to software, the team roughly discussed including a Xubuntu core meta package which would include only a basic system without various applications seen in the current default installation. Some team members are working on drafts for the contents for the package as you read this article. The meta package would be installable instead of the Xubuntu desktop package during installation.

Documentation

The team is keeping the pressure up on the documentation improvements. The team is looking to extend the re-written Xubuntu documentation from a few releases ago even further as well as to get the infrastructure rights to enable translations for the documentation.

In addition, another goal is to get started with the 12.04 documentation review to supply a more up-to-date version via a stable release update for the LTS users as well.

Community

As with the previous cycles, we will keep on focusing on community. One of our targets this cycle is to get several people new upload rights to the Xubuntu package set. We also hope the prospective developers can help create processes with the newly appointed QA team lead to help reinforce the QA team as well as help with their testing duties.

Milestone participation

As usually, Xubuntu is following the Ubuntu release schedule. While the release schedule is far from final, the Xubuntu team is planning to release one alpha and both betas. At the moment the alpha participation looks pretty certain but the details depend on the Xfce 4.12 release. We will keep sending updates as soon as we have any news.

Summary

In the end, this is a final tune-up before we head into developing the LTS release that is expected to be unleashed in April 2014.  Xubuntu presents a conservative desktop choice among the Ubuntu flavours.  As we head into the Saucy Salamander development cycle, we will be striving for excellence once more.

To read the full notes from the three meetings, refer to the following URLs: night 1, night 2, night 3. If you are interested in the original agenda for the nights, refer to the following URLs: development and milestone participation, forward-looking issues, software.

It feels like Friday! Why? I think it's because I am tired. I am tired because Virtual UDS turns out to be surprisingly intense.

Power to PeopleSo, that is to say, the second Virtual UDS is over. After experience my second vUDS, I think vUDS is really a boost for the transparency of the Ubuntu Project for a few reasons.

• Frequency. We can do it every 3 months instead of every 6 months. As I mentioned in the opening plenary, this is important because we don't actually plan only every 6 months anymore. Like any modern software project, we are continuously planning. The 3 month cadence for vUDS means that there will be less time between detecting a need to change plans and discussion about how to make those necessary changes. I pushed very hard to have the first vUDS quickly, because there was a lot of planning for Ubuntu Touch that was backed up and needed proper discussion. If we waited until now, a lot of the work would have started without a good opportunity for discussion.
• Access. Folks don't have to travel to wherever UDS is. People with specific interests can rock those interests with a laser focus, without having to dedicate a whole week away from home. Let's face it, traveling for 2 weeks a year to participate in UDS is something that only a few privileged people can swing. Many many more people can join a hangout.
• Persistence. The sessions are streamed live, but then instantly available for reviewing, along with the white board, links to blueprints, etc... Try it. Go to Summit for the UDS that just ended. Find a session. Click on the session. It's like you are there live. Discussions that used to exist only in the memories of a select few with some written traces are now persisted and available.

Personal FavesI won't go into a run down of the results, because that job is taken. However, here are some of my personal favorite discussions at this vUDS. These are my favorites based only on personal interests of mine. These are by no means the most important decisions or discussions. Just things that interest me a lot personally.
Rolling ReleaseAfter the unfortunate kerfufle last cycle when I pushed hard to move Ubuntu to a model of LTSs with rolling releases in between, it was niceto close in on one nice outcome. Namely, Colin has a technical solution that will allow users to subscribe to essentially the tip of development. Instead of using "raring" or "saucy" in your sources lists, you'll subscribe to a new name which is symlinked to whatever is the current development release. In this way, each day you will be on the latest. Even the day after a development release becomes a stable release, because the symlink will just point to the next development release.

I ended up with a couple of action items from this session. Mostly, to come up with a name and bring it to the next Tech Board meeting for approval. I'm very much leaning to "rolling", but I am open to discussion ;) This would mean you could say "I am on Raring", or "I am on Precise", or "I am on Rolling". "I am on Rolling" means that you are on the tip of development. Fun!
Touch Image TestingI've been very keen to get Ubuntu Touch out of "preview" mode and into our standard development processes so that they inherit all of the daily quality tools that we have in place. This means moving all the code of out PPAs and into the real archives, so that we get the benefits of all the efforts we have put into place around -proposed and archive maintenance. It also means getting smoke testing and regression testing automated on the Touch images. I loved hearing from the Phone Foundations team and the QA team about their vision for "not accepting regressions". We should have dog-foodable touch images as early as the end of this month. Then if we can keep the images fully usable with minimal regressions each day, we will go very fast towards completion.
Ubuntu Status StrackerI am partial to this topic because the status tracker started out as a labor of love for me. The first real bit of code that I wrote after joining canonical was to render my version of burndown charts. If I am not mistaken this code is still in use. In any case, status.ubuntu.com is critical to maintaining our planning, and ensuring that the status of the project is visible to all.

Unity 8 in 13.10While 13.10 is very very focused on Ubunty Touch for phones, we all know that the real prize is the fully converged client OS. With that in mind, I think it's important to get the code up on as many device types as possible as soon as possible. There was a rich discussion about the steps to offer Unity 8 on top of Mir as an option in 13.10. Now, keep in mind that the result will only be the Phone UI on the desktop, and the default will be the Unity that we know and love today (with Smart Scopes and other enhancements of course!). Still in all, I am betting that basing Unity 8 on QML means that it will be surprisingly functional on a desktop even though it won't have any real desktop support in terms of things like workspace switching, etc..

Back in 2010 I packaged Google’s ipaddr module because I needed a light weight IP address manipulation library that supported both IPv4 and IPv6 and (at the time) python-subnettree was IPv4 only.  Well, ipaddr is all grown up now and included in python3.3 as the ipaddress manipulation module in the standard library.  You can find details, as well as some description of the differences, in PEP 3144.

I just converted one package that I’m upstream for to use either ipaddr (for python2.6/2.7/3.2) or ipaddress instead of some custom code.  It turned out to be pretty easy to make it work with either.  Other than the name, the only difference I ran into was the removal of the common, generic IPAddress and IPNetwork functions that are replaced by ip_address and ip_network.

…
-import ipaddr
+try:
+    import ipaddress
+except ImportError:
+    import ipaddr as ipaddress
…
-    address = ipaddr.IPAddress(ip)
-    if isinstance(address, ipaddr.IPv4Address):
+    try:
+        address = ipaddress.ip_address(ip)
+    except AttributeError:
+        address = ipaddress.IPAddress(ip)
+    if isinstance(address, ipaddress.IPv4Address):
…

Currently, python3-ipaddr has no reverse-dependencies in the archive (python-ipaddr does).  Once python3.2 is dropped from Jessie, I think I’ll drop the python3-ipaddr binary on the assumption people newly coding for python3.3 should use ipaddress.  The python-ipaddr module will stick around for use with python2.7.

Following on from the first event in March of this year where we had a great day of talks covering varying topic I am very happy to announce the next HacknTalk will take place on the 29th June at the Google Campus again in London.

For those who missed it we had a great turn out and had talk on “Documenting tools for Tech Events“, “How to get kids more involved in open source in Education“,” Exceptional Money“, “Using MVC in Game Design” and we learned about STEMNET.  There were other talks, lots of demonstrations and hands on help from members of the community helping one another with their questions.

We hope to reproduce the fun and informative day again in June.  Learn about more great projects that are happening in the varying open source communities and meet new people. Since HacknTalk is an unconference, the speaking/demo schedule will be set on the day and everyone is free to propose a talk themselves. You are of course free to come along, sit back and listen to other people’s talks but we’d like to encourage everyone to take part and talk on something they are passionate about in technology.  There is lots of space, wifi, and power sockets to go around. Break out areas to work on your hacking or demoing and hanging out with people.

If you want to come along please do remember places are limited so you need to sign up. If you can’t make the event, let other people in your community know about it and remember there will be another event in 3-4 months again. You can follow @hackntalk for more updates.

We’re back with the twelfth episode of Season Six of the Ubuntu Podcast from the UK LoCo Team! Alan Pope, Mark Johnson, Tony Whitmore, Laura Cowen and The Podcats are all set in Studio A with cake and an interview.

 Download OGG  Download MP3 Play in Popup

In this week’s show:-

• We interview Rick Spencer, VP of Ubuntu Engineering at Canonical, about engineering Ubuntu.
• We share some Command Line Lurve: gpg --multifile
• We chat about attending an Ubuntu development sprint in Oakland, more Doctor Who stuff at the British Film Institute (it is the 50th anniversary year!), and going to watch the Reduced Shakespeare Company reducing Shakespeare to 90 mins (including an interval).
• And, of course, we go over your marvellous feedback.

Please send your comments and suggestions to: podcast@ubuntu-uk.org
Join us on IRC in #ubuntu-uk-podcast on Freenode
Leave a voicemail via phone: +44 (0) 203 298 1600, sip: podcast@sip.ubuntu-uk.org and skype: ubuntuukpodcast
Follow our twitter feed http://twitter.com/uupc
Find our Facebook Fan Page
Follow us on Google Plus
Leave us some segment ideas on the Etherpad

                          

In late 2008, I sketched initial designs for what became Gnome’s System Settings utility. This centralized most operating system settings in a single window, without the need to reopen menus or switch between multiple windows if you didn’t find the setting you were looking for the first time. It made Ubuntu, and other Gnome-based systems, much easier to configure.

Five years later, we’re building a phone operating system. So once again, we need a centralized system settings interface.

What other phone OSes do

The first step in designing this was a competitor evaluation of how other phone systems present system settings.

iOS 6.1.4.

iOS is highly consistent in using a hierarchy of list items for Settings. But their design is rather awkward in three ways. First, the top-level Settings screen is very long, usually containing 30 or more top-level categories. Second, Apple originally tried to include application-specific settings inside the system-wide Settings, which made them hard to find while using the app. Some apps (including nearly all the default ones) still do that, but nowadays most put settings in their own UI. And third, the top-level “General” settings category is a bit of a junk drawer — containing subcategories for everything from auto-lock to accessibility, software updates to Siri.

Android 4.2: Tapping “Set mobile data limit” checks the checkbox. Tapping “Mobile data” flashes the switch label, but does nothing else. Tapping “⋮” opens a menu of more settings.

Android’s Settings similarly uses a hierarchy of lists, though some sections use dialogs instead. It has other consistency problems, too. Sometimes checkboxes are on the left, sometimes on the right. Tapping a checkbox label toggles the checkbox, but tapping a switch label doesn’t toggle the switch — sometimes it navigates to a different screen, other times it does nothing at all. Sometimes a screen’s heading contains a Back button, sometimes it doesn’t. Sometimes it contains a “⋮” dropdown menu of more settings, and sometimes it doesn’t. All this shows the importance of system settings having, if not a single designer, at least strong design guidelines.

An impressive aspect of Android’s Settings is that they can display in either portrait or landscape mode.

Windows Phone 8.

The Windows Phone design emphasizes typography and visual simplicity. It’s a bit rough around the edges: for example, the “photos+camera” settings screen uses ten font variations, and the main heading doesn’t fit on the screen. Windows Phone also groups “system” and “applications” settings on separate screens, but the separation needs work: for example, the voicemail sound effect is set in one of the “system” screens, while the voicemail number is set in one of the “applications” screens.

A nice detail in Windows Phone’s Settings is the use of summary values. The row you would tap, to navigate to a settings screen, often contains a line of small text summarizing the current settings values. This can save you from having to visit the other screen at all.

Learning from others

This competitor evaluation revealed three main issues. First, the difficulty of organizing system settings versus application settings. Apple tried to group them all together in iOS, but that lacks in-app discoverability. Microsoft used “system” and “applications” categories in Windows Phone, but suffers from poor sorting. It seems more likely that we can solve the sorting problem than the discoverability problem. So, as with Ubuntu for PC, Ubuntu Phone will have “System Settings”, not just “Settings”. Applications will be responsible for presenting their own settings.

Second, there is a tension between categorizing settings, and promoting frequent or urgently used settings. Categorizing by itself is tricky enough: different people might look for the same setting in different places. (For example, iOS sometimes mirrors subcategories of settings inside multiple categories.) A search function may help, but is not a complete answer, because people still need to know what settings are available in the first place. Categorization becomes even trickier when trying to provide quick access to settings like flight mode or orientation lock. Indicators at the top of the screen may help with this, by providing quick access to frequently used functions, like they do on Ubuntu for PC.

Third, it can be useful to reveal current state of settings as part of the navigation to those settings. This is usually done in text, with summary values, but an icon could work too. For example, a Bluetooth settings icon might be dull when Bluetooth is off, bright when it is on, and have an emblem when it is paired to any device.

User journeys

Two user journeys influenced the design of the System Settings interface.

The primary journey is someone wanting to solve a problem. Maybe their Internet connection is not working. Maybe they’re wondering if they can save battery. Maybe a cabin attendant has asked them to put the phone into flight mode. Maybe a friend has been messing around with their phone and they want to stop it from happening again. This person usually will be in a hurry, and sometimes irritated. They’ll want to get in and out as quickly as possible.

The secondary journey is an adventurous new owner, starting out with their phone, wanting to explore what it is capable of. They have more time to read explanations, and to explore cross-references between categories.

Designing the overview

Next, I sketched out nine possible layouts for the overview screen — the first thing people would see when they entered System Settings.

Selecting the most promising elements from each of the nine layouts, I passed them on to one of our visual designers, Rosie Zhu. She produced mockups of three possibilities, and with help from Marcus Haslam we decided on one final layout.

The design promotes frequently- and urgently-needed settings at the top, categorizes other settings compactly, and places bureaucratic stuff (“About This Phone” and “Reset Phone”) right at the bottom.

This is far from a final mockup. We need to finalize the icon style, and fine-tune control sizes, use of color, use of lines, and so on. But the basic layout is in place for engineers to start work. (Contact Sebastien Bacher if you’d like to help out with the code.)

Designing individual screens

Meanwhile, I have been busy designing individual settings screens. This has helped reveal missing controls in the UI toolkit, so they can be implemented for app developers to use them too.

Links to designs for the individual screens, as well as the design for the overview screen, are on the System Settings wiki page. Your feedback on any of the designs is welcome, either here, or on the ubuntu-phone@ mailing list.

For several years, Randall Ross has been now on the war path about the structure of Ubuntu LoCo teams.

However, everything that is raised in his post seems nothing more than a storm in the teapot.

As can be read from Jono's blog, Brainstorm has basically effectively been discontinued. It strikes odd, that this decision was made seemingly so rapidly, and it seems without a lot of community input, despite it was a community tool.

Of particular interest seems to be the reasons given for retiring this tool.

Time does fly, and we’re alread on the last day of the Ubuntu Developer Summit. Lots of content covered and still lots of interesting discussions to be had. We’re thrilled to bring you the summary on what’s on today on the App Development track.

Here’s the list of app development sessions for today at UDS:

• At 14:00 UTC: App Development Roundtable
• At 14:00 UTC: SDK UI Toolkit Responsive Layouting
• At 15:05 UTC: Core Apps plans for 13.10
• At 15:05 UTC: Contact Service for Ubuntu Touch
• At 16:05 UTC: LoCo Team Coding Challenge
• At 16:05 UTC: Refocus the Ubuntu App Developer site to go mobile
• At 18:05 UTC: Building a set tutorials for App Developers
• At 19:00 UTC: Closing Plenary and Track Summaries

Hope to see you there!

If you did keep an eye on Planet Ubuntu, you would absolutely notice the series of “People behind Ubuntu Quality” series, where QA community members like me, Sergio, Jackson, Javier and Carla were interviewed by Nicholas Skaggs. If you never read it before, you will find it in Nicholas’ Orange Notebook.

Anyways, I myself started another series of interviews. I will be interviewing Canonical QA people from all over the world, who spends everyday making sure Ubuntu is of high quality. These interviews are to pay tribute to them, and thank them for making Ubuntu a nice product. As to echo Nicholas’ series, I shall conspciously name it “People behind Canonical Quality”.

Expect to see the first interview coming up by tomorrow or Saturday!

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!

The Ubuntu Community Council is happy to announce the availability of discounts from Gandi to Ubuntu Members! Members will be granted E rates for domains and partner rates for cloud hosting (-50% from public price).

To redeem this benefit, members should send an email to non-profit@gandi.net from their @ubuntu.com email address that includes:

• A Gandi handle (see here to create a new one if requred)
• The currency they use (Euro, USD or GBP are available)

Huge thanks to the kind folks at Gandi for offering this benefit to our members, and also thanks to community member Benjamin Kerensa for reaching out to them to request it.

Elizabeth Krumbach Joseph, on behalf of the Ubuntu Community Council

The Ubuntu Community Council is happy to announce the availability of discounts from Gandi to Ubuntu Members! Members will be granted E rates for domains and partner rates for cloud hosting (-50% from public price).

To redeem this benefit, members should send an email to non-profit@gandi.net from their @ubuntu.com email address that includes:

• A Gandi handle (see here to create a new one if requred)
• The currency they use (Euro, USD or GBP are available)

Huge thanks to the kind folks at Gandi for offering this benefit to our members, and also thanks to community member Benjamin Kerensa for reaching out to them to request it.

Elizabeth Krumbach Joseph, on behalf of the Ubuntu Community Council

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.

Earlier this week the techboard asked what we should do with Brainstorm. Having been involved with Brainstorm since almost the beginning, I felt it appropriate to handle how we would deal with it since no one wants to be unpopular, except for me of course. The TLDR is that Dell launched IdeaStorm and of course people thought this would be a great idea for OSS.

The very first thing I noticed when the idea of shutting it down was a fundamental misunderstanding of what Brainstorm is and is not. So let me be clear here:

Brainstorm was never about user-driven voting for what goes into Ubuntu.

Brainstorm was about communicating ideas that the user base were interested to Ubuntu, and at THAT it did a pretty decent job. Every cycle the tech board was taking in the top ideas and responding to them. Most of these ideas were pretty obvious. Ubuntu developers don’t need anyone to remind me that Ubuntu needs to do a better job at hardware support. We know and deal with these issues every day.

Brainstorm was about engaging developers with users, and here’s why that doesn’t work anymore:

• Just go to UDS. It’s virtual, anyone can join without caring about travel expenses, just talk to developers directly.
• Be involved in projects you care about; there’s mailing lists and tons of feedback options for developers.
• It takes a reasonably intelligent person about 10 seconds to come up with 10,000 years of development work that will never be accomplished with the resources we have.
• Go do stuff, the more you do, the more you get a say.
• At the end of the day I’m swimming in great ideas. I don’t need great ideas, I need people willing to make great ideas a reality.

It seems that a great number of people think that Brainstorm is all about “wish-driven development” - the idea that you will come up with an awesome idea and then a team of developers will go do that for you and deliver what you want. Unfortunately that is not how it works. The only way you will ever get things done is if you do the work alongside other people. The currency of Open Source is the amount of work you’re willing to put into it. And while some people are saying that they’ll move to other distros or give up on Ubuntu because “no one listens to me” are in for a rude awakening when they realize that no open source project is driven by webpoll results.

Some people have equated the “age of Unity” as the reason as to why Brainstorm is failing, but I don’t think so, the site was flailing long before then. I might be seemingly overly negative, and that’s not my intent. In fact the barrier to get involved with Ubuntu is lower than ever.

The ironic bit so far is that the amount of complaints about Brainstorm shutting down far outnumber the amount of volunteers who have laid aside a ton of their own personal time to do the work to make the site succeed. That tells me a few things. First of all, the amount of people who will complain that things don’t work like they want them to is high. The amount of people willing to work on Ubuntu to fix these problems is relatively low.

So is Brainstorm a failure? Probably. I think we learned a bunch of things. No other OS has tried this before. Sure, they say Windows 7 was my idea, but you know that’s made up. I like that we tried, shrug.

I like that we now do design and user-feedback based improvements into Unity. Some people don’t like that. Some people don’t like that we do test driven development either. To each their own. Anyway Brainstorm was never my idea, it was a community idea that seemed to make sense at the time and whose course has run. Let’s torpedo the unrealistic idea that webpolls run an operating system and just people wired into making an operating system. Want to make a difference? Here’s the schedule for the last day of UDS if you want to get involved.

I love maps — something that became clear to me when I was looking at the tag cloud of my bookmarks a few years back. One of my favorite blogs (now a book) is Frank Jabobs’ Strange Maps.

So it’s no coincidence that a number of my favorite MIT Mystery Hunt puzzles are map based. Trying to connect the two worlds, I sent Jacobs a write-up of the hunt and of a particularly strange sound-based map puzzle called White Noise that I worked with Don Armstrong to solve in the 2006 hunt. While I wasn’t paying attention, Jacobs did a very nice writeup of my writeup of the puzzle for Strange Maps!

There has been much teeth gnashing about the removal of the ‘Community’ link from the top of the ubuntu.com site. As a member of the Ubuntu Community Council I have tried to gather my thoughts before blogging about this. Recently, I read an article that got me rather upset.

The Community Link:
First I want to layout my thoughts on the primary issue of the ‘Community’ link being moved to the footer. It is my opinion that the importance of the change is elevated by the recent mis-communications between Canonical and the community. Some have pointed out that promises have been made, but not kept. I can categorically state that I, as a member of the Community Council, have seen an improved effort from Canonical to inform the Community Council. As an example we were informed prior to the public discussion of the suggestion ‘click packages’. From my perspective ‘click packages’ are much more likely to have an impact on Ubuntu than the placement of the ‘Community’ link.

There is a UDS session scheduled to discuss this and if you are interested I would suggest you attend. In that blueprint I made a suggestion that some data on page views should be looked at. Peter has posted the following:

AFTER Apr 15, 2013-May 9, 2013 compare to BEFORE Mar 21, 2013-Apr 14, 2013

Pageviews
-32.69%
90,700 vs 134,740

Unique Pageviews
-31.54%
76,853 vs 112,261

Avg. Time on Page
33.75%
00:01:24 vs 00:01:03

Entrances
2.68%
52,548 vs 51,174

Bounce Rate %
-1.04%
60.54% vs 61.17%

it appears to be a 1/3 drop-off in page views, with a 1/3 equal increase in time on page.

With this data it would appear that there is a drop off and the traffic to the page has decreased. There is a session at UDS to discuss this and if it is important to you I would attend the session and subscribe to the blueprint.

The Community Response:
I want to clearly indicate that this IS NOT aimed at the broad community, but those that historically over-react in a dramatic negative fashion. There have been multiple instances of community members invoking the Hitler meme in regards to Mark Shuttleworth and the Nazi party in regards to Canonical. I can not fathom any rational person invoking this imagery in regards to Mark or Canonical. In all my dealings with Mark he has been respectful, thoughtful and compassionate. When I analyze what Mark values it is the success of Ubuntu. He understands that difficult decisions will need to be made for that to happen. When the Code of Conduct was revised it was to help ensure that the pitfalls other open source projects have been derailed by can be avoided by the Ubuntu project. I will echo that I have yet to work with a Canonical employee who has not been willing to listen to feedback or been disrespectful.

As a community member I find such attacks a violation of the Code of Conduct and as a person I find the comparison to be completely unacceptable. It is one thing to disagree respectfully, but making comparison’s to Hitler or the Nazi party is not acceptable.

Yesterday in the Ubuntu Community Roundtable session and idea was put forth by Jono Bacon to remove the term ‘approved’ from the loco team lexicon. It was further suggested to remove the boundary restrictions currently in place. These ideas have been floating around in the community since, my first UDS, UDS-N in Orlando Florida.

For me one of the first things that I notice is that there are already exceptions to the ‘rules’. For example, there are city teams (Chicago and Dallas), but new city based teams are not allowed. I am in New York State so I might be a bit biased, but I would personally think having an Ubuntu New York City team would be good thing. New York City is the 8th largest city (population) in the world. It is also 342 mile from where I live so there is little chance that people from my area would travel there or vice-versa. In my city we actually have two Linux user groups; one at a prestigious technical university and one for the general community. The technical university focuses more on development, and the general community group on specific implementations of applications and general use. Two different groups with two different needs. Both groups exist and thrive separately as well as cooperate when interests overlap.

I want to be clear; I do not think this should be forced, nor do I think it should be something that requires approval.

It is my personal opinion that the challenges that face teams are each unique; they will vary based on culture, language, geographic distance, population density and other variables. Ubuntu users should be able to choose how to organize themselves without artificial organizational boundaries placed on them.

From my understanding the original structure was put in place to control the flow of resources like CDs, conference packs, etc. There will still be a need for some control in regards to resources, and this is an issue that must be discussed and worked out. I feel strongly that this need should not inhibit the freedom of Ubuntu users to organize and grow in a way that best suits the needs of their area or group.

If you are interested in having input on this discussion please attend the UDS session this Thursday and subscribe to the blueprint.