Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index

Hi Michael, Christoph, designers and developers

On Tue, 08 Mar 2011 12:05:22 +0000
Michael Meeks <>

      We finally get a competant, enthusiastic, motivated developer
- actually fixing our horrible user interface problems: and he does
some great improvement - and our design guys apparently emit a long
stream of complaining left and right ! That, if true, is hard to

However, it is a such a common issue, that it even has a name
"Parkinson's Law of Triviality" or "colour of the bikeshed":

So we should not be ashamed that it happens, only be prepared to handle
it well. For developers this means that you cant make everybody happy
and you should not dispair if not everybody loves your implementation
on first sight.

For nondevelopers it means you should have to build a consensus in a
larger group (best including some trusted grognard of the project). If
each nondeveloper directly approaches a developer alone with their
contradicting ideas(*), that poor confused developer will have a hard
decision to make, which might even be outside his expertise. He might
even innocently build a compromise which pleases nobody ("I will
implement the wings from the plane proposal, but to make the ship
proponents happy too I will also add a sail to our vehicle"). So if you
see a change in an area you are interested in: The one thing a
volunteer developers will love to hear would be:

"Awesome! Way better than before. I will sit down with some other guys
to discuss how to even make it better and we will get back to you with
a proposal when we found a consensus!"

It you think it is actually worse than before, the first thing to find
out is if you are alone with that opinion. If you are not, team up and
create a proposal.

On Tue, 08 Mar 2011 18:42:05 +0100
Christoph Noack <> wrote:
So here a short takeaway:
      * Please ping us in any case if you need something
      * Have also in mind that some of our members are new and also
need some time to get settled --> expect personal likings, relax and
        wait for a mature outcome
      * If you require a decision more quickly, or if you're unsure
        about the current state, then please feel free to bother
us ...
      * Over the time we'll get to know each other ... and you'll know
        whom to trust ;-)

Agreed, as with the rest of you post, with one slight modification: I
see little reason why a developer should not start working on an issue
like this(**) even before there is a final decision.

Personally, I think the bug #31251 should stay at least RESOLVED -
WORKSFORME until there is a clear specification of how exactly it
should be done different. At _that_ point the bug should be reopened,
but before that there is no open bug, because the discussion might very
well end with no consensus, or the consensus is "current solution is

Oh, and as a sidenote: It would be a good idea to link to the discussion
in the bug otherwise it will be repeated half a year later.

Best Regards,


(*) Keep in mind that even simple statements like "this is very
important" can be contradicting. Somebody else might find something
else way more important.

(**) If the issue is a major feature requiring lots of interdependent
changes, that is a different issue.

Unsubscribe instructions: E-mail to
List archive:
*** All posts to this list are publicly archived for eternity ***


Privacy Policy | Impressum (Legal Info) | Copyright information: 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.