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

[tdf-discuss] Re: [steering-discuss] Candidacy for Board: Michael Meeks


Hi David,

On Mon, 2011-10-10 at 15:40 +0300, David Nelson wrote:
Sorry, I just want to add this small comment/question to my preceding
posts in this thread:

        These belong on discuss - as has been pointed out. They are also rather
tangential to the role of the board IMHO - which devolves development
and release scheduling decisions to the Engineering Steering Committee.

I have been searching around, and I have not been able to find an
official development roadmap of any kind. For sure, there's detailed
information about planned release dates going far into the future [1].

        It is lovely to have a roadmap - and it is nice to have things on it,
it serves a useful marketing function no doubt. However we really need
to motivate volunteers to have fun incrementally improving the code, and
there is no shortage of useful tasks here. Our approach seems to work
for the Linux Kernel - perhaps you should go check the Linux Kernel
roadmap out to see best practise there.

If our leading devs stopped coding on LibreOffice tomorrow

        An extremely unlikely possibility, but perhaps worth considering.

we wouldn't have any idea of what kind of future plans they'd 
been working on implementing, and how far they'd advanced in
the process.

        Since the new devs that you're going to find to replace all those who
died of a mystery illness ;-) would have their own ideas as to what they
plan to work on - thus making the previous roadmap of only academic
interest. So your rational seems weak. I can believe a made-up roadmap
is worth doing for marketing though.

Does the engineering steering committee have any kind of formal
methodologies, and any kind of formal documents that it maintains?

        Emphatically not beyond our minutes. Clearly we do some informal
co-ordination of what we're working on to avoid overlap, and we have
some ideas as to the big feature holes, and problems in the code: but it
is informal. It is really easy to get included into those inclusive
discussions: get involved in hard-core hacking :-) then people will try
to persuade you to work on their pet feature etc.

Or is the future of LibreOffice simply stored in a myriad of post-its
on your computer monitors, and in your minds, and in a tenuous web of
discussion threads on the devs mailing list?

        Not at all; the future of LibreOffice is formed exclusively by
contributions that people make, and a collaboration between them that
grows organically. It adapts to meet user needs as it goes with help
from designers, QA people, documentation guys etc.

        This is anathema to large chunks of the formal, specification driven,
process ruled, waterfall style software development industry. You can go
and read huge management screeds about how evil it is to work
incrementally and without a highly granular ten year plan, with no
product management, gantt chart, etc. ;-) I meet people who simply
refuse to believe that Free Software exists - and that it can possibly
work and improve on this basis.

        However the reality is, that the best software I've seen is Free
Software, and was built without any of this overhead. It is also the
case that, in general, volunteers don't like being 'managed' or making
binding commitments to XYZ feature delivery dates :-)

        I don't plan to arrive at the docs team eg. and say: "what is your five
year roadmap for documentation ?" or "you created this fantastic
documentation - but why is it late !?" etc. ;-) I'd be rather concerned
if you had such a thing: but each to his own.

        Finally a time-based release plan is one that doesn't wait for
features. This gives confidence to distributors and developers alike,
and keeps freeze discipline without conflict. It reduces the risk of
unfortunate incentives during the development process and it appears to
work really well, not just for us - but for many other Free Software
projects that have adopted it.

        HTH,

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot


-- 
Unsubscribe instructions: E-mail to discuss+help@documentfoundation.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.documentfoundation.org/www/discuss/
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.