Archive for November 18th, 2008

Posted on November 18, 2008 - by jono

Want To Be a Horse[wo]man?

Just a quick note to let you all know that I am still looking for a fourth horseman or horsewoman to join Daniel Holbach, Jorge Castro and I. The role involves reporting on the progress and growth of the Ubuntu translations community, growing and expanding the community, working with LoCo teams and working with upstream translators and projects. If you are smart, hard-working and think outside the box, we want to hear from you. Also, just for the record, an appreciation of death metal is not a pre-requisite.

Curious? Well, go and read the job description and follow the instructions to apply. Please no not contact me directly to make your application, just follow the instructions.

Posted on November 18, 2008 - by jono

Lowering The Theming Barrier with CSS

Andreas writes about some of the work going into the GTK CSS Engine.

“Back at GUADEC in Birmingham, when Garrett proposed using css-markup for widget themes, I thought it sounded a bit too cracky to be doable. Rob’s recent work, however, looks really sweet and since every designer and his mother out there knows css, this is a great way to lower the barriers of theme creation”.

The basic idea is that GTK (and as such GNOME) themes can be created using the well established Cascading Style Sheets technology that web designers the world over are familiar with. This is something I was blogging about back in 2005 after some discussion in the Tango project (unfortunately, the original link to the discussion seems to be dead).

What excites me about this is not the seemingly obvious technical coolness of the idea, but the fact that it breaks down the barrier to implementation and experimentation in an important, creatively fuelled part of the desktop experience – themes.

Themes are objects produced as a result of artistic creativity. Great themes are constructed by those with a strong eye for colour, interaction design, and aesthetics, and an understanding of the emotional and practical effect of this sandwich of visual considerations. The problem is that different brains work in different ways, and visually creative thinkers typically communicate their art via more direct means – painting, sculpting and drawing – they use their hands to produce the art directly. Abstraction and interface typically has no place in the traditional creative arts. Computers have made this kind of artistic expression insanely more complicated, with paint packages, 3D modeling software and other applications, all expecting the artist to understand the rules of interaction defined by the computer. We have since produced a generation of artists who have figured out how to squeeze their creativity into this computer shaped box.

What excites me about the CSS GTK engine is that it makes logical sense to build on a body of knowledge that the creative community has already worked hard to aquire. Artists and designers the world over have spent years learning CSS and figuring out how to represent their creative intentions via this language. The language and its structure has been refined over the years based on feedback, and is now an elegant and well understood means of visually depicting content for different types of media – screen, print, mobile and more.

I believe that a CSS driven theming engine is going to open up GNOME theming to a whole new demographic of potential contributors, and sites such as GNOME-Look are going to become the bubbling pot of exciting new visual potential in the desktop. I hope that our friends in the Qt and KDE world are going to do the same.

Even though I am not a part of the work going on in GTK CSS support, I would urge the developers of this support to focus their efforts on one key area though – soliciting feedback from artists. To make this a success, artists need to help drive the CSS support to be as flexible and complete as possible. Andreas talks about this intention already:

“Rob is in great need of designers to test these things out in the wild though, so if you’re a designer with css knowledge who always wanted to create widget themes, don’t hesitate to check it out from svn and give it a shot”.

The key here is going to be simplicity – artists need to be able to test the software easily and communicate their thoughts just as easily. I would urge you folks to produce distribution packages so you can bypass the expectation of using svn, and have a clearly defined process so artists can share what challenges they face and how support could be built in to improve this. This could be achieved by website forms, artist interviews, assessment of CSS themes and surveys.

There are so many areas in which we can make the many collaborative opportunities with Free Software easier, and I am excited that this important area is getting such quality focus. Great work folks.

Posted on November 18, 2008 - by jono

On Feedback

Ubuntu is a big project. Hundreds of teams, thousands of contributors, millions of users. Every day the project grows by a fraction of a percent, but the fraction is bigger than you might think. With such a wide ranging and diverse community, growth in the project happens at an intense rate. We are not the largest collaborative project in the world, but we are not small, thats for sure.

In addition to this existing Ubuntu-focused diversity, now let us roll into the mix the deep relationship that Ubuntu has with a great many other Open Source projects. There is the obvious connection to Debian, but we also have an extensive relationship with a range of upstreams – GNOME, KDE, X.org, OpenOffice.org, Mozilla and more. With thousands of Ubuntu contributors interfacing with thousands of upstream contributors and millions of users, the jigsaw puzzle is rather large. With so many interconnections between communities, one of the problems is that a person can only see so much of the picture any one time. Part of the skill of a community manager is to try and see the full picture.

This has been something on my mind for a long time – how can we see the great many interconnecting lines between different parts of community. In effort to make progress this area, I have worked closely with my team to build some metrics to understand our community. These metrics are mostly based around bugs, but they give us a solid idea of how to see additional parts of the picture. But metrics are one thing – they show progress and they show the timeline of progress, but they don’t provide good solid feedback. They don’t help us to fix things.

Like any Open Source project, we get our fair share of criticism about what we do. Although I cannot guarantee that we will always make the right choices every time, I can guarantee that we make every effort to make the right choices based on informed evidence. The work that my team and I have been working on recently is to help better make those choices. To achieve this we have been on something of a feedback shopping spree.

Much of this started back when Jorge and I started work to improve our upstream bug story. As I talked about in previous entry, bugs are an important mechanic in how Open Source projects communicate and we want to make all of the points of interaction as painless and as smooth as possible. We broke down the workflow and discovered we needed to know about the problem, and with this mind we threw out an upstream survey to some upstream projects that we work closely with, and a general survey that anyone could contribute to. We then evaluated some of the comments from the survey and continued work to develop the upstream report. The feedback helped us to craft a tool (the upstream report) which has helped us focus our efforts in the right areas. Subsequently, we have seen a marked improvement in linked bug reports between Ubuntu and upstream.

As part of this feedback, we were told that our patches could be better. Patch quality typically falls into two key areas – quality and discoverability – people want quality patches that apply easily and they want to be able to find them intuitively. We have since made this a priority and I asked Jorge to post a patch survey to a number of upstreams and also solicit more general feedback. Jorge did an excellent job here, and this survey will help us drill down in more detail how we can improve our patches. The aim here is to firstly produce best practise around patches – to help our community and our staff at Canonical not only produce technically proficient patches, but to understand what upstreams like to see in a great patch. Thanks to everyone who has participated so far. I am looking forward to the outcomes of this research and its impact on how we work with upstreams.

Feedback is a useful tool and I recommend all Open Source projects to make use of it. When sitting down and exploring ways in which you improve your governance, processes and methods of interaction, it is tempting to become to wrapped up in technical processes. It is tempting to try and produce technical solutions to social problems, but many of the problems and issues we can face within a specific community or the wider Free Software world are cultural, social and habitual divergences in practise. Feedback, and the simplicity of providing objective feedback can be a fantastic antidote to the production of unnecessary processes that attempt to solve half-understood problems. Bureaucracy is the ultimate enemy, but decisions without enough feedback from those who your solutions will affect, are just as potent an enemy.