On Wed, 09 Mar 2011 22:16:48 +0100
Bernhard Dippold <email@example.com> wrote:
Hi Björn, all,
Bjoern Michaelsen schrieb:
Hi Michael, Christoph, designers and developers
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.
I agree with you that the design modification here is an example of
Priority is not the point. Please have a look at that wiki page. It is
more about that this (most small design issues) are something most
people have an opinion about, regardless of if they are designers,
developers, both or neither.
But the way one of the main developer seems to disregard non-coding
community members is independent from this question.
No, I dont think that it is correct to put it that way: This is _not_ an
developer/nondeveloper issue. We currently have a very open model for
contributors on master and as I understand it, we want to keep it that
way to allow others to join in easily -- this is one of the
foundations of TDF/LO. This is not only the case for design issues, but
for all topics.
If somebody has something he thinks of as a great improvement, he can
commit that to master. If it breaks stuff, it will be reverted. If it
improves stuff, even if it does not make things perfect it stays in. If
there is a plan how to make things even better, that of course should
be done -- but you will not ever force volunteers to do it. It just
wont work (unless you pay them).
Nobody -- developer or nondeveloper -- should be able to block anybody
from doing a Good Thing(tm), just because he wants a Better Thing(tm).
And dont think that developers are so much more special than
nondevelopers: Even if I had twenty fulltime developers at my disposal
(in addition to myself), I would not get everything done I would love
to see changed. There is always more.
I see commits fly by every day that I would have done different. But
the only relevant question is: "Is it at least better than before?".
From your other mail:
For a developer interested in working on a certain topic it would be
easier to get a final voting like
"The Design Team asks you to add a 8 px wide blurred shadow in grey
transparency to all borders of the document. If the zoom factor
reduces the space between two sheets to less than 16px, the
overlapping areas of the shadow should be cut off. This should apply
to every area of LibreOffice, where document borders are visible,
namely Writer, Impress, Draw, XML forms [others not yet searched
I am afraid you are very wrong there. It is not at all easier -- it
is a lot harder -- and a lot less fun (the stuff that motivates
volunteers). To give you a car analogy (which are always broken, but
anyway), the statement above would be like telling a taxi driver not
where you want to go, but which route to take, when to changes lanes,
when to go faster or slower and when to change gears. You can do that
with a taxi driver, but he likely will not like it.
You better should not try it with a driver, who volunteered to get you
where you wanted to go. On the first ride, you should mostly just go
along with what he does (unless he drives you of a cliff). Before the
second ride, prepare to suggest improvements to him. If he is a
reasonable guy, he will listen to you -- esp. if you have a record of
being right about these things.
Unsubscribe instructions: E-mail to firstname.lastname@example.org
List archive: http://listarchives.libreoffice.org/www/design/
*** All posts to this list are publicly archived for eternity ***
[libreoffice-design] Re: [PUSHED] fdo#31251 - Improve default page layout · Bjoern Michaelsen
Re: [libreoffice-design] General relationship between coders and designers (was: [PUSHED]fdo#31251...) · Bernhard Dippold
- Re: [libreoffice-design] Re: More general stuff (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