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


Which is all why I didn't propose that we do it straight away.  We all
agree that the UI needs an overhaul, and if there is a dedicated person/s
that work on a spec we can have a Citrus UI spec together relatively
quickly. the problem is that the majority of us have day jobs and other
aspects of lives to take care of to concentrate on writing such a broad
spec.   After the spec has been writen we would then need the devs to put
together a working prototype of the UI to test and then to modify and
re-implement the spec of.  All of which points back to my original plan of
having a crew of devs create the UI as a pre-/alpha version of LibO 4 while
LibO 3.x continues independently of those UI changes

On Sun, Dec 11, 2011 at 2:39 PM, Charles-H. Schulz <
charles.schulz@documentfoundation.org> wrote:

Hello all

I wanted to address two questions because I think they're important. One
will make some grit their teeth and the other will hopefully help to
understand how things work inside the LibreOffice project and in other FOSS
projects as well.

* The notion that somehow we should just "redesign" the whole suite and in
two releases we would get a beta obviously shows that someone does not even
take the time to read what others actually wrote on this list, and then
asking what a specification is also tends to point out that while opinions
can be shared, they won't all be helpful. In Free Software (but this could
be applied to several other fields as well) people contribute their time
according to their abilities and skills. Some are developers and develop
code. Some others test the software through various processes for quality
assurance. Some others work in the infrastructure (website mirrors, etc.)
Some others write documentation, while others localize (translate) the
software. For some projects (not all), there are marketing people who write
press releases, do market research, etc.  And there are as well designers
and User Experience people; the former contribtue designs (generally it's
the logo, or help with the website, etc.) and when it comes to the User
Experience (UX for short) they study the whole usability of the software
and then propose changes. The way they propose changes is by describing in
full detail the change in question in a document called a specification.
The reason they do this is that they want to document what they actually
want so that others -the developers, the localizers, the documentation
writers, sometimes the QA people and even the marketing team- can
understand what they mean. The people who will be the most interested by
the document will be the developers because you can show lots of pictures
to a developer he's going to need a heck of a guidance to assess what is to
be exactly done.
If you don't have a spec, your wishes simply will not even be ignored; it
will be like talking a foreign language no one in the room is able to
understand. Thus, anyone who thinks we "just have to do it instead of
bickering" is not just wrong, he's also lacking respect to the actual UX
people trying to write specifications and to the developers. Unless
someone's here a genius who has gotten exactly what the two Alex, Mirek,
Kevin and others want and is able to code these changes right away, things
will  not be working "just like that". If you want to code, go ahead and
pull the git. If you want to work on design, go ahead, join the team and
work with us. If you're just here for the sake of voicing your opinion then
please be aware that this is a specialized mailing list;
discuss@documentfoundation is much better suited to your needs.

* There was the question of volunteers/money. It's an important, yet a
tricky one sometimes. It was pointed out before that we're all volunteers;
that's for a great part true. Some of our most active developers are
actually employed by various companies (check our sponsors)  for what they
do. In any case, the need has been seen, in some cases, that having
volunteers to work on specific tasks and projects might actually not be
enough, as these volunteers also have a day job. If they're skilled and
knowledgeable enough and that the task at hand is daunting, you want to get
the job done in a consistent way; or to put it simply: "it'll go easier if
some people just could stop wondering how to pay their bills and eat so
that they can dedicate their full time to the job here".So sometimes, you
can propose to raise funds for a specific task and pay a certain number of
people (actually in FOSS projects it's developers 99% of the time) to
complete one or several specific tasks. The whole point is that it's meant
to be temporary and exceptional (otherwise it could be argued you simply
need more volunteers).  I hope it's helpful...

Best,
Charles.

--
Unsubscribe instructions: E-mail to design+help@global.libreoffice.org
Problems?
http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be
deleted




-- 
Sean White,
Within Temptation - Your Argument Is Invalid

-- 
Unsubscribe instructions: E-mail to design+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

Context


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.