Re: [libreoffice-design] Re: Impress Mode Toolbar

Le 14/01/2016 15:26, V Stuart Foote a écrit :
> Michel RENON-2 wrote
> > ...
> > [resent to the ml]
> > Currently, some design changes are merged asap in master, just because
> > the code is ok.
> > Then during alpha or beta, some user feedback is coming, but it's
> > already too late to make changes in code...
> >
> >
> > Why not working on those changes in specific branches ?
> > and take time to have user feedback and iterate.
> >
> > And only when everything is ok (ui, code), it is merged in master with
> > the usual process
>
> Maybe ask the remaining AOO folks how that development model is working for
> them?
>
> IMHO this would be a horrible regression from a developers perspective. It
> would kill the project's timed release ethos, and stifle innovative code
> development and ongoing refactoring of our long code tail.  It would be
> detrimental to the long term health of the project and likely ultimately
> kill it.

Let me clarify :
I absolutely don't want to change the time based releases (every 6 months).

I just mean to merge design changes in master when they have been 
validated (by design team, by user testing).
So, if a design change is not complete for version N, it will be merged 
for version N+1 (+6 months). that's all.

Today, there is a strong process to validate code : developers work on 
some branches, until they reach good quality level, then they ask for 
merging in master : gerrit, automatic compilation, automatic tests, 
reviews by core devs ; and that's ok and absolutely necessary.

My wish is to have a similar process for design changes.

As it's not ok to merge alpha-quality code to master, it should not be 
ok to merge alpha-quality design in master.

That's what happened for the 'new template manager' for LO4.0 : it was a 
painful time because design was incomplete and incoherent.
And important feedback were made during beta, that created changes at 
the last minute : developers were in hurry. So users of LO4.0 had a 
alpha-quality design.
And some regressions that are still not corrected :
https://bugs.documentfoundation.org/show_bug.cgi?id=60589

Same problems for new start center for LO4.2 : user feedback while beta, 
last-minutes changes. I proposed to postpone it to 4.3, to give enough 
time to designers and devs to correct it [1]. But it was too late : it 
was merged in master and already in string or feature freeze...


IMHO, it won't kill LO, it would enhance its perceived quality.
And it would reduce work of translation and documentation teams : they 
would have to handle less versions.



What is fun is that two time I said "postpone ONE functionality to next 
version (+6 months)", people understood "revert WHOLE LibreOffice to a 
release-when-ready". Is my written-english so bad ??


[1] http://listarchives.libreoffice.org/global/design/msg06280.html

> The truth is the success of LibreOffice has come in large part from exactly
> the welcoming meritocracy in development that has emerged.  Few question it
> is a better product than the alternatives, but it keeps its relevance
> because of the development model and functional cross platform support.
>
> Are there hicups--design, UI and UX--absolutely! That keeps it fun for the
> developers.

Sorry, I can't agree :
as a developer and designer, my focus is users.
And the only way for me to have fun is to have for every release :
- all problems solved / no regressions
- happy users

I hardly can't imagine why it is fun for developers to ship software to 
millions of users that have hiccups/problems to be solved in the next 
6-month-release...
Is it really the common way of thinking in FOSS ?



Michel


--
To unsubscribe e-mail to: design+unsubscribe@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