Re: [libreoffice-design] General relationship between coders and designers

Hi Bernhard,

On Tue, 15 Mar 2011 00:11:48 +0100
Bernhard Dippold <bernhard@familie-dippold.at> wrote:

> > > Please wait for the decision by the Design Team and we would be
> > > very glad if you could implement the resulting graphical
> > > approach by a  patch.
> >
> > Again - the code was merged day #1, then these 'fixes' were merged
> > week #2, and we are not blocking on the advice of the design team.
> > Clearly if something -really- upsets them we will back out the
> > changes. Clearly if -everything- upsets the design team, and we
> > find ourselves in some constant conflict - the design team's crying
> > will start to become normal background noise, and have rather less
> > impact. That is how relationships work right ?
>
> Not really:
>
> *If* the design team would be upset by any UI related development, it 
> would be worthwhile to find out the reason for such feelings.
>
> Just skipping them as "normal background noise" is far too easy and 
> indicates an attitude of ignorance for the broader community: This is 
> exactly what I called "two classes"...

No, that is not an "attitude of ignorance for the broader community"
and no "two classes" issue. If introduce a pink button in LibreOffice
and get flamed for it by any single person (coder or noncoder) a
few minutes later because he would prefer it in bright green, I would
likely ignore it (speaking of master, not a release branch obviously).
Otherwise I would not be making any progress at all or just be changing
the same colors over and over again.

If I get a link to a discussion on a mailing list a week later showing
consensus of the design team that bright green is indeed better than
pink in this case, I would change that. And I would expect the design
team to defend that decision and keep the discussion away from me from
that point on (that includes links to the discussion in the relevant
places).

Would I take the word of a trusted UXer without waiting a week? I
might, esp. if I get the feeling that I will end up changing the stuff
anyway or if there is a deadline (like a release branchoff) looming.

This is a lot different for most implementation issues, as consensus
there is often immediate. But this has to do with the topic and not
with "classes".

> That's a topic that really needs interaction and decision making 
> *before* someone starts coding IMHO.

In most cases not. Most design choices are easily changed and tweaked
afterwards, but the hard part is enabling them to be tweakable at all.
Starting on the code will also show you what is easy to do and what is
hard -- an information you can only afford the luxury to ignore, if you
have unlimited resources.

> While this doesn't mean to hinder contributors from providing their 
> work, it is neither a reason to disqualify discussions leading to 
> consensus and decisions as "long stream of complaints", allowing the 
> contributors to ignore it, just because "they don't see it as useful
> input".

As long as there is no consensus, a coder can not derive _any_ valid
action from the discussion, so the only reasonable action is to ignore
it for his coding decisions. Any objections to that conclusion?

He might prepare his coding for likely outcomes, but that is guesswork.
He might also take part in the discussion, but that is independent from
his coding work (modulo his expertise on what is doable).

> So in a short term:
>
> * Every community member deserves the same respect for his
> contribution.
>
> * No contributor should be hindered to contribute in a way that
> brings LibreOffice forward.
>
> * No contributor should be told that his opinion is more valid than
> the recommendations of experts in their dedicated fields (but she is
> free to convince them).
>
> * If the contribution might interfere with general community goals or 
> agreed ways to reach these goals it might be handled like code 
> introducing bugs in other areas of the product. This will probably
> lead to modification of the contribution - in very seldom cases to
> rejection.

I agree mostly. However "experts in their dedicated field" is rather
vague and can be misused easily regardless of the "field" being coding
or UX. I would much prefer "community consensus", which -- while
being equally vague -- at least does not introduce the exact "two
classes" (experts/nonexperts) issue described above.

Best Regards,

Bjoern

-- 
https://launchpad.net/~bjoern-michaelsen

-- 
Unsubscribe instructions: E-mail to design+help@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/design/
*** All posts to this list are publicly archived for eternity ***