Apart from changes in my personal life, I was also affected by a sense of purposelessness. I had no idea what I was doing in the community anymore, so I just quit. I feel that this is a general problem in the community. A successful and happy community needs something to do. It needs a responsibility, something it can focus on. For the greatest part of the five years that I have been an active part of the Ubuntu community, I felt part of a group that was working together on creating the best distribution. There was a clear goal: making the best operating system of them all.

The difference with today is that the primacy of innovation, of change, appeared to be much more in the community back then. We were all excited about the upcoming changes and the direction we were heading towards, because we all knew what those changes and directions were. For people to be excited about something, they need to know what to expect.

Ubuntu has matured enormously. Canonical has acquired so many skilled people that I do not fear for the quality of Ubuntu. It is only going to be better. However, that maturation has come with a price: as Canonical moved more and more to an Apple-style secrecy surrounding its plans, the community has been robbed from the vital basking in the glory of the upcoming changes. Because of the way the plans are announced, the community also doesn’t always feel them to be theirs.

Is this a bad thing? Not necessarily. I believe that Canonical’s approach will probably lead to better designs. However, the atmosphere in the community needs to be improved if we want to keep everyone motivated and give the people a sense of purpose. Currently, the responsibility of the community is quite uncertain. On the one hand, Canonical makes it appear in its communications that the community has more influence than it actually has. It says that all employees are community members, whereas many are in fact not. It decides many things on its own, but then says it involves the community. But Canonical seems to steer the Ubuntu project on its own.

I do not disagree with the way Ubuntu is run. However, I do believe that it is vital that the truth is not denied, like the political ‘leaders’ of Europe currently do when talking about Greece. Saying that Ubuntu is created by the community does not make that true. Stop it. Honesty will improve a lot, because it will reduce unrealistic expectations.

With the fallacy of the community running the project removed, the community does need something to replace that. To return to the beginning of my post, what I believe is causing the leadership lethargy that was mentioned in the Community Council, is uncertainty about the responsibility of the community. It should be made clear exactly what role the community plays in creating Ubuntu. What decisions can it make? What can it contribute? What is the reach of the authority of the Community Council over the project? Once that is clear, the roles of the different leaders can be defined within that responsibility. Then they know what their purpose is. Having a purpose, having influence motivates people.

Somewhat related: maybe it would be a good idea to make in every team somewhat responsible for community and contribution management. For example, if you as a community volunteer contribute code to the desktop, who will look after you? Who will make sure that your work doesn’t go to waste? Such a change would also take of stress from the shoulders of the community team, which should not be used for such wide purposes.

The number of bugs reported every day is huge. It’s a continuous flow of problem reports, Apport crash reports, wrongly placed support requests, trolling, feature requests and distress. Heroically fighting to stem the flood is Ubuntu Bug Squad. Together with specialised bug triage teams for certain packages, like the kernel, they try to process as many useful bug reports as they can. However, there are too little triagers for too many bugs.

The current situation is not good for the people who work so hard to process all the reports; many leave the team soon after joining. It also causes relevant bugs to be lost in a sea of unprocessed or half-processed bogus bugs that clog up the system. It has been proposed before, but maybe we should once again seriously consider discouraging non-technical users from reporting bugs.

If we’d decide to do so, regular users would be kept away from the bug tracker. Only for automatically generated crash reports from Apport should be allowed, because the process is such that bogus reports rarely happen and many triage steps for this particular kind of bug can be automated. We would remove the ‘Help->Report a bug’ everywhere, including alpha releases. Links to reporting a bug should be removed from the documentation and the official sites. Launchpad could be adapted to make the ‘Report a bug’ button less obvious.

All this should lead to less bug reports and a higher average quality of the reports. If we focus only on the technically capable and interested users, then we’d have less clueless reports. It would save the time, energy and motivation of the bug triagers, which could then focus on making sure every bug that would be reported, would be processed quickly.

However, we should not forget that one of the things Ubuntu often is credited for is the large amount of bugs forwarded to upstream. Furthermore, an even more important argument in favour of bug reporting for the masses, is the fact that technical users use their computer different than non-technical users. They might miss bugs that non-technical users do encounter or see no problem in a feature of the system that is terribly confusing for non-technical users.

Limiting bug reporting would deprive us of this and that seems sufficiently bad to me to doubt whether we should limit bug reporting at all. I really don’t know what’d be the best. Making it harder to report bugs would make managing the bugs easier, but wouldn’t that also make the bugs we manage worth less? What do you, oh dear reader, think?

The large success of Ubuntu we’ve seen in the recent years has come mostly due to the fact that Canonical is very good at adding polish to the functionality that was already there. It made the great tools of the free desktop software usable by everyone. They still do this wonderfully and I have full confidence that the Canonical Design Team will continue to make Ubuntu suit its users even better.

However, while reading OMG! Ubuntu!’s post about the music and document file browsers mock-ups something struck me. Something that started to bug me while trying out GNOME Shell now became clear. Canonical may be very good on polishing, it may be very good at innovating user interfaces, it cannot do without GNOME. It lacks content.

Now, I don’t mean this in a demeaning way. I have great respect for the vision that speaks from Unity. However, I would like to emphasise that working within GNOME would be much better for Ubuntu on the long-term, no matter how hard it will be in the short-term.

When comparing Unity and GNOME Shell, I noticed right away how clearly a philosophy speaks from GNOME Shell. When using GNOME 3, you can really notice how its developers have purposely worked together to create a coherent experience. It feels nicer than Unity. Plus: it uses GNOME technologies and that improves its integration in the rest of the desktop tremendously.

But after a while you start noticing a few things. GNOME Shell is less stable than Unity and it feels less solid and responsive. Moreover, whereas Unity’s rough edges are at its rough edges, GNOME Shell has rough edges spread equally all over. GNOME 3 looks less slick and sharp than Unity, GNOME 3′s default theme is less crisp than Ubuntu’s Ambiance.

It is a terrible shame that the huge effort Canonical made to get Unity to the high level it currently is, was not spent on making GNOME Shell even better. Canonical may be stubborn, but the company has great ideas and it could have done so much to make GNOME Shell really slick.

Canonical is not a very huge company. It does not have enough employees to create and maintain a whole desktop. This is already showing in the stalled innovation of Notify OSD and friends; I am absolutely jealous of GNOME Shell’s notification area. While GNOME is working on expanding and improving its GNOME 3 desktop, Canonical is still very busy with its own shell. The consequence of this is that the shell does not integrate as much in the rest of the applications as you’d hope. There is a lot to improve in the GNOME project, but when you improve it, you are sure that it fits with the rest of the desktop and that it will look and behave the same.

The Documents and Media file browsers I mentioned earlier can be great ways to give users access to their files. However, every time you implement a way to access stuff like this, you make a paradigm choice. If you want to satisfy the user, it should be consistent. Unity also gives the user access to files, but it does so in a different way. This causes a collision of paradigms. If Canonical wants to do it right, it should ensure consistency across all applications. This is a lot of work and will probably require the development of its own file manager, etc, in the long term.

Canonical does not have the workforce to fully maintain its own desktop. By creating its own shell, it may improve things in the short term, but it will only make things worse in the long run. While GNOME progresses along a different path, the two desktops will diverge even further. In the end, if we ever want to beat Mac OS X, Ubuntu will have to to get rid ofGNOME and Canonical will have to have grown substantially.

GNOME needs Canonical as well. There is no other company in the Linux distribution world that focusses on regular consumers and regular consumers are the target group that shape the OSes of today. I’m not sure how much longer Novell’s remains will stay around, Nokia seems to be on a suicide mission and Red Hat is a business oriented company. GNOME 3′s magnificent user interface philosophy is in need for a good set of clothes and proper manners and of all companies that are in existence today, Canonical is the best candidate to look after that.

My ego is not so large that I believe this blog post can change Canonical’s company policy—which naturally wasn’t thought out in one hour—but I do wish to add my voice to the chorus that say: Ubuntu should return to GNOME 3!

When I bought it, I got a driver CD as well as warnings for Windows Vista. I hadn’t checked for Ubuntu compatibility, so I did expect some troubles and braced myself for hours and hours of fiddling with JACK to make it work. So I started with installing Ardour and trying if I could get anything recorded there. Nothing.

Then I remembered my system was sporting the flexible PulseAudio. So, I went to volume control, saw the Audiolink listed under input devices. After I had selected it, I opened the GNOME Sound Recorder, pressed record and started to play. Bingo! Everything just worked. No fiddling needed. All you have to do is to select a different input, using the default volume control.

This really demonstrates the power and user-friendliness  of PulseAudio. I know that with JACK it is possible to do quite a lot with input sources, but that is too much for what I want. I just need something simple and this is working great for me! Thank you PulseAudio developers!

Let us first take a look at the defined purpose of the ‘local community teams’. The ‘About Local Community Teams‘ page at the Loco Directory has the following to say about it:

With the incredible success of Ubuntu around the world, the LoCo project is here to help groups of Ubuntu fans and enthusiasts work together in regional teams to help advocate, promote, translate, develop and otherwise improve Ubuntu.

Local community teams are supposed to cater a definite geographic area. In the United States and the Russian Federation they ought to cover a state, in the rest of the world a complete country. This geographic constraint is important to notice, since we will see later that it doesn’t always fit well in the case of ‘local communities’.

Within their geographic area, local community teams are expected to advocate Ubuntu, organise local activities and informal meetings. This is all ‘in real life’, the internet presence is often very limited. Teams that behave according to this description, are what I would like to call ‘local teams’. Basically all local community teams from the English-speaking countries are of this type.

Since the international Ubuntu community is English-speaking and provides excellent support via the Ubuntu Forums, Ask Ubuntu and the #ubuntu IRC channel, the internet communities of the English-speaking local community teams don’t have to have a broad own community online. They are limited to small forums that are mostly used to discuss the activities that take place ‘in real life’ and to complement social contact. For the most part they are integrated into the international community.

Virtually all other local community teams, however, can be classified as ‘local communities’. Because many, if not most, of its members do not speak English, they cannot use the online support from the international community. The main focus of these ‘local communities’ is not so much activities ‘in real life’, but instead the management of a language-specific Ubuntu community. Running a community is not easy, so it takes a lot of resources.

The local teams have much more time and energy to spend on organising local activities and meetings, because there already is an online community for them, the international one. You can call the local teams a team because they often consist of equals, working together to spread Ubuntu and enjoying each others presence.

A local community, in contrast with a local team, does not consist of equals working together on the same things. There are many more different functions within a community: there is support to be given, documentation to be translated and written, interface text to translate and all of this needs to be organised. Furthermore, those who come to ask for support are a fundamentally different kind of community member than new computer enthusiasts who joins a local team to help out. Many of the people who come to ask for support are regular users who don’t have the desire to become an active contributor, they only want help. The spirit of a local community is therefore very different from that of a local team.

What makes this even more complicated is that language boundaries and geographical boundaries often don’t match. For example, Spanish is spoken in a lot of different countries by many people across the whole world. Therefore, having one Spanish support channel and forum makes sense. Add to that the Spanish translators of Ubuntu’s interface and documentation and what you get is a very large community, separate from the international one, transcending geographic borders. The difference between this conglomeration of several ‘local community teams’ and, say, the local team of the US state Massachusetts, is one of day and night. Countries like Belgium, where they speak Dutch, French and German, are even more complicated, because you have multiple language communities within the same borders.

Local communities and local teams both do very valuable work. I think it is a shame that many local communities are not locally as active as local teams often are. But this does have a reason: founding, building and running an full-blown online community puts a hefty toll on your volunteers. If you are small, like Ubuntu Nederland, you don’t have a lot of spare persons left to organise social activities ‘in real life’.

Duplicating the international Ubuntu community in your own language is hard, it requires skill to do it successfully. Good documentation can help with that. Unfortunately, most of the documentation—written in the English-speaking international community—focuses on local teams instead of local communities. Also, the requirements of the LoCo Council put a lot of emphasis on local activities, whereas it can be a tremendous achievement already to ‘only’ have a solid online presence.

I should add some nuance to this. Of course there are local community teams that under my classification would be local communities, but which do have a strong local presence; there are probably also local teams that have a large own online community. I acknowledge this and think that the definition of a local team and a local community should be stretched enough to suit this. However, the general observation still applies.

What to do with this analysis? Firstly, I think that the international community should be more conscious of the fact that non-English local community teams are distinctively different from English-speaking local community teams, because of the boundary created by language. We should be aware that there are several parallel Ubuntu communities in other languages that over time may have grown own identities. They may see themselves not as a localised annexe of the international Ubuntu community, but instead as the equivalent for their own language of what is often perceived to be the English Ubuntu community, but is in fact the international one.

Secondly, there also is a task for the leaders of the local communities, who could make their people more aware of the way things work in the Ubuntu project and explain what more there is to do if you learn English. They can help to bridge the gap between the different language communities.

Thirdly and finally, the LoCo Council should take into account when judging the performance of local community teams that not all of them have the extra burden of having to build a complete new community from the ground up.

One could argue that Americans—no, I’m not going to write USanians—derive a large advantage from the fact that the default locale is their English variant. All software is understandable for them right from the beginning. They never have to wait for translations. However, in this piece I would like to argue that actually it is a disadvantage.

The Disadvantage

Why would it be a disadvantage to Americans that all software automatically suits their customs and follows their local quirks? Well, for that I would like to do a game of compare and contrast. Mostly contrast. You see, the US English strings are the only texts written by the developers themselves.

Development attracts people who like to develop, not people who like to write. They do not necessarily come from the United States, often are not native English speakers and many of them can’t see the use of arguing about -ize vs -ise, or have own opinions about it. The consequence is that the US English strings are written by people whose primary interest is writing code, not human language. This is detrimental to the quality of the texts, the suitability of the chosen phrases and spelling and grammar in general.

Translation teams, however, attract people who are interested in language. In the world of perfect localisation, all typography nuts, grammar enthusiasts and spelling bees will join together to form a team with Super Language Powers. This means that the people who will write the text you see every day on your computer are fond of language, know how to use it and have experience to say it, if you speak any language or dialect other than US English.

The Consequences

All languages—except US English—have a corrective filter between the developer’s work and the end-user. There is one community that oversees all use of language in the product. Translation teams often work with word lists, style guides and selection of contributors based on their quality. This allows them to guarantee quality, make sure that all text on the system follows the same conventions and warrant consistency across the desktop. You can correct for overuse or underuse of capitalisation, distinct between the computer and user in events by using different verb conjugations and so on.

Consistency is an important issue. For example, a computer can have a screen, a display and a view. These words are near synonyms, but the X server uses them to distinguish between three different things. It is hard enough for a user to understand what the system is talking about already, it becomes even harder when words can have different meanings in different applications. When there is no central organisation of the terminology, this does happen. Translators could correct for this by adapting the translations to the context, but Americans are out of luck.

There are no people looking after the typography, grammar, capital use and readability of US English. But there is more to localisation: translation teams also make sure that the system is using the correct date format, currency, decimal delimiter and so on. Each country has its own conventions here. No one has the job of nitpicking about the American conventions, so they’re missing a watchful eye here as well.

The result is that the US English desktop can often be inconsistent in style, word choice and spelling. This makes our product less appealing to Americans and to other people using the US English version. If we want to pursue perfection, we should not miss this out.

It has also consequences for the translations. The translations are translations of the original English texts. Although I did say earlier that translators can correct for inconsistency and bad wording, they don’t always do. It is a lot of work to manually check the context of each and every string, many translators just stick to translating every word with the same phrase. Badly used capitals and dots will often find their way into translations as well. Vague US English results in vague translations.

Solutions?

Improving the quality of US English will mean large improvements for all languages if it is done properly, by sending patches with corrections to the developers. I am convinced that we need an American ‘localisation team’, consisting of all American typography nuts, grammar enthusiasts and spelling bees who want to contribute to Ubuntu and FOSS in general. They could work together with other projects to establish conventions and methodically go through all applications to check whether they comply with these conventions.

We cannot ask from all the localisers to understand programming language and patching systems. However, with the current state of technology, I am afraid that writing patches directly for the code is the only option. In the long term, something like a POT editor and a reverse POT generator could improve things.

It would also require infrastructure. Many languages have project-agnostic communities for translation in FOSS that provide various language-related services; examples are the French Traduc and the Dutch OpenTaal. These relations are often not formalised, but they are really helpful in making sure everyone is somewhat following similar rules. As part of FreeDesktop an American initiative could be started, which could keep a list of the standard meanings and uses of words.

The solutions above are just ideas for ways to deal with a problem that we should give much more attention than we have done so far. Admittedly, it is easy for me to talk from the sideline, knowing that I—being a native speaker of the Dutch language, not of US English—will never be doing much of the work I propose. But I do hope that some people will be inspired by this piece and do something with it.

Those poor Americans deserve localisation too!

GNOME was founded by two Mexicans and currently seems to be predominantly dominated by people from the United States, with the foundation itself being based in the States. The most important companies behind it, RedHat and Novell, are both from the United States too.

Ubuntu was started and Canonical was founded by a South African based in London, where the company has its headquarters. Although there is again a very high American presence within the community and company, the leadership is much more eclectic than GNOME’s. Furthermore, the Canonical Design Team seems to be predominantly British.

Why would this matter? Our differences aren’t very large after all, the open source community is dominated (unfortunately) by white, Caucasian males and they have a lot in common. I think it may play a more important role than we have thought so far. Communication is very culture-bound and it seems that it is communication that has been causing most of the problems.

If we look at the rejection of ‘libappindicator’ as an external dependency, we may be able to see this more clearly. Canonical, say some people in the GNOME project, failed to push its inclusion thoroughly enough. They may have done what was formally required, but didn’t show the initiative that could have resolved the issues that were raised. They say that you need to find the right people to talk to, not expect a machinery to process your request once you’ve delivered an appropriately tagged package.

Canonical reiterates that it did what was required to propose a module as an external dependency. They say that they want to have someone to talk to, to have someone in charge who makes the decisions and can be phoned up if necessary.

Both parties expected different things from the other. This may be what caused the unease. Each party feels that it did enough and the other too little, so no one is to blame.

Strikingly, it seems that the cooperation concerning the application indicators/status notifiers with KDE—founded in Germany, its foundation still being based there—was very productive. Was this because of the persons involved, or because of the cultures? The communication ways I described above do seem to reflect the stereotypes of the two continents.

What should be said that the above is a gross generalisation. Generalisations can usually only be used, with great care, when you talk about large groups. In this case it might be better to talk about individuals instead.

I don’t think that what I said above is the whole explanation. I do think, though, that it is something we should keep in our minds. It may not only have played a role in worsening the unease and misunderstanding here, but it affects all communities that are truly diverse. Traditionally, FOSS seems to have been dominated predominantly by people from the US. Now that is changing, more people learn English—as an example, my father’s generation learned German, not English, as the most important foreign language at Dutch secondary school, for me it is English—and ‘developing’ countries are catching up.

Cultural differences will be more visible in communities, we need to be aware of the different ways different cultures communicate if we want to make sure no contributions go to waste.

When people talk about Ubuntu, they usually have two ways of referring to it. Most frequently people use ‘Ubuntu’, but at some places you’ll find ‘Ubuntu Linux’ very consistently. This may be a relic of the past, after all the Ubuntu 4.10 Warty Warthog release announcement has links to www.ubuntulinux.org rather than www.ubuntu.com. In this blog post I want to argue here to stop calling Ubuntu ‘Ubuntu Linux’. There are several reasons to do so.

The first, and the most important argument considering we’re trying to market a product here, is that using simply ‘Ubuntu’ makes the brand name a lot more attractive and easier on the mind. Because of the Linux in ‘Ubuntu Linux’, people will associate it with the legacy of past Linux distributions, and I think that ‘Ubuntu’ is a more attractive name on its own.

The second argument is about being sensible about attribution. Several people have said that Ubuntu should very purposely be marketed as ‘Ubuntu Linux’ to give credit to the Linux developers. Other people, who feel that GNU contributed a lot of code to the base of most operating systems using the Linux kernel, even say that we should try to promote Ubuntu using the impossible name ‘Ubuntu GNU/Linux’. However, why would we attribute GNU and Linux, but not GNOME, FreeDesktop, Mozilla, The Document Foundation, Novell, Red Hat or any of the other projects and companies that all contribute to what is ultimately integrated into one Ubuntu? Does GNU really deserve more to be in the name than GNOME? Isn’t the browser the most important tool of the desktop nowadays?

Putting either Linux or GNU and Linux in the name is not fair at all. There is no reason why those vital projects should be attributed, whereas other projects that are just as vital are not.

The third argument is practicality. Your headlines will be a lot shorter when writing ‘Ubuntu’ instead of ‘Ubuntu Linux’.

The fourth argument is conformity. If we want to bring a consistent message, we all should follow the same naming scheme. This is very important. When someone is talking about ‘Ubuntu’, and another person is discussing ‘Ubuntu Linux’, then you create confusion. “Is Ubuntu the same as Ubuntu Linux, or is it something different?” a person might wonder. Ubuntu Linux could very well be a derivative of Ubuntu! We should pull our act together and make sure we deliver a consistent message. Canonical and most people are using ‘Ubuntu’, therefore it makes sense to stick to ‘Ubuntu’.

Why write this blog post about to propagate a convention that is already dominant? The reason for this can be found in the fourth argument: ensuring consistency. Use ‘Ubuntu’, not ‘Ubuntu Linux’! When you see ‘Ubuntu Linux’ being used somewhere in a description, on a wiki page or elsewhere, fix it! Make sure the public knows we’re all talking about the same product!

The year 2010 has been a tumultuous one for me. On 2 February I finally became an Ubuntu Member, in May and October I attended the two UDSes, and in July I helped the organisation of GUADEC 2010 in The Hague. In October I also became the LoCo Contact of Ubuntu Nederland.

The year 2010 was also the year that my final year at secondary school started. An important transition in anyone’s life. It is very important for me to score high on my exams, but apart from the need for more focus on school I’m also changing as a person.

When I joined the Ubuntu community I was in my first year of secondary school. As someone diagnosed with a mild version of Asperger’s syndrome and ADD in an unfamiliar environment, I didn’t make a lot of contact on school right away. In a new social environment it takes a while before I learn what to do.  The Ubuntu community was an open, welcoming place where I could find company and kind people to talk to, without the fuss that accompanies real-life conversations.

During the years I contributed to Ubuntu I learned a lot and met many kind people. It has been a wonderful experience to have the privilege to work together with such great persons. However, the last five years have been my puberty years, so it would be strange if those would have left me unchanged. As my social skills improved and my school life started to become busier and busier, I felt less and less need to be present in the Ubuntu community.

My lack of time and the decreasing need for community aggravate an increasing lack of motivation. Often I sit behind the computer, feeling bad about myself because I feel I ought to be contributing to Ubuntu, while I’m not. This makes me associate feelings of guilt and dissatisfaction with Ubuntu. I do not want to associate negative feelings with Ubuntu.

I do not want to waste energy and time that I need so much for my final exams. I do not want to turn my great memories of Ubuntu into something bad. I do not want to disappoint people who expect me to do things. Therefore, I have decided to retire from the Ubuntu community and stop before things go wrong. I feel a kind of melancholic sadness while writing this, but, to be honest, also some kind of relief.

I will stop all my work for Ubuntu in the international community. I will not quit as Ubuntu Nederland LoCo Contact. My work for that community will continue as usual for now.

Jorge, the Unity Places API still looks awesome to me, and probably will be playing with it when it becomes public. Now I’ll feel free to do just what I want, so I may be playing a bit more with code. Writing a Unity Place would be a fun exercise.

To all those countless people who I met in the Ubuntu community, I want to say: thank you for being there. Ubuntu was fun because of you. Thank you so much. There are many people who helped me out, but I want to especially thank – in alphabetic order – Carlos de Avillez, Jorge Castro, Jan Claeys, Laura Czajkowski and Dr Vish for their patience with me and for their indestructible enthusiasm, which has been my source of motivation during those years.

I am sorry if I disappoint you by leaving. I do not think that this leave will be forever, maybe I will see you again later, when I come back.

Alle erkende lokale gemeenschappen krijgen eenmalig een spandoek en een tafelkleed met daarop het logo van Ubuntu. Ook dus Ubuntu Nederland.

Ons spandoek en tafelkleed arriveerden vandaag met UPS vanuit Engeland bij mij thuis in Dokkum. Ik heb ze gelijk even op de foto gezet zodat iedereen ze kan zien. Het is de bedoeling om ze te gebruiken voor conferenties en evenementen waar Ubuntu Nederland vertegenwoordigd is. Op dit moment zijn ze nog in Dokkum, maar ik heb een pagina op de wiki aangemaakt om bij te houden waar ze zijn en wie ze nodig heeft.

Misschien is het handig om ze binnenkort wat meer naar het zuiden te verplaatsen, we moeten maar even zien. Maar nu ben ik vooral blij dat we nieuwe, professionele aankleding hebben voor onze stand op conferenties!

Wanneer je ze denkt te kunnen gebruiken, laat het weten. Bedenk wel dat het spandoek en het tafelkleed bedoeld zijn voor gebruik op evenementen waar Ubuntu Nederland wordt vertegenwoordigd, dus niet voor iedere bijeenkomst waar iemand iets over Ubuntu verteld.

During the Ubuntu Developer Summit in Orlando, Florida, we discussed how we wanted to continue the project this cycle. This session resulted in some changes to the requirements of what constitutes a valid paper cut.

We now accept all trivially fixable usability bugs that the average user would encounter in a default application of Ubuntu or Kubuntu OR in any of the featured applications. This expands the number of possible targets and makes sure that we can also look after parts of the desktop that are not included by default, but which will get a lot of exposure.

We also defined our focus as being on applications and upstreams. Wat this means is that we want the project to be especially for making the applications we ship work great, and that we want to forward our solutions upstream and cooperate with the upstream projects whenever possible. Projects who would like to work together should contact Jorge Castro. Do note that the One Hundred Paper Cuts project is only for applications that are provided in Ubuntu by default, or are recommended in the Software Centre.

More details and guidelines can be found at the One Hundred Paper Cuts project’s wiki page. If, after reading this page, you still have some questions about the project, please don’t hesitate to ask on IRC—in the #ayatana channel—or in a reaction to this blog post.

This cycle I will probably be giving most of my attention to my role of LoCo Contact for Ubuntu NL, which I assumed Saturday 30 October 2010, while waiting for my plane in the Caribe Royale lobby. I aim to strengthen the structure of the LoCo, making sure we finally get a clear organisation and can act decisively.

That is my most important goal, but there are more. I want to work together with Vish to make sure the One Hundred Paper Cuts project will be a success for Natty, just like it has been for the past few cycles.

The Bug Squad Mentorship programme will see some experimenting to test ways to improve this vital project. It is my goal to help to make the programme ready for starting to deliver good new triagers to the Ubuntu community.

My last goal is to contribute more to the Ayatana project, especially to Unity and to help Unity Places gain traction. I’m not exactly sure how I will contribute to Unity, but it is a great, fun way to learn something new.

These are my main goals and this is what I will be focussing on. I will probably do something to previous areas I contributed to, but not as much as I used to. Since this is my last year in secondary school, I have less time to spend and I also want to spread my contributions not as thin as before.

In half a year I will review my goals and see if I succeeded!

Thursday

Thursday started with a community roundtable. The Beginners Team was one of the things we discussed, and I have to say that I was amazed by the large amount of good work they have done, without many of us taking notice. They really help newcomers to the community to find their place.

During a session on the Unity Places API we learned how much possibilities this interesting software offers. The most exciting piece of technology was the great ‘libdee‘, which allows you to share a table of information over DBus and use it in several applications at once. The table automatically stays synced across all applications! Really cool stuff.

During the ‘Indicator Framework Changes for N’ I learned that the keyboard shortcuts nightmares will go away in Natty, because of the move to Compiz. We can manage the shortcuts there, so things should be working much more smoothly.

Caribe Royale, as seen from the smokers' spot in front of the UDS convention centre.

Thursday had two great plenary talks, from Allison Randal and Ivanka Majic, respectively Technical Architect of Ubuntu and Canonical Design Lead. Allison gave a general talk about how we are different and reminded us of our ways. She reminded us to make sure we can look at things from a different perspective. Ivanka told us about making opinionated decisions, i.e. making choices for our users. Our users doesn’t want to configure everything theirselves, and sometimes when they want we shouldn’t let them. If you limit yourselves to what your users need and make sure the users are not confronted with difficulties they cannot solve, your product will become much better and a lot more user-friendly.

The two-hour Bug Squad Roadmap session was a bit of a marathon, but it was a great session. We are planning on some changes to the Bug Squad Mentorship programme, we will run a trial of putting a few mentors and students into one group and see how that goes. Also, I mentioned that bug triaging is still too much of a first step, a first hurdle, on your way to MOTU-stardom. Now, I don’t want to say that MOTUs aren’t stars, but I do think that bug triaging also needs some status. Why? Because we need more and better people. We could make the requirements for becoming a bug triager stricter—Pedro is looking into bringing some clarity to the application requirements—but we also need to make sure that in our communication we show that bug triaging is something on its own, worthy of mentioning on your resume. Bug triaging is not easy, it requires a lot of knowledge and effort to become a good triager.

Friday

Friday we discussed how to handle non-English bug reports. We didn’t make any fixed decisions this session, but we will take a look at using Launchpad Answers to solve our problem. Bug reports would be recommended to use Launchpad Answers to report their bug in their native language, their local community could then help with translating the issue into a bug report and translating the communication.

We had a very interesting session on the results of the Unity Usability tests. It turned out that many users had problems with finding out how to drag icons. They tried to drag them up or down in a straight line, but that was not possible. Also, it was highlighted how extremely difficult users find it to launch an application they just installed from the Software Centre. They first look for more information at the “More Information” page of an application, then try the website—which is often not very useful to a user—and then the screenshot. Charlene said that some users even thought the screenshot was the real application!

My bed in Caribe Royale, complete with its five pillows

The lightnight talks were really good this time. If you want to use threading and pipelines in C, use libpipeline! If you have a question about Ubuntu, go to AskUbuntu! If you want to design an awesome interface in Qt, use QML!

There were only two sessions left then: a summarising QA Roundatble and an interesting session in which we examined the needs of the Ubuntu community with regard to AskUbuntu—I hope to see localisation coming to AskUbuntu in this cycle. After those two sessions we had the closing procedures and then it was over! Done, finito, voorbij!

I took flight MP636 from MCO to AMS, which left at Saturday 30 October 19:30 EDT and arrived at a bit before 9 ‘o clock, CET, at Sunday 31 October. Today I didn’t go to school, but instead slept until 12 ‘o clock. I’m curious to find out tonight how far my jetlag is gone already.

Pictures!

Tuesday

The first session I attended Tuesday was the Community Roundtable, in which we discussed Team Reports and Planet Ubuntu, amongst some other things. It was said that for some it is not very clear how to add the Team Reports to the wiki in the correct fashion. To solve this the documentation will be improved, and we also may see dedicated website for submitting Team Reports. I remarked that another language is another barrier; in Ubuntu NL the most important argument against writing Team Reports was that we thought we had to write them in English. However, I have been told that it is not required to publish the Team Reports in English. This will make it a lot easier for us to write down our activities.

We also talked about Planet Ubuntu. A number of people, including me, expressed the wish that all posts on Planet Ubuntu get a name attached. It will be looked into how to make it possible to also make the name of the authors show up next to aggregated posts from the Canonical Design Team. It is also very possible that we will move away from PlanetPlanet, since that is an orphaned project, and even the original author has told people to move to something else.

The Indicator Datetime and Indicator Session were very short; it is mostly bugs that need to be fixed and polishing that needs to be done. Also, Ted Gould likes Texas so much because there are no naturally occurring lakes, save for the one that was created when a beaver built a dam somewhere.

During the plenaries I spend some time trying to figure out what is going on with this Packard Bell EasyNote MZ35 laptop. I’ve got this annoying bug that makes it that every time I am using wireless on this crappy RaLink RT61—the ‘rt61pci’ kernel module has been causing a lot of problems on this laptop and is probably to blame for this as well—and am not connected to a power socket, the laptop freezes.

In the ‘Encouraging game development on Ubuntu’ session Rick Spencer demonstrated his awesome work on creating a PyGame template for Quickly. Currently the command ‘quickly create ubuntu-pygame foo’ creates an actual working basic game, a nice start if you want to create a simple game. I didn’t follow the rest of this session a lot, so I can’t say much more.

Next was a really great session about the One Hundred Paper Cuts project. We should be really thankful to the wonderful, wonderful work Vish has done for this project last cycle. Without his tremendous efforts we wouldn’t have got nearly as many paper cuts solved as we did for Maverick. For the Natty cycle we want to make sure he gets some help. At least I plan on doing more work here. We are making some changes to the way we work on improving the package descriptions and are planning some other improvements to the project as well. More of that later, as I think this deserves a blog post of its own. One thing we will change I can say is that we will allow paper cuts to be reported against more applications, even some that are not in the default installation.

The last session of Tuesday was about the Adopt-an-Upstream project. This pet-project of Jorge will become more visible as we plan to make more people explicit Upstream Contacts who are currently already doing similar tasks. More of this will probably be announced in a blog post that Jorge will most likely write about this. (Right, Jorge?)

Wednesday

The first session of the day I attended was more of an informative session explaining the different technologies on which Unity is built. Something new I learned is that Unity will be a plugin of Compiz, just like Scale or Expo.

The ‘Launchpad for Upstreams’ session was a a really useful one, mostly because it allowed different ‘stakeholders’ to share their thoughts on Launchpad’s behaviour regarding upstreams and propose some optimisations. An exiting feature that was announced during this session was something that the developers have been working on for the last few months: we will see options on Launchpad to set the mail notification level in bugs and the possibility to subscribe to bug searches soon. Great news!

Here I would have talked about the plenaries of today, and the other sessions of Wednesday. However, because I am very tired, it is very late already and there weren’t many very important sessions for me I am skipping this. Apologises in case you were interested.

The last session of the day was about the Bug Squad’s documentation. Currently there is way too much text and there are way too many pages. This needs to change. It will be a lot of work, and this session as only a first discussion. We will probably see all current documentation moved to some archive, and then we will start the documentation from the ground up, moving over the useful pieces of text and designing an understandable and maintainable documentation structure. Stay tuned for more.

See you tomorrow.

The TomTom is for the time estimate, I swear!

I arrived in Orlando at Saturday evening, after a nine hours and 40 minutes flight from Amsterdam, which was preceded by a two hour car drive to Schiphol. My flight was delayed by one our, but I didn’t have the bad luck of the poor people arriving from Poland who had to circle for two hours in the air above Frankfurt because of heavy mist.

On our way to cheap shopping!

Sunday morning we went with a couple of people to a factory outlet store group nearby. It was at walking distance, but we did have to risk our lives by crossing the busy motorway next to the hotel, and the 30° C temperature made things a bit more sweaty than it would have been in the 8° C there is at home right now. In the evening we took the Mears buses to ‘Downtown Disney’, for dinner. There were three buses, three drivers and three guides for the four of us who showed up. Most people where at the mandatory Canonical-only keynote, or had yet to arrive. If you’re at the Ubuntu Developer Summit, please be aware of the buses Canonical arranged to bring you to either ‘Downtown Disney’, ‘Universal City Walk’ or ‘Point Orlando’ in the evenings!

This morning opened with the kick-off keynote, started by Jono Bacon and finished by Mark Shuttleworth. Jono explained how the UDS works, Mark introduced the plans for Natty Narwhal. I could talk about the funny routine with the fly in the ice cream (morale: one bug can spoil it all) or the ‘cadence, design, quality’ focus line, but of course there is only one thing that everybody is talking about. That is this: for 11.04 Unity will replace GNOME Panel as Ubuntu’s shell for GNOME on the desktop as well as on notebooks.

I’m sure many people will be shocked by this, but it comes as no surprise to me. As ArsTechnica pointed out in their article covering the announcement of this morning, RedHat—which appears to exercising complete control over GNOME Shell development—and Novell are mostly focussed on the enterprise desktop, which is completely different from the end-user’s desktop Ubuntu is focussing on. Take that and the fact that it has been frustratingly hard for Ubuntu Community members and Canonical to contribute to GNOME, it is no surprise that eventually there is some divergence.

Exciting times are ahead, and it will not be easy to make Unity as good as it needs to be, but I have full confidence that we will have delivered a great product when the next LTS release is there!

The sessions I attended today were the Desktop Team Roundtable, the Ayatana Roundtable, App Review Board Review, Ubuntu Development Advocacy and Quickly Widgets.

The Desktop Roundtable made it clear that this will be a very interesting UDS for the Desktop Team. The fallback in case Unity is not supported by the hardware needs to be planned, and there is GObject Introspection, and the default application selection that will be discussed.

On the Ayatana front we will see a merge of the GtkMenu processing code of AppMenu and Application Indicators. This should help a lot to solve bugs that are currently plaguing exotic menu items and mundane submenus in Application Indicators.

During the Quickly Widgets session Rick Spencer gave a nice overview of the great number of widgets that are already available from this neat little project he has been running in his spare time. We probably won’t see Quickly Widgets moving to a full-blown library in the near future, but there will be improvements and exciting new widgets. Rick has been working on a webcam widget, and we briefly discussed video/audio-player widgets as well.

Today’s plenaries were interesting as well. The nicest was Rick Spencer’s plenary on ‘gifting’, in which he reflected on contributing, giving something to someone else, without gaining direct benefit from it for yourself. We should keep in mind that everything resolves around the user: we give to the regular user, not so much to other developers.

The most interesting two plenary sessions were the last two by Matthew Paul Thomas and Evan Dandrea, on the applications available for Ubuntu. Statistics were shown of the number of applications available for Ubuntu, which had grown to about 3000 (*.desktop files) in six years. To show the contrast with other applications, statistics of Android and iOS were shown. Android now has 100,000 applications available in its App Store, iOS 300,000. Both operating systems are younger than Ubuntu’s six years. Clearly, something’s missing.

There is a bottle-neck: Debian and we, the distribution, package most, if not all of the software available on Ubuntu. It takes long for all applications to get updated, some get neglected, a lot of software is never packaged and developers cannot present software to the users as they want it, it has to go via a proxy: the distribution. This does not scale, hence it would be much better (at least according to my personal opinion) to make the developers themselves responsible for packaging and delivering the application to the users. The figure Evan Dandrea showed in his presentation was a circle—instead of DEVELOPER->UBUNTU->USER—with Ubuntu being an upstream for the developers, providing the platform and feedback from the users. The users give Ubuntu the feedback, and Ubuntu provides the channel (Software Centre) for the software to arrive at the user’s doorstep, but the developers themselves would do the packaging.

Of course this would require a lot of automation, but it is something that the App Review Board is very busy with at the moment. We’ve got Mago to do automated testing and there is work going on to write a Python framework for automated  testing. Ubuntu is heading in the right direction!

See you all tomorrow!

Deze LoCoHealthChecks zijn maandelijks, en zeker de moeite van het bijwonen waard, maar vanavond is het extra interessant omdat er als punt op de agenda staat ‘Introducing your LoCo to the wider Ubuntu community’, oftewel ‘Je LoCo kennis laten maken met de hele Ubuntugemeenschap’.
Als je graag meer wilt weten over de Ubuntugemeenschap, en dan dus vooral de internationale, raad ik je aan om vooral te komen vanavond.
Vergeet het niet! 3 augustus, 19.00-20.00 CEST in #ubuntu-locoteams.
Meer informatie op de Ubuntu Wiki: https://wiki.ubuntu.com/LoCoCouncil/LoCoHealthCheck.

However, I would like to take the opportunity to try to turn this into something positive. Because, 1% guys, we know we can do better! Don’t see this debate about Canonical’s contributions to GNOME as an attack on the Ubuntu project, but instead as a challenge!

Raise that number! Show your appreciation for GNOME by contributing to it. We all know the One Hundred Paper Cuts project; work on solutions for the bugs reported there and forward the the patches upstream! Go to GNOME Live! and browse the project pages for ways to contribute. For I believe that the best way to deal with criticism is not attacking the critic with starting a flame-war, but dealing with the problem pointed at.

The challenge: just 1% of the commits are from Canonical. The solution: contribute!

It seems from Dave Neary’s slides that @ubuntu.com addresses are also attributed to Canonical (correct me if I’m wrong!), so it is not limited to Canonical employees.

The day

There were some really interesting sessions today. I haven’t attended much, but I did go to the keynote about activists and journalists and the treats for them in an online world, and what the (FLOSS) desktop can do against that.
Another interesting one was the “GNOME 3 for your Application” talk. Some really interesting plans were shown. I can’t help and wonder, though, if a lot of this isn’t just duplicating stuff from Ubuntu’s Ayatana project, or at least touching it very closely. RedHat’s GNOME 3 and Ubuntu’s Ayatana seem to have a lot in common, but unfortunately there doesn’t seem to be much cooperation and so far the standards and APIs proposed upstream were declined and refused to be used. It would be really a shame if GNOME Shell — which seems to be the big chunk that is going to contain all the new neat functionality — would be using a new API, separate from existing projects. If it would be using standards, but not be using existing libraries for them, then we’d have just dumb duplication of code. I can think of a better way to spend resources.

I hope there will be more cooperation, or at least communication, between RedHat and Canonical on this matter.

T-shirts

I hope this will be the last time I mention those blasted shirts here. Finally we were able to hand out all t-shirts today after some of the organisation went to pick them up from the printer in Nijmegen yesterday night. The good news here is that the Igalia logo, which the printer somehow had made disappear from the final prints of the first batch of t-shirts, is on the newest batch. But still, with the Igalia logo missing from the first sponsors and the huge delays in the deliverances we’re of course not too happy with the service.

Social Media Livestream

The first view days there have been some issues with Identi.ca the UDStream based Social Media Livestream on the GUADEC website. At first the dents were shown with the time in GMT, whereas the tweets were correctly shown in CEST. After I had fixed this everything appeared to be right, but fortunately Stéphane Maniaci was kind enough to keep nagging me about it until I had completely fixed all problems with the microblogging system used more often than Twitter by the attendees. See, my hacky fix for the date problems (‘+ 2 * 3600′) was only working on Google Chrome/Chromium, but made all dents disappear in any other browser. After fiddling a bit with the date format I thought things were completely fixed, but they weren’t in all browsers.

Then I cleaned the code a bit up and by delaying the formatting the Date until after the Date class has been initialised the time is now correctly everywhere without hack, and Identi.ca isn’t broken anymore. This also means that the screen of the livestream in the venue is working at long last!
I’ll push my changes to the GUADEC 2010 Website’s Git repository next week(end) and will backport the changes back upstream to UDStream as well.

Collabora barebecue

Unfortunately, after two weeks of very hot weather, the summer started to fade a bit at the beginning of the conference. Now, this isn’t that bad for a conference, it makes being inside much more bearable, but it is a shame for beach parties. We were having a barbecue at “Beach Company”, but no swimming! The party was very well organised, and the vegetarians were happy with their own stuff and barbecue, and everyone had a great time. New to most of the international guests was the presence of large quantities of the Dutch version of satay sauce (or ‘peanut sauce’), which we seem to put in litres on everything, according to some of them.

Last words

Tomorrow will already be the last day of the conference! I can’t believe that after all these months of preparation GUADEC 2010 will be over! I can surely say that it has been a great fun so far and I’ve met some really nice people. Despite some problems with ordered goods (ahem, t-shirts, ahem), there weren’t any major problems and I’m glad that everyone seems to be enjoying the conference so much.

On to a great last day!

I started to wonder about the use and desirableness of non-English posts on Planet Ubuntu after a comment from LoCo Council member Laura Czajkowski on my blog post Realise native English speakers are privileged. She said: We have many ubuntu members who do not post on planet.ubuntu.com as they feel it has to be in English which is unfortunate as I’d love to read them – we all can use a web translator.

That is something I personally agree with. I see Planet Ubuntu as a window into the general Ubuntu community, not necessarily just the English speaking part of it. After all, when you want language-specific content your LoCo can always provide their own Planet.

However, before bombarding the Planet with posts in a language that not everyone understands I would like to discuss this first and at the same time point at the lack of rules and guidelines there seems to be for Planet Ubuntu. We’ve seen how this can cause confusion and irritation lately when people questioned the appearance of notably Dell, but also other entities. It was their opinion that Planet Ubuntu should be for Ubuntu Members, on a personal title, only.

I’m in favour of allowing everyone to post in their favourite language on Planet Ubuntu. It would make it more useful for more people to read the planet, which would expose them to the rest of the community as well, and it would reflect the international nature of the community better. On top of that, it would allow us all to follow parts of the community that now remain ‘hidden’, by either testing our foreign-language skills, or by testing the quality of the online translation tools.

A possible downside to officially opening Planet Ubuntu for every language could be that it would be less clear what to expect when visiting it. Now people that can speak English know they can go to the planet and read everything. However, this requires mostly a change in behaviour and if people want an English-only planet they can always set one up, no?

What do you, dear (Planet Ubuntu) readers think? Do you want multilingual blog posts, like me? Or are you opposed to it? Please leave a comment.

The days of Latin and French as the lingua francas of the world are long over and we all know that English has taken its place. Especially IT is dominated by the language. Virtually all documentation and function naming is done in English, as well as almost all the communication. There are not many languages that have their own words for ‘computer’ or ‘internet’, or ‘software’ and ‘hardware’ for that matter.

It is logically, of course, to use this language now. It makes no sense to try to get everyone to learn Swedish all out of the sudden because we like that better. If you want to successfully communicate online and participate in an open source community you’ll need English. However, this is the cause of a large inequality between native and non-native speakers.

It comes clear when you take a look at what happens when you’re not a proficient English user. When your English isn’t correct:

• people will take you less seriously and treat you more like a child or an ignorant person;
• you find it harder to express yourself and to make your intentions to someone else;
• using it takes more energy and is more frustrating, meaning you’re less likely to use it;
• you’ll be more often misunderstood and/or be considered harsh, causing negative feedback;
• you find it harder to understand documentation, HowTos, blog posts and other community-vital information.

These points all discourage less fluent persons to contribute to discussions, to speak up. This is very clearly demonstrated by the relative high amount of Americans, and other contributors of English speaking countries, in the community, especially in key roles.

The United States with 300 million inhabitants is smaller than geographical Europe with 731 million people, or the EU with 501 million. Still there are many more Americans visible in the open source projects. There are only about 70 million native English speakers in Europe, from Ireland and Great Britain.

But lets start about India, Indonesia and China. All these countries have populations of less or more than one billion people. That is huge! Ubuntu also seems to be very popular there. Still we don’t see as many contributors from those countries as we see from English speaking countries.

Of course there are many factors that have to do with the diversity and origins of the community members. However, this doesn’t explain everything. India, Indonesia, Brazil and China might still be working very hard on making broadband accessible to everyone, but (Western) Europe has mostly far better internet connections than a lot of parts of Northern America.

I think that one very important reason for this is the fact that not everyone speaks good English, and for a lot of people who do speak English using it is still not as simple as using their native language. You can never learn a second language as good as your native language and it does cost a lot of energy for many people to use it when reading, writing, speaking and listening.

That is a barrier to them to contribute to the open source communities, so they stay in their LoCos or hang around a bit in the international community, but don’t do as much as they could or would like to do, because they find it costs too much energy or it too hard to learn or do because of the language. For most voluntary contributors Ubuntu is something they do in their leisure time, as a hobby. When your hobby is mostly hard and not as fun as other things you could do in the same time, it is not hard to decide not to contribute.

This is probably costing us more contributors than gender or race inequality. It is also something that is harder to solve since you can’t take away all problems by simply educating people and raising their consciousnesses. There will always remain a language barrier.

Raising consciousness does help, though. First of all I would like to make all native English speakers realise that they are in fact — every one of them, including those with dyslexia — very privileged over non-native speakers.

Secondly I would like to ask everyone in the community — also the non-native speakers — to take into account someone’s proficiency when reading a mail written in bad English. It might be tempting, unconsciously, to dismiss the email and consider the author as someone who didn’t bother to write it in proper English. However, please consider that this might be the best English of the author. Give the author a chance regardless.

Thirdly I would like to ask everyone in the community to realise how important localisation and translations are, of the interface and the documentation. Americans are very privileged that they have their whole system, from the texts in some obscure application from universe to their default currency, localised by default. They never have to adapt when a certain application is only available in US English, or when a command line calendar is following their historic conversions. Others do.

Checking the Ubuntu community

I wanted to end this post with an overview of the different councils of the Ubuntu community and the countries of origin/native languages of their members. Just read the data and consider it.

Community Council

Forum Council

IRC Council

LoCo Council

Technical Board

We willen het makkelijker maken voor mensen om mee te helpen en om te zien wat er gebeurt. Want het is eigenlijk te gek dat een lokale gemeenschap voor een opensourceproject bestuurt wordt alsof het een fanforum is. Het zou veel makkelijker moeten zijn om mee te praten, ook al is het niet veel. Dan krijg je sneller mensen die meehelpen naar hun kunnen. Alle kleine beetjes helpen, en iederen moet mee kunnen doen. Dat is wat opensource is, en dat is waar we naartoe moeten.

Het viel me op tijdens het overleg over het voorgaande dat veel mensen het forum van Ubuntu NL gelijkstelden aan Ubuntu NL zelf. Klaarblijkelijk lijkt het forum voor veel mensen zo belangrijk dat ze het gevoel hebben dat het forum alles is. Dat is niet zo, en deze blogpost wil ik aangrijpen om dat te benadrukken.

Laten we eerst eens kijken naar wat Ubuntu NL allemaal doet:

• Vertalingen
• Documentatie
• Releaseparties
• Ondersteuning op IRC
• Ondersteuning op een maillijst
• Ondersteuning op het forum

Dat is meer dan het forum. Sommigen zullen delen hiervan zien als een voortzetting van de forumgemeenschap. Maar besef wel dat een redelijk aantal van de mensen die bijdragen aan Ubuntu NL nauwelijks op het forum komen! Niet iedereen — en daar ben ik één van — vindt een forum een prettige manier om te overleggen. Het vertaalteam gebruikt al tijden een maillijst. Dat heeft echter wel als resultaat dat voor veel mensen ze nogal onzichtbaar zijn.

Als we eens kijken naar de aangeraden gebruiken voor LoCo’s van de LoCo-raad op https://wiki.ubuntu.com/LoCoCouncil/LoCoTeamsBestPracticesandGuidelines dan zien we dat ook weer terug. Je ziet dat het forum één van de manieren is waarop ondersteuning gegeven kan worden. Misschien moeten we ook maar duidelijker het forum losweken van het team zelf. Een appart forumbestuur kan sneller beslissingen nemen en zit dichter op het forum, en het zorgt er bovendien voor dat de rest niet mee hoeft te vergaderen over forumonderwerpen.

Het is zo gegroeid dat veel communicatie over het forum gaat. Jammer genoeg lijken fora te stimuleren om nergens anders dan op het forum te kijken. Veel mensen horen enkel aankondigingen als die op het forum geplaatst worden. Het forum is dus de centrale plek geworden waar mensen van de gemeenschap elkaar ontmoeten. Het totale monopolie dat het forum echter op de communicatie lijkt te hebben schrikt wel mensen af om bij te dragen. Ook ik ben lange tijd niet actief voor Ubuntu NL geweest omdat ik gewoon geen zin had om een forum in de gaten te moeten houden.

Het forum heeft alles een beetje opgeslokt, en samen met dat monopolie is het niet onbegrijpelijk dat mensen soms denken dat het forum alles is. Maar het is wel een verkeerde aanname, en een aanname die mensen weg kan houden. Het forum is één van de manieren om te communiceren, maar er zijn meerdere. Bovendien is het slechts een middel.

The definition is this:

“A paper cut is a trivially fixable usability bug that the average user would encounter in default installation of Ubuntu or Kubuntu Desktop Edition.”

The goal is to fix at least 100 paper cuts this cycle. Last cycle we had the same goal, but actually finished 103 — thanks to great upstream participation — and I hope we can break that record for Maverick.

There are ten milestones to which accepted paper cut reports are assigned. Each milestone has a theme.

• Round 1 File Management: Nautilus;
• Round 2 Office: Evolution, OpenOffice.org, gedit, etc;
• Round 3 Social Networking: Empathy, Gwibber;
• Round 4 Miscellaneous;
• Round 5 Photo Management: Shotwell;
• Round 6 Sound and Video: Rhythmbox, Totem, PiTiVi, etc;
• Round 7 GTK+ and Notify OSD;
• Round 8 Miscellaneous;
• Round 9 Software Center: package descriptions;
• Round 10 Software Center: applications from universe that don’t work.

This set of milestones may change and the lists of bugs assigned to them aren’t final. Please also note that you can only work on paper cuts that are on this list. The milestones are a guideline, but please feel free to work on any paper cut with the status ‘Triaged’, your work will be appreciated! A list of paper cuts with the ‘Triaged’ status.

When you have chosen to fix a paper cut, please make sure you check the upstream bug report if it is there. Once you have fixed a paper cut and have got a patch ready, please attach it to the paper cut bug report and we will be very happy to accept it.

We are also looking for stories. Have you fixed a paper cut? Tell us how you did! Blog about it, or send your story to Jorge Castro or Jono Bacon.

If you want to work on Kubuntu you can find a list of paper cuts by searching for the ‘kde’ tag.

The two new tags are ‘app-menu‘ and ‘trayaway‘. The first one is for problems that show up in applications when the Application Menu is enabled. Currently there are no bugs using that tag. The second tag is for the Notification Area transition; some applications still refer to the tray in their settings and dialogues, but that should be removed once the tray is gone as well.

Indicator Application

Another tag we’ve been using last cycle was ‘indicator-application‘, for bugs related to the Application Indicators. At first the tag was mostly used for applications that needed to be ported to Application Indicators — the tag still gives you a nice list if you want to do some work — but later in the cycle bug reports about issues with the implementation of Application Indicators in the users also ended up on this list.

Usage

I would like to ask everyone at the two lists to use the tags when necessary. But only when necessary, because if we want to make sure the list of bugs under a certain tag remains usable we need to tag with care.

This means: don’t tag bugs reported against the packages of the projects themselves; i.e. don’t tag bug reports reported against the ’indicator-application’ package with ‘indicator-application’. The tags are purely for issues with those projects in other packages.

Helping out

The tags are a great opportunity for those of you that want to help out with Ubuntu’s desktop experience. Most of the issues you’ll find with these tags are not too hard to fix and would be a great way of getting to know the Ubuntu platform by contributing to the cool stuff. There are still a lot of  applications listed at the overview page of the ‘indicator-application‘ tag that need to be adapted to use an Application Indicator. But once we’re a bit further in the Maverick cycle the other tags will also give you quick access to some bite-size tasks. Fixing those will make a real difference on the desktop!

The complete list of Ayatana tags can be found at the BugSquad’s tag list on the Ubuntu wiki. Please update the wiki page if you start using a new tag.

The forest path between Hoeilaart station and UDS hotel Dolce la Hulpe

I arrived at the evening of Sunday 9 May at the hotel after having walked from the Hoeilaart train station to the Dolce la Hulpe hotel, where the conference was located. Fortunately I had missed the bus in the Netherlands that brought me to the train station where I departed, so I managed to take a quicker bus (makes sense?) and got the earlier train.; the walk from the train station to the hotel was a lot longer than I had anticipated.

Canonical chose the hotel wisely, one could say, because it was completely surrounded by forest and even the village was at least a half an hour walk away. The only escape methods where the expensive cabs or the evening coaches Canonical kindly had provided for. This meant that we had nothing to do than thinking and talking about Ubuntu. Not that this was a bad thing, I enjoyed every minute of the week.

Wireless

Like every hotel upon which a swarm of geeks descends the wireless network of the Dolce la Hulpe lobby also collapsed under the weight of the almost(?) 300 attendees trying to access it at the same time. The routers just couldn’t keep up with the endless requests for new DHCP-leases. Fortunately the network in the conference centre and the auditorium was deployed by the Canonical sysadmins. If I heard it correctly there were about twenty access points flown to the hotel and set up in the auditorium and around the brick core of the conference centre. Those networks did not fail and provided a reliable connection with the outside world. Yay for them!

The design team

The design team was a great example for us all by showing how to learn quickly. During the Lucid cycle they received fierce criticism for some of the changes to the way Ubuntu looks and feels, but soon they started to improve their communication with the community. What the community members want is an explanation of why the change was made, a rationale for the decision. Announcements made for the Maverick cycle where much more elaborate, linking to design specifications on the wiki and showing examples, even before the Ubuntu Developer Summit. Creating a ‘planet’ for the design team has also helped with this by providing the design team with a channel for communicating with the rest of us. It must not have been easy to see your hard work for Ubuntu being rewarded with personal attacks on your blog post, I really hope the frequency will decrease over time as the community gets used to the concept of a design team.

Other teams can learn from this!

The sessions

Room at the UDS Maverick (Mahogany?)

There was a session about providing people wanting to write applications for Ubuntu with clear information on how to do so. At developer.ubuntu.com we’ll be creating a site that gives a comprehensive overview of the Ubuntu platform — i.e. the libraries that are used and recommended by Ubuntu — and links to more extensive documentation, like the yet-to-be-written Ubuntu Developers Manual. We want to make it very easy to Quickly write an application that scratches your itch and integrates well with the Ubuntu desktop.

During another session we’ve discussed the Bug Squad Mentorship programme, which didn’t work very well during the Lucid cycle. The people that had offered to mentor didn’t accept a lot of students, and the people that got accepted as a student didn’t always turn up. However, a mentorship programme has a lot of potential and we want to get this working. Therefore hggdh, Pedro Villavicencio, Charlie Kravetz and I volunteered to be the Bug Squad Mentorship administrators. Our task will be to couple students to mentors. At the moment we’re in the process of cleaning up, if you’re considering to request mentorship, please wait. All current students and mentors should have been mailed with a question regarding their current status and whether they are still interested. See the blueprint if you want to know more.

We’ve also discussed the status of the Adopt-an-Upstream and Adopt-a-Package projects. We’re happy to see that people are taking part in it, but we would like to see some more participation in the larger projects. Work will be done on making the documentation more clear, as well as adding more information when necessary. The blueprint contains the work-items.

In between or during the sessions I also found some time to talk with the sole Ubuntu NL and the Ubuntu BE members I’ve seen about Ubuntu NL. We had some nice discussions and I was really glad to meet them In Real Life. As a matter of fact I’ve met the same amount of people from New Zealand as from the Netherlands. To me that really is a powerful demonstration of the language barrier for participating in the international community. English is vital, but this is a disadvantage to non-native speakers. Not only will non-native speakers have more trouble eloquently selling their ideas to eloquent native speakers, but a lot of the non-native speakers actually never learn English good enough to contribute internationally.

Motivation

What can really motivate me, I’ve discovered at the UDS, are exciting new things. The prospect of Unity coming true, or even Scott James Remnant‘s awesome sounding plans for Upstart in Maverick make I cannot wait for those to become reality and I’m proud to be active in a community that produces this wonderful operating system. Maverick promises to become a great release already, imagine what 12.04 is going to look like!

Af en toe organiseren ze een wedstrijd om de aandacht de vestigen op de problemen die er zijn en om vrouwen aan te moedigen actief te worden in de gemeenschap. Nu hebben ze een nieuwe wedstrijd georganiseerd: ‘World Play Day’. Over het algemeen zijn het vooral mannen en jongens die worden afgebeeld als gebruikers van technolgie; het doel van deze wedstrijd is het verzamelen van foto’s waarop meisjes — jonger dan 12 — te zien zijn die met Ubuntu.

Er zijn twee prijzen te winnen: de winnaar wordt aangewezen met behulp van een verkiezing. Het meisje op de foto dat door de gemeenschap wordt uitgekozen als de beste wint een Dell Mini 10n. De andere prijs wordt verloot door een willekeurige deelnemer te trekken uit de inzendingen. Het meisje op deze foto krijgt een verzameling ‘Ubuntu-goodies’: een muismat, Silly putty, een Ubuntu notepad(gerecycled), een Ubuntu pen, een Ubuntu keycord en een Ubuntu t-shirt.

De volledige aankondigen — met alle regels nog even duidelijk op een rijtje — is te vinden op http://wiki.ubuntu-women.org/Events/Competitions/WorldPlayDay/Announcement.
Inzenden kan tot 1:59 op 15 mei. (23:59 UTC, 14 mei).
Dit bericht was een aangepaste versie van een onderwerp dat ik eerder op het Ubuntu NL forum opende. Zie http://forum.ubuntu-nl.org/offtopic/’ubuntu-women’-wedstrijd-world-play-day/.