As I mentioned last week we’ve started a campaign for helping people get started on fixing bitesize bugs in Unity. Jono blogged about this as well. As it turns up, we’ve got our first bitesize contributor today!

Jamal Fanaian has fixed Bug #683241: Recycle bin icon is empty when there are items in the bin. Jamal is a developer working on Flickr. He passes along “I love Ubuntu and open source software, so my only real hobby has become working on open soruce. Other than that, I like playing with hardware, although recently I have found less time to do so.”

Basically the trash icon showed up empty even if you had stuff in it. Jamal first grabbed the code, then fixed the bug, and then pushed it to launchpad.

Photo by brittav.

From there he submitted it for review in Launchpad. In this specific example Alex Launi has started the review process. Now we’re cooking. So, how can you get started? First let’s have a look at the list and look at the progress people have made this week.

• Bug 677577 – Clicking on a launcher icon does not raise most recent window
- Fixed!
• Bug 646740 – indicators are mis-aligned
• Bug 683241 – Recycle bin icon is empty when there are items in the bin
- Fixed!
• Bug 683466 – There are 2 Quit menu options in Quicklist
• Bug 599716 – having “unity –replace” would be nice
• Bug 681428 – scrolling does not work on the sound menu – Music lovers everywhere would appreciate a fix here.

New bitesize bugs this week (they might be older bugs but new to bitesize):

• Bug 686591 – unity-panel-service should be autorestarted by unity when crashing – A fix for this one would be most welcome, as it’s annoying!
• Bug 677594 – Workspace switcher useless with one workspace
- Armor Nick seems to be doing the initial investigation here.
• Bug 686182 – Unity launchers run multiple copies of program if clicked multiple times before the program loads
• Bug 599716 – having an unity binary would be nice

Getting Involved: Instructions for getting started are available here 

For more information check out the wiki page: https://wiki.ubuntu.com/Unity/Bitesize

Today we published our final Shot Of Jaq. You can listen to it here.

Shot Of Jaq was our experiment into whether podcasting could be turned on it’s head a little and instead of being a long show (such as what we did with LugRadio, could be a short, sharp burst of content to start the discussion. We did this with Shot Of Jaq for nine months, put out around 70 shows on a twice-weekly basis, and had over 3000 comments as part of the discussions.

Although Shot Of Jaq had a fairly short life-span, I am proud of what we achieved with it. I feel like the format worked, and our final show which we released today talks about some of the lessons learned in a hope that others will continue the shotcasting format.

As for why we are stopping Shot Of Jaq? Well, Aq and are simply too busy with other things (such as Severed Fifth on my part) and we both have hectic work lives. We didn’t want the quality of the show to suffer, so we figured now was a good time to call it a day.

Thanks to everyone who was so supportive of the show!

As I mentioned last week, I am now doing my At Home With Jono Bacon videocast in a regular weekly slot at 11am Pacific / 2pm Eastern / 6pm UTC. In every show I provide a Q+A section but I am keen to cover tutorial topics and overviews of key elements involved in Ubuntu and general community management.

To ensure this is as transparent as possible, I have created this wiki page where you folks can go and suggest topics for me to cover in the show. Go and add your ideas and while I can’t guarentee I will cover them all, I do my best to get through them.

Today I added a new feature that helps you tie online documentation with a snippet. So, if you take a look at this screenshot:

You can see that in the snippet information (which I have changed the layout on a little) there are now a couple of link buttons. If you click on one of the buttons it will load up the documentation in your web browser. This documentation is added to the snippet like this:

[SNIPPET_DOCS: http://www.website.com, http://www.anothersite.com]

Acire will then grab the title of those sites and display the buttons underneath the snippet. This is a great way of including a link to the manual page for a given feature, tutorial links or anything else with a snippet. This is just a first cut of the feature and I am sure there some bugs to irk out, so merge proposals are welcome.

In addition to this I added some additional fixes and features:

• Alphabetized Lists – the list of categories in Acire and the list of snippets in each category has now been alphabetized which makes navigating available snippets much easier.
• HIG improvements – thanks to Matthew Pirocchi fo contributing a branch for helping Acire to fit in with the GNOME HIG better. The changes are subtle but really sleek.
• Number of snippets – the number of snippets that are currently available are now shown on the status bar.
• Link to how to add snippets – Acire is nothing without python-snippets, so I added a link in the Help menu to this page which explains how people can contribute snippets.

The python-snippets project which provides the library of snippets that Acire uses has been seeing some wonderful contributions across a range of categories. Here is a quick screenie showing the range of categories that we have snippets in now:

So, I am planning on doing a little more bug-fixing and then rolling a 0.5 release of Acire.

Presenting The Opportunistic Developer Vision

On Wednesday 24th Feb at 11am / 2pm EST / 7pm UTC/GMT I will be giving the talk that I delivered this past weekend at SCALE in LA in which I talk about the work going on in the Ubuntu community to embrace Opportunistic Developers in writing awesome free software apps. If you are curious about all this blathering about opportunistic developers from me, be sure to tune in and check it out. Tune in here.

Ubuntu Opportunistic Developer Week

A few weeks ago I announced the plan to put together Ubuntu Opportunistic Developer Week: a week of IRC tuition sessions aimed at helping opportunistic developers scratch their itches and write fun and useful programs using our awesome platform. The week takes place from 1st – 6th March 2010.

The response so far to the call for sessions has been fantastic, and we already have the following sessions scheduled, all visible from the timetable for the week:

• Welcome! Ubuntu For Opportunistic Developers – Jono Bacon
• Gooey Graphics with GooCanvas – Rick Spencer
• Testdrive – DustinKirkland
• CouchDB support in your app with DesktopCouch – Stuart Langridge
• Creating stunning interfaces with Cairo – Laszlo Pandy
• Hot rodding your app for translations support – David Planella
• Creating a PyKDE app – Rich Johnson
• Creating an application from scratch with Quickly – Rick Spencer
• Microblog from your app with the Gwibber API – Ken VanDine
• What’s new in Quickly 0.4 – Didier Roche
• Learning through examples with Acire and Python-Snippets – Jono Bacon
• Building in Application Indicator support – Sense Hofstede
• Writing a Rhythmbox plug-in – Stuart Langridge
• Create games with PyGame – Rick Spencer
• Write Beautiful Code (and Maintain it Beautifully) – rockstar
• Using GTK+ signals in Python – Sense Hofstede
• Integrated development workflow with Ground Control – Martin Owens
• Building multimedia into your app with GStreamer – Laszlo Pandy
• Speed your development with quickly.widgets – Rick Spencer
• Web browsing and rapid UI with WebKit – Ryan Paul

Each of these sessions is designed to give you a taste of the topic and get you up and running, enough to be productive and start exploring the features of the tool being discussed. In addition to this we will have a series of showcase sessions:

• SHOWCASE: Gwibber – Ken VanDine
• SHOWCASE: Lernid – Jono Bacon
• SHOWCASE: Photobomb – Rick Spencer

These sessions explain the story behind the app: talking about which tools, modules and technology that was used to put these apps together and what challenges were solved. This is a great way to learn more about tools available for opportunistic developers so that when you need to do something, you know which tool to reach out for.

All of this awesome content is best experienced using Lernid. Expect a new Lernid packaged and ready for the week of opportunistic goodness. If you would prefer to use a normal IRC client, just join #ubuntu-classroom and #ubuntu-classroom-chat to join in the fun.

Introduction To Python Tuition Sessions

Now, many of you will be entirely new to Python and entirely new to coding. To give you folks a head start before Ubuntu Opportunistic Developer Week kicks off, Rick Spencer from the desktop team will be running some beginners Python tuition sessions on the Thursday before Ubuntu Opportunistic Developer Week:

• Thu 25th Feb 2010 – 15.00 UTC – Ubuntu Opp Dev Week Prep: Intro to Python for total beginners – Rick Spencer
• Thu 25th Feb 2010 – 16.00 UTC – Ubuntu Opp Dev Week Prep: Intro to Python for programmers – Rick Spencer

This is a great way of getting your opportunistic development kickstarted!

Again, this awesome content is best experienced using Lernid. If you would prefer to use a normal IRC client, just join #ubuntu-classroom and #ubuntu-classroom-chat to join in the fun.

Rock and opportunistic roll, my friends.

Fun Apps And Hacking Parties

With an awesome week of opportunistic developer learning ahead of us, I was keen to put together some sessions where you good folks can just hack on fun projects in the same room, ask each other questions and more. As such, at the end of each Opportunistic Developer Week day, there will be a a series of parties. These include:

• Mon 1st March 2010 – 21.00 – 23.00UTC – Hacking Party – Work on your app together, ask/answer questions and have fun together!
• Tues 2nd March 2010 – 21.00 – 23.00UTC – Hacking Party – Work on your app together, ask/answer questions and have fun together!
• Wed 3rd March 2010 – 21.00 – 23.00UTC – Hacking Party – Work on your app together, ask/answer questions and have fun together!
• Thu 4th March 2010 – 21.00 – 23.00UTC – Snippets Party – Join us and create Python snippets!\
• Fri 5th March 2010 – 21.00 – 23.00UTC – Hacking Party – Work on your app together, ask/answer questions and have fun together!

This is an awesome opportunity to get together and make something fun. So, I have a challenge for you good folks: before we start next week, think of a fun app to focus on writing next week. Pick something that will do something useful for you and something not too large and comprehensive (e.g. don’t pick a word processor or spreadsheet!).

The Place To Be: #ubuntu-app-devel

As part of building an awesome community and platform for opportunistic developers, I created #ubuntu-app-devel on Freenode and we have a great group of enthusiastic developers in there who can answer your questions and help you get started. Join us and join in hte fun!

Today we are proud to announce the schedule for the next Ubuntu Open Week, which takes place from the 2nd – 6th November 2009.

Ubuntu Open Week is a week of free live online tuition and Q+A sessions that are provided on a range of topics by many of the movers and shakers in out community. If you are interested in getting involved in the Ubuntu community, this is an incredible opportunity to learn many of the skills involved, meet many of our contributors and just have a great time!

The way the sessions work is pretty simple, and everything is explained here. You simply join two discussion channels, one in which you watch the session leader deliver a session and the other to ask questions in. This year we even have a web based interface to the sessions, so it is easier than ever to get involved!

The schedule for Ubuntu Open Week is looking incredible:

This schedule may change since I have published this blog entry. You can find the latest schedule here.

The schedule is also available in iCalendar (ics) format, subscribe to the calendar using Google Calendar or Evolution.

If you use identi.ca, you can also subscribe to @udscommunity to be informed whenever a new Open Week is about to begin.

Note: For help on time equivalents around the world, visit Time and Date World Clock, and specifically for the equivalent of 15:00 UTC see 15:00 UTC around the world.

This is an fantastic opportunity to welcome new members to our incredible community, and I would like to encourage everyone to spread the word about Ubuntu Open Week so that the opportunity is open to as many people as possible: do go and blog, tweet, dent and otherwise spread the word!

Finally, thanks to Jorge Castro and Amber Graner for helping to put together the event and to all of our session leaders who have committed to running sessions. Rock and roll, my friends, rock and roll.

Today I turn 30.

It seems everyone has an opinion about what happens when you turn 30. Sharing my news of the imminent event with friends would usually result in sarky mutterings of “it’s all downhill from here, boyo“, and affirmations that hangovers feel worse, bones ache more, you get tired quicker and find yourself shouting at kids to get off your lawn. Bob Hope seemed to sum up this cornucopia of codgerly cantankerousness with “middle age is when you still believe you’ll feel better in the morning“. Bugger, that doesn’t sound very inspiring.

Well, screw that.

Don’t get me wrong: I am comfortable with the opportunities and limitations before me. I realize that it is unlikely that I am going to headline Wacken any time soon, I am probably not going to be as fast a drummer as I could, and I am going to have to shelve that plan for an 80′s perm.

But y’know what, life hasn’t changed that much. I still love my wife, family and friends. I love free software, metal, partying, working on interesting projects, having new experiences and supping coffee. I am still a sucker for wikipedia, dogs, PS3 and random trivia, and I still say community too much.

For all the perceived downsides of hitting the big three-oh, there are up-sides though. A little while back I was having a good ‘ol chinwag with Terri Molini from Sun and I shared with her how my perspectives have changed in recent years. I have been re-assessing old assumptions and looking at them from a new perspective, throwing away old expectations and ideas and approaching them from a new angle based on new experiences. When I shared this she said “how old are you?“, to which I responded “30 in a few months“, and she said “yep, that pretty much happens at your age“.

She ain’t wrong. In the last year I have felt a renewed sense of perspective in approaching my work and other aspects of my life, and this has helped me to understand the phases we go through as we get older and how we respond and react to things. I suspect…this is what happens when we grow up.

So, as I hit 30 I am entering middle-age actually a little excited.

Before I wrap up, I want to thank those of you who have generously bought me something from my Amazon Wishlist. I have received Queen – Live at Wembley Stadium DVD and The Daily Show with Jon Stewart Presents America (The Book) Teacher’s Edition: A Citizen’s Guide to Democracy Inaction by Jon Stewart – thanks so much, folks, I really appreciate your generosity!

Right, I am going to tell those bloody kids to get off my lawn…

Quite some time ago, we set ourselves up with the job of improving how we work with upstreams in a range of areas. To do this we hired Jorge to implement this work, and we decided to focus on bugs as our first action area. When trying to improve the relationship between two people, areas, or things, it is important to first define the mechanics of interaction. When thinking about the mechanics of interaction between Open Source projects, bugs offer a really exciting opportunity. Bugs are not only a common language between Open Source projects, but they also have a broadly similar schema – bug summary, description, state, associated patches, assignment etc. In a world with thousands of Open Source projects, bugs offer an interesting means of defining the connections between the thousands of dots. It is this kind of interconnected data that can be interesting in community improvement projects such as this.

Before we could begin improving our bug story though, we needed to understand more about the problem. Sure, we had ideas about how we could improve bug workflow, but the reality was that we were really just clutching at ideas and assumptions – we simply did not know enough about bug culture and the different approaches to bugs taken by upstream projects. Our first step was in understanding upstream bug workflow better. One key question here was:- exactly how can upstream projects make best use of our bugs?

To explain better, let me summarise the problem. Imagine you are using Ubuntu and something goes wrong. You suspect it is a bug, so you click Help->Report a Problem and you file a bug. We now have a bug in Launchpad in the Ubuntu project. Now, this bug is reasonably likely to actually exist in an upstream project. Imagine the bug was present in the GEdit text editor that we ship with Ubuntu – there is a distinct possibility that this bug is a bug in GEdit itself as opposed to a bug that we introduced while we build Ubuntu. It therefore makes sense to ensure that this distinction is noted, and to make this easier, we have a rather cool feature in Launchpad in which we can link an Ubuntu bug to a bug in an upstream bug tracker. In this particular example, if we found a bug in GEdit in Ubuntu and the bug is present in the upstream GEdit bug tracker, we can link the two bugs together. This link is also called a watch. This means that bug status changes in the upstream bug tracker will be reflected in the Ubuntu bug inside Launchpad. The goal here is that there should be one set of bug information that can be accessed from the upstream bug tracker and in Launchpad, and the two should be synced; multiple eyes on the same bug. Nice.

There were however two specific unknowns:

• Firstly, we had an suspicion that not that many Ubuntu bugs were getting linked to the upstream bug tracker. We had no fixed idea of this, but it was a hunch that we needed to quantify.
• Secondly, if we do link a bug upstream, we had no firm idea how useful an upstream actually find our bug data. Our discussions suggested very mixed reactions – a small project is likely to have a very different perspective on bugs than a large project. Just think about this in purely quantitative states – a small project will likely get fewer bugs, and these bugs can probably be dealt with by a small collection of volunteers. This is unlikely to scale to something like the Linux kernel or OpenOffice.org.

To help understand the latter problem more, we conducted an upstream survey, which some of you may have filled in. Surveys are a funny old beast, and a general issue survey can sometimes not yield particularly useful results, so we issued the same survey twice – first to an invitation-only range of upstreams who we knew would provide some objective commentary, and secondly we opened it up to anyone. A key element in this survey was asking about perspectives on bug workflow. We got a decent set of results (it is recognised in research that the magic number is 24 sets of results, so you don’t need hundreds of participants) and we assessed each set of results as well as combining the surveys. In addition to this we sat down and assessed other areas of bug workflow – watching how Ubuntu developers fix bugs and taking notes, developing bug jams further and improving our bug documentation.

But anyway, back to the upstream report specifically…

With every project that I approve on the community team at Canonical I want to see metrics. This is something we apply across the board. I have to admit, I am a bit of a graphing obsessive; it is interesting which conclusions and patterns that you can identify when you track a set of data, and this is particularly interesting when you match your data to your initiatives in the time-line. Of course, not everything can be graphed, but a lot can, and it really helps us build our community more effectively.

In terms of this project, I was keen to see graphs that show the number of upstream bug linkages going on, the total number of open vs. upstream bugs and how many bugs are fixed elsewhere. We could use these graphs to determine our progress in improving our bug workflow, but this was not enough – we also needed raw data about which projects needed the most focus. Which projects were struggling the most with bug figures? Which projects were not forwarding bugs upstream? Which projects didn’t have an upstream bug tracker registered in Launchpad? We had all the answers to these questions in Launchpad, but no means of gathering them. To fix this, we created the Ubuntu Upstream Report.

The Ubuntu Upstream Report that has hit beta today is the result of us sitting down and determining exactly what kind of data we wanted to know about upstream bug culture, and presenting this data in a means that helps us focus our efforts more effectively. The most critical focus with the report was to identify the Top 100 projects that need the most assistance with bug work – these projects are organised by open bug counts. We could then produce figures for each of these projects to identify how many upstream tasks are registered and how many of these tasks are links to upstream bugs. Combining these figures, it gives us an idea which projects are sucking at linking to upstream bugs.

With this kind of data available, it gives us the ability to drive our other initiatives that we have been building such as Bug Jams and 5-A-Day. In fact, 5-A-Day is a key driver in how we can improve our bug linking story. Right now you can look at a project on the upstream report and click the number in the far right column to provide a list of bugs that have upstream tasks but no upstream link. A bug with an upstream task but no upstream link is likely to be considered an upstream bug, but it really needs the link to be made. All you need to do is find the upstream bug in the upstream bug tracker and link to it in the Ubuntu bug in Launchpad; this is a really useful and simple contribution to your 5-A-Day – nail five of these suckers a day, and you are flying. How cool is that – we can let our incredible 5-A-Day community know exactly what easily needs fixing in the Top 100 projects that need attention. That is pure class in a glass.

This is just one of a number of projects that we are working on to improve how we work with other entities in the Open Source world. We are really, really keen to not only build a strong and effective Ubuntu community, but to also ensure we can work as effectively with other projects and contributors too. Sure, we have some things to fix, but I am determined for us to resolve these problems and really drive through new opportunities to improve how we work together. This is one element in how we want to improve our relations with upstreams, so stay tuned for more as we develop our ideas.