Planet ubuntu-uk

I just wanted to provide a quick update on how the team is doing on our set of commitments in the 12.04 cycle. Feel free to ask questions in the comments.

In terms of general team progress, this is how our burndown chart looks today:

I asked each of the guys on the team to follow up with their respective community members to start moving the needle on those work items. As such, if you committed to something in 12.04 for our team’s burndown, expect Jorge, Daniel, or David to come knocking on your door soon.

With Nick and Michael joining the team recently, their work is not reflected in this burndown – their work will appear in the 12.10 burndown.

Developer Growth

Daniel’s core focus in this cycle is developer growth. The first step here is ensuring that our developer processes are working effectively. Over the holiday period the sponsorship queue got a little out of shape, so I asked Daniel to work with the patch pilots to get this back on track. Good progress is being made:

You can see how the queue is falling back down at the end of the graph since Daniel started hammering on this over the last few weeks. Thanks to all the patch pilots for their hard work.

Daniel has also been fixing up some metrics so we can track this work more effectively, and putting together a developer outreach team to provide a more personal level of support to get developers through the process. He will be speaking more about this in the coming weeks.

Cloud and Juju

Jorge is focused on growing the Juju charming community and is making great progress. A tour of events is planned and Jorge has a hit-list of upstream projects which he is focusing on to get charms put together for. We are seeing good progress on this list and I am confident Jorge will hit his goals in this cycle.

Juju really is awesome. You should check it out.

App Developers

David has been focusing on app developers in this cycle. A first chunk of work here is helping the App Review Board to get in shape. The ARB has a large queue of content to get through, so in Budapest we sat down and dissected the ARB process and made a bunch of optimizations. David has been coordinating with the team to help coordinate this work, and we are seeing progress happening.

We have recently seen three lenses get through the ARB, and David is going to be starting a regular cadence of queue reviews to keep the ball rolling. Thanks to the ARB for all your contributions.

David originally planned a Phase II set of additions to developer.ubuntu.com, but with some re-structuring from the Canonical web team, those plans have been put on hold a little. Instead d.u.c is now being put into maintenance mode and we identified a set of things that need fixing (particularly on the publishing side), and David is coordinating those changes.

The next chunk of work will be outreach to grow our app developer community. Stay tuned for more…and an up-coming competition…

Upstream Relations

Michael is the new upstream community coordinator, and will be focusing on Unity in particular as he gets started. I have asked him to first work with the Desktop Experience team to help get their community merge proposals in shape. There are a number of branches that have been sitting around for a while, and Michael is coordinating a patch pilot scheme to ensure these get reviewed regularly. We expect to see this in place over the next week.

Michael has also been performing an assessment of Mozilla’s SUMO for a potential solution for help in Ubuntu. He has put together an extensive report and a test instance to play with and he will be working with the docs team to continue assessing this as a solution. I am excited to see what work happens here.

Finally, next week we will be putting together an upstream target list for Michael to reach out to to start engaging app authors more effectively around our technology. I am excited to see this work progressing.

…oh, and one other thing: Michael is working with Didier to merge Singlet into Quickly. This should make creating Unity lenses a piece of cake. Bring it!

QA

Finally, the latest addition to the team has been Nick Skaggs. Nick has been working with the QA around a few core pieces of work:

• Getting our manual test infrastructure in place. We are going to be piloting Case Conductor as a solution that will fit alongside Jenkins.
• Consolidating our QA community teams. Nick is evaluating our current QA on-ramp and then we will put together a proposal for bringing more efficiencies and consistency to the QA community.
• Building a take-and-bake testing process so Ubuntu Engineering can reach out to Nick to facilitate community testing more effectively.

The former two items will take time to put in place, but the latter item should be in place in the next week. As such, you should see a regular stream of testing campaigns driven by Nick in 12.04. Be sure to keep an eye on his blog.

. . .

Of course, there are lots of other things going on, but these summarize some of the key themes.

The Ubuntu Developer Summit (UDS) is the most important event in the Ubuntu calendar. It is where we get together to discuss, design, and plan the next version of Ubuntu; in this case the Ubuntu 12.10 release.

The next UDS takes place at The Oakland Marriott City Center, Oakland, California, USA from the 7th – 11th May 2012. You can find out more about why UDS is interesting from the perspective of a member of the community, an upstream contributor, and a vendor. We also welcome everyone to participate remotely if you can’t attend the event in person. More more details on how to get there, see this page.

At the heart of a great UDS is a diverse group of attendees who can bring their experience and expertise to the discussions. You don’t have to be technical, or be a programmer or packager to attend – UDS is open to everyone (including non-Ubuntu folks) and free to attend. We encourage everyone with an interest in Ubuntu to attend.

Sponsorship

For every UDS Canonical sponsors the hotel and accommodation of a set of community members to ensure they are free to contribute and bring value to the discussions. We have a limited budget so we can’t sponsor everyone, but we are always keen to have a capable and diverse group to sponsor:

• We strive to support community members who are actively involved in Ubuntu and who are providing significant and sustained contributions to the Ubuntu project.
• We always welcome Upstream contributors who are bring value to Ubuntu indirectly via active participation in their upstream project, but who are keen to see quality support for that upstream in Ubuntu.
• Contributors are willing to actively participate not only throughout the full Ubuntu Developer Summit week, but also following with active contributions throughout the release cycle.
• We are always keen to welcome members of the community who have never been to UDS before and are keen to participate and experience the event.
• You don’t have to provide technical contributions to apply – if you have participated in the areas of advocacy, documentation, testing, art, design etc, you are encouraged to apply.
• UDS is an event that encourages diversity – we welcome everyone to apply for sponsorship, irrespective of gender, race, impairment, technical expertise, or other factors.

If you are participating in the Ubuntu community, we would love you to apply for sponsorship. This is how it works:

1. You can apply for sponsorship by following these instructions. Apologies for the different forms you need to fill in – we are going to consolidate these forms at the next UDS. The deadline for submissions is Wed 22nd February 2012 so be sure to get yours in!
2. When the deadline is reached we will assess the applications and finalize who we will be able to sponsor.
3. You will then receive an email outlining whether we can sponsor you or not.

Simple! I look forward to seeing your applications, and seeing many of you in Oakland!

Today we announced the HUD that is landing in Unity. This is an awesome new feature. See Mark’s blog post, the coverage on PC Pro, and the interview with John Lea on OMG! Ubuntu!. Here is a video of the feature in action:

Can’t see it? See it here.

I wanted to point you folks at Nicholas’s blog post about how to test the HUD. You will need to be running Ubuntu 12.04 (which is still in development) to test.

We would like to encourage everyone to test so we can get this rock-solid for 12.04!

I am a pretty terrible programmer. Anyone who has read my code can see that. Unfortunately, I tend to have lots of ideas about how we can use technology in different ways, hence why I write some code. Examples of this have included Lernid, Acire, RaccoonShow, and Jokosher.

Fortunately (or unfortunately, depending on your view), I have had Python and GTK to serve my needs here. Python, with it’s awesome batteries-included range of facilities and GTK as a simple yet flexible toolkit has allowed me to create implementations of the ideas that I have dreamed of. I started using these tools many years ago, and they have always provided a simple and effective toolset for me.

My preferred toolset of choice. One day…

Having not written any code for a while, I got the itch this weekend to start writing the trophy helper app that I wrote about as part of the accomplishments system spec that I created with Stuart Langridge and Daniel Holbach. I thought this would be a good opportunity to brush up on my skills, given that PyGTK is dead and the new world is instead the GIR approach to GTK. In a nutshell, this is where the language bindings basically match the C API for GTK thus reducing the need for people to maintain different language bindings.

Of course, this is a good thing: less work for volunteers in maintaining multiple-language support for GTK and a consistent API is good. Unfortunately, I found getting started with this new world a little more complex than I imagined.

From reading the documentation it suggested that all I needed to do was to import Gtk from gi.repository and instead of creating widgets with gtk.<foo> that they would be Gtk.<foo>. The docs suggested a few other lexical adjustments, but not much more than that. There is even a pygi-convert.sh script that can convert older PyGTK code over to the new PyGI way. Unfortunately the script didn’t work for me, so I instead used it as a cheat-sheet for things that needed changing. Sadly, it seemed like some things were not covered in the script.

An example of this included when I was creating a ListStore. In PyGTK code I could add a gtk.gdk.Pixbuf to the ListStore for an icon, but I had a difficult time trying to figure out the new way to describe this. I tried Gtk.gdk.Pixbuf and Gtk.Gdk.Pixbuf but had no luck. Fortunately the awesome Ryan Lortie informed me that it needed to be GdkPixbuf.Pixbuf. Another example of this was gtk.SORT_ASCENDING in my original code and the new Gtk.SortType.ASCENDING in the new code. It seems like various functionality in GTK has been moved around and re-factored.

Unfortunately I could not find any documentation to help me with this. Sure, the C docs are available online, but I am not a C programmer; I am (in the most generous and understanding way) a Python programmer and where I previously had a pretty decent tutorial and reference guide to PyGTK, as a desktop app developer I no longer have these resources to help me. Even though I am not a fantastic programmer, I have written enough Python and GTK code to fumble my way through writing various apps, and if it stumped me as a relatively old hand, I wonder how a brand new developer would get on.

Pictured: old hand.

Now, this may sound a little critical, but it is not mean’t to be. I have tremendous respect for the GTK team, and I am hugely thankful to them for all their hard work. I am also thankful for the team that has worked on the GIR support so that multiple language support can be more efficiently provided. Thanks to all you folks for providing great tools that let a programming numpty such as myself be able to write Free Software.

I just wanted to share this because I feel like these tools are missing the final component: if we had a good solid set of reference documentation generated for each language (naturally, Python is the language I mainly care about), this would help novice and established developers use GTK more effectively. From my personal experience, my patience started wearing pretty thin when I felt like I didn’t have anywhere to find help as I navigated C documentation to try and figure out how the API fitted into my Python application. A good solid Python reference manual would have resolved this issue, and from what I understand, this could potentially be generated from the GIR files. Unfortunately, I don’t think I have the skills to help solve this problem, so I figured the best I could do was to share my story and see if anyone would be interested in helping to solve this problem.

If so, thanks in advance, and thanks again to the GTK team for all your hard work!

A little while back I mentioned that Nicholas Skaggs would be joining the Community Team at Canonical. Nick is now on board but is not an Ubuntu Member yet, so his blog is not appearing on Planet Ubuntu.

On his blog he will be talking about improving our QA infrastructure and documentation, building out manual test coverage, and growing a community of QA testers.

You can read his blog here. I am going to ask Nick to apply for Ubuntu Membership in a few months when he has provided a significant and sustained contribution, and then his blog will appear on Planet Ubuntu.

A little while back I blogged about an accomplishments system that Stuart Langridge and I designed when he came to visit a while back. The idea was simple: a de-centralized system in which we can easily define different types of accomplishments (e.g. filing a bug, submitting a patch, getting a patch sponsored, translating a string) and a means in which users can be rewarded trophies for these accomplishments as well as discovering new accomplishments and how they can be achieved.

The nice thing about the system we designed is that it is de-centralized, it uses Ubuntu One as a transport mechanism (which means we don’t have to build our own transport system and your trophies are visible across all your Ubuntu machines), and the system has a verification process to ensure that people can’t fake their community accomplishments.

I wrote this all up into a spec which you can find here.

We had an interesting session about this topic at UDS and Stuart put together a draft implementation which is at lp:~sil/+junk/libaccom-draft/. The implementation defines a set of sample accomplishments and provides a daemon that runs to maintain state on which accomplishments have been achieved and which are still yet to be completed. The system is neatly integrated into Ubuntu and accomplishments are displayed in a notify-osd bubble:

Stuart also wrote a small API (libaccomplishment) that client apps can use to query the system and present trophies achieved or those yet to be achieved. You can read more about this draft implementation here.

In the original spec there are two clients that would be in the system. A lens:

…and a helper app that is loaded when you click on a trophy in the lens which can provide more information about an accomplishment as well as showing the list of achieved accomplishments and those yet to achieve:

This weekend I decided to start writing this helper app (Michael Hall has expressed an interest in writing the lens). To get things rolling I wanted to display the list of trophies that have been accomplished. It looks like this so far:

This app is using the libaccomplishment API that Stuart provided in his draft implementation and this code could obviously used to develop the lens. There is obviously still lots to build into the app, but it provides a useful proof-of-concept for how it could work. This is a Quickly project and you can grab the code from lp:~jonobacon/junk/trophyinfo.

If you want to play with this, grab Stuart’s draft implementation (lp:~sil/+junk/libaccom-draft/) and run examples/demo.sh – this will start the daemon. You can then grab my branch (lp:~jonobacon/junk/trophyinfo) and run quickly run and see the trophies in the view.

Everything so far has been something of a proof of concept, but I wanted to see if anyone else was interested in participating. There are a number of things that we need to do:

• Stuart’s draft implementation needs extending, and he would like to find a new owner for it. Currently the API is simple but might need fleshing out further.
• The helper app here that I created a first cut of needs expanding and functionality added. We need to provide different ways of filtering the trophies, providing information about a specific trophy and how to achieve it, and the other features outlined in the spec.
• Each accomplishment has a script that is run to see if you achieved something (e.g. if you filed a bug in Launchpad). In the spec, when one of these scripts returns that you accomplished the task, it creates a trophy, and syncs it via Ubuntu One to a validation server which runs the same script to verify you really did achieve the accomplishment. This then signs the trophy which then syncs back to your machine. We need someone to build this verification service.
• We need to evaluate and extend the .accomplishment format to include documentation for how to achieve a trophy. I know Jim Campbell expressed an interest in working on this and I would love to encourage others to participate too.
• We need to create a library of Ubuntu Community accomplishments. Stuart’s draft implementation includes an example script for filing a bug. See the list of ideas that Daniel has been working on.

Anyone interested in taking part?

UPDATE

Since I posted this I have made a bunch of improvements to the helper app. This includes:

• The app now displays trophies achieved on the My Trophies page and those not yet achieved on the Opportunities page.
• Locked trophies (i.e. those that need another trophy to be accomplished before it can be) now use a different icon (we will need new icons for all of these, so I am using stock icons right now).
• Trophy/opportunities status is now updated with each page load which means that trophies are updated more dynamically.
• Double-clicking an opportunities will take you to the WebKit page to display info about it. I just need to update the .accomplishment scheme to provide more useful info.

I pushed all these updated to lp:~jonobacon/junk/trophyinfo if you want to play with it.

A week ago I flew to Budapest for an Ubuntu Engineering Team Rally. This is where we get the Ubuntu Engineers at Canonical and some other groups together for a week to work together, plan future work, have meetings and make progress on our existing commitments. It is in this week that I gather together with the guys on my team and we have the rare privilage of working together from the same office (we all work remotely usually).

Daniel Holbach, Jorge Castro, and David Planella were there, and we welcomed Nicholas Skaggs to the team who started his first day at Canonical on the first day of the Rally; a brave man! Unfortunately Michael Hall could not join us, but we had a tablet with his gleaning smiling face beaming into our room on Google+. He was there in spirit, if not physically.

Chris Farley was also there in spirit, if not physically.

We made some great progress and put quite a dent in our burn-down chart, but I wanted to summarize some of the work going on right now that might interest you:

• David, Daniel, and I spent quite some time opening up the ARB process and helping to get things back on track. We now have a flow of lenses coming through and the queue is looking in better shape. Thanks to the ARB for their work here and we will be continuing to build refinements into the process over the coming weeks.
• Nick got on-boarded at the event and met the QA team (Gema, John-Baptiste, Carlos, Pete etc). We discussed plans around putting in place a manual test case system (we will be piloting Case Conductor). We also centralized QA communication channels (#ubuntu-testing on Freenode) and Nick started cleaning up the documentation for how people participate in Ubuntu QA. I am excited by the progress happening here…more to come soon!
• Jorge made further progress on the charms front and we planned out a tour of events to run charm schools. Good progress is being made on upstream charm targets and awareness of Juju is growing.
• David and I discussed next steps for developer.ubuntu.com. Things will be on hold a little in this cycle due to the web team being re-assigned to other work. Instead we are fixing up chunks of developer.ubuntu.com, particularly around publishing apps and reference materials.
• Daniel (who just got back from an awesome holiday in Morocco) and I synced up on the sponsorship queue which has got a little out of shape recently, so Daniel is re-focusing on that over the coming week as well as building out the developer advisory group and identify prospective developers and providing 1-on-1 guidance to get them through the developer process.
• Michael is going to be putting in place a patch pilot scheme for the DX team to ensure community merge proposals are getting through in a timely manner. He also coordinated the move from #ayatana to #ubuntu-unity on Freenode.
• Michael also connected with Jorge regarding the transition of Unity responsibilities and he will be coordinating further relationships with upstreams. The goal here is simple: encourage more participation in Unity development as well as the consumption of our APIs by upstreams.
• I spent some time with the team on team-related workflow. Everyone is pretty happy with how we are working, are happy with the public IRC meetings and comfortable in how we are tracking our work and moving forward on projects.
• We discussed raising the awareness of cool things going on in Ubuntu and discussed how we can provide a more representative view of this work across blogs and social media. You can expect more blogging out of our team and other teams.

Of course, there were many other things that happened, but these were some of the main ones. Remember you can keep up to date with out work on the burndown chart and in #ubuntu-community-team on Freenode.