[steering-discuss] Candidacy for Board: Michael Meeks

Sorry, I just want to add this small comment/question to my preceding
posts in this thread:

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].

But I don't find any information about what changes are planned to the
general architecture of LibreOffice.

If our leading devs stopped coding on LibreOffice tomorrow, not only
would we not have any design documentation explaining how the beast is
architectured and how it works, but 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.

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

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?

[1] http://wiki.documentfoundation.org/ReleasePlan

Hi Michael,

Thank you for taking time out to give me those interesting answers.
Lots of food for thought there, as has been the case in the past after
discussing with you.

I'll be arming up for work on the online help and the code base in the
near future, and will pop up on IRC at that time. And I'll be coming
back to the subject of design docs on the discuss list, with ideas and
questions.

Again, thanks for the time, and have a good conference. :slight_smile: I so much
regret I won't be there with you guys.

Hi David,

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 :wink: 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 :slight_smile: 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. :wink: 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 :slight_smile:

  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. :wink: 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.