Re: [Gimp-developer] contribution processes...

[yahvuu <yahvuu gmail com>]

Am 13.05.2012 15:15, schrieb peter sikking:
> yahvuu wrote:
> 
>> some food for thought from the mozilla folks who have a proud track record of successful open design:
> 
> I am not that familiar with the mozilla processes (although do I
> know the guys from the agency Silver Orange who are/were simply
> contracted to design mozilla software, all of it).

next time you meet these folks give them a good talking-to about the use 
of vertical space in thunderbird :->>


> ‘proud track record of successful open design’
> 
> that is quite a claim. anywhere visible on the net how that works?

i'm mostly referring to the blogs of Alex Faaborg and Aza Raskin [1][2],
plus some linked discussion strewn throughout the mozilla wikis.
These two are not working for mozilla anymore, though.


> I looked carefully at the 3 links you sent.
> 
>> bugzilla keywords like 'uiwanted' may be useful. Complete list available here:
>> https://bugzilla.mozilla.org/describekeywords.cgi
> 
> yes, already thinking how the new process will integrate with
> bugzilla is useful. however I want to avoid that things
> needing UI design become a blocking state in bugzilla.

to avoid blocking, the UI issues could be addressed by dedicated, additional bugs.
If in turn some specific UI question is indeed blocking, it is probably 
a good thing to have that visible in bugzilla.



>> Open Design: Five Lessons 
>> http://www.azarask.in/blog/post/open-design-four-lessons/
> 
> I can only call this open design in this way:
> Sebastiaan de With designed a new logo for Ubiquity.
> he did this in the open. they got a lot of ideas and feedback.
> then Sebastiaan did all the heavy design work.
> 
> this is how interaction has been designed up to now in GIMP.
> for instance: save + export. in the open, loads of feedback
> (that made it significantly better) and I did all the heavy
> design work.

IMHO the benevolent dictator (team) working in the open is just about the 
right approach for an open project. At least, community design has proven
to be less successful for GIMP.


In that context, i'd like to highlight one particular challenge:
How to embrace new developers whose contributions do not match the product vision?
It is hard to bear for an open project that the traditional scratch-your-own-itch
approach cannot be allowed in the UI domain.

The project has to cope with the fact that technical people generally are not
aware of the value of interaction design, at least as of 2012. Moreover, it takes 
an eye-opener like "About Face 3" by Cooper to get a grasp that this is actually 
a field of its own. Personal intuition und common-sense reasoning is simply not 
enough to design proper interaction for GIMP.

The only constructive solution i can see for such conflict-prone contributions is to
let them live and evolve as plugins/add-ons. If a capable coder is really burning to get 
the feedback from all of GIMP's huge user community, she might even be tricked into 
creating the required APIs.



> what I am trying now is to get beyond that. new, fresh contributors
> that can contribute a snippet (or more) of interaction design
> without demanding that they are actually interaction designers,
> or follow established interaction design processes.

sounds fun! Something like Gnome-love bugs with guidance by the UI team?!?


best regards,
yahvuu



[1] http://blog.mozilla.org/faaborg/
[2] http://www.azarask.in/blog/