Archive for August 15th, 2006

Posted on August 15, 2006 - by jono

The Official Ubuntu Book is out!

Today when I got in from work there was a FedEx package containing one of these:

This my friends, is the Official Ubuntu Book and it is out now!

I am really pleased with how the book turned out, and it was a delight to work with Mako, Corey, Jonathan and Ivan. A special thanks should go out to the awesome Debra Williams-Cauley who nurtured the book through every step. The schedule for the book was pretty tight and it was an interesting experience writing a book around software that was not written yet. I remember hanging around #ubuntu-devel getting daily updates about the GUI installer as Colin was writing them. Bleeding edge writing if there ever was.

Also, thanks to the incredible Ubuntu community who contributed recipes for one of the chapters. This started out life as this fridge post and resulted in an awesomely diverse chapter. This not only gives the book more value, but makes the book feel like a real community effort. Thanks for your awesome work people!

Finally, the book is released under an open license, but I really urge you to buy a copy. This is not for any financial benefit for the authors, but for the potential of a second edition. If this book sells well, there will be another, and we can keep having a high quality official guide for Ubuntu. So, vote with your feet and grab a copy. If a second edition is commissioned, I would love to explore ways in which we can increase the contribution of the community and the doc team to the next edition and continue the community contribution to the book. This is not mine, Mako’s, Corey’s, Jonathan’s ad Ivan’s book – its our book – lets make it rock hard.

Posted on August 15, 2006 - by jono

Easing contributions for creative thinkers

MacSlow brings up some interesting points in his most recent post, and although his idea about the library he suggests makes perfect sense to me, I would like to broaden out the discussion a little to explore ways in which visually creative people and others can better help the desktop experience, without suffering through processes alien to them.

Part of the problem is that the current development model is fundamentally based around programmers. Even if you have an artist working away in Inkscape doing some art, the artist typically needs to know about Subversion and needs to be on the bleeding edge, checking out code so they know which icons to draw. Even then, when it comes to icons there are different sizes, and technical reasons and contexts when those sizes are used. This all fundamentally detracts away from the core skill that person brings – to create beautiful artwork.

In recent months we have seen an explosion in the visual side of the desktop with Tango, Cairo, Compiz, XGL/AIGLX and more maturing. I am really interested in exploring better methods of putting visually creative people in a position where they can express their ideas in such a way that makes sense to developers/users and can be implemented easily. Now, in the long term, expansive changes to desktop infrastructure could theoretically accommodate this (such as the oft-discussed CSS driven theming engine). In the meantime I put this to you – let us try and create usecases that are amenable to non-programmers and build around it.

A few examples:

• Artists – artists should not need to know what version control is, they should not need to know about code, development, checkouts or other fluff – they should just need to know (a) which icons/imagery is required and (b) any guidelines (such as Tango) in producing that art. When art is created, it should be easy to pass it to the developer, and the developer should be easily able to manage it.
• Documentation writers – docs writers should again not need to know about this programming fluff, and they really shouldn’t need to know about markup languages. The docs writer should just be able to view a page and edit it straight away. Wouldn’t it be great if you could just click on the text on a wiki page and edit it directly instead of having to learn all that pesky wiki markup?
• Bug reporters – bug reporters should not need to know about severity, versions, milestones, products etc. The reporter should know the problem and be able to tell the developers easily. Bug buddy is a step in the right direction with regards to this, but I still think the problem can be eased. Bug reporters are users, and anything that sounds vaguely non-userish will be seen as gibberish and will put the user off reporting bugs. We should treat bug reporting with the same level as care as we treat the desktop. Why don’t we use Istanbul to record the bug happening?

All of this is about process – we need to identify methods in which we can preserve the seedling of that skill in question and not run it through the shredder. Fewer obstacles in the way of contribution means more contributions and a greater eagerness to contribute. Contributors just want to do the thing in hand, and I am convinced there are huge opportunities to ease this process.