[MacSlow brings up some interesting points](https://macslow.thepimp.net/?p=78) 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.