On Tue, 15 Mar 2011 00:11:48 +0100
Bernhard Dippold <firstname.lastname@example.org> 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 ?
*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
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
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
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
* 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
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.
Unsubscribe instructions: E-mail to email@example.com
List archive: http://listarchives.libreoffice.org/www/design/
*** All posts to this list are publicly archived for eternity ***
- Re: [libreoffice-design] Re: [PUSHED] fdo#31251 - Improve default page layout (continued)
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy