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

2011-10-12 Thread 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.me...@suse.com  <><, Pseudo Engineer, itinerant idiot


-- 
Unsubscribe instructions: E-mail to steering-discuss+h...@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/steering-discuss/
All messages sent to this list will be publicly archived and cannot be deleted


Re: [steering-discuss] Board of Directors Candidacy: Caolán McNamara

2011-10-12 Thread Caolán McNamara
On Sat, 2011-10-08 at 17:11 +0300, David Nelson wrote: 
> I would like to ask whether you would be willing to make a commitment
> for a term of office on the BoD.

Sure.

> I am certain that you will assure us that you support openness of the
> source code of LibreOffice.

Sure, apple pie and motherhood too.

> But I would like to put it to you that no software source code is
> truly open until it has been rendered as understandable as possible to
> as many people as possible.

err, sure, it would be nice to have source code as understandable as
possible. It might be a bit of a stretch to conclude that it's not open if
developer documentation is somewhat on the slight side.

> The solution of interested individuals gleaning knowledge by lurking
> and asking questions on IRC is not an effective and community-oriented
> method of sharing knowledge.

*shrug*, most questions are asked and answered on the mailing list,
where they can be archived so they don't have to be asked again. irc
tends towards more real time chat on specific "right now" problems
rather than a stomping ground for discussing anything indepth.

> Would you be willing to commit yourself to actively work ... on
> developing global design documentation

No. I couldn't make such a commitment.

> I am thinking of something along the lines of:
...

> Please may I ask your thoughts about this idea and whether you would
> explicitly agree to be part of it?

Well, here's what I *have* written, "lazy uno hackers guide to porting",
"default paper size selection", various bits of
http://wiki.documentfoundation.org/Development/FAQ
http://wiki.documentfoundation.org/Development/String_Classes and bits
and pieces like that. Generally stuff which gets asked of me a lot so
its less time to write it up once than repeat it on every question, or
stuff that was sufficiently difficult that I know I won't remember it
in a few weeks time.

Personally, I reckon developers hate "wrong documentation" more than
they hate no documentation. I mean, they would be compelled by their
natures to *fix* incorrect documentation far more than they could be
motivated to write correct documentation in the first place ;-)

C.

As an aside, I think we can somewhat lower the barrier to entry a good
bit here and there by removing the necessity for specific LibreOffice
documentation, e.g. there's great work underway with the various
macro-based list things to replace them with stl, so necessity to
document libreoffice-specific code goes away when its the same stuff as
found in any standard reference manual.


-- 
Unsubscribe instructions: E-mail to steering-discuss+h...@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/steering-discuss/
All messages sent to this list will be publicly archived and cannot be deleted


Re: [steering-discuss] Candidacy for a BoD seat

2011-10-12 Thread Thorsten Behrens
David Nelson wrote:
> Would you be willing to commit yourself to actively work with me on
> developing global design documentation that will be a major asset to
> any party wanting to start hacking the core and developing extensions?
> 
Hi David, all,

beyond what others said, let me add my very personal statement to
that question - I do think good documentation is an enabler. Where
I'm unsure is how to best get both good quality and up-to-date
documentation. You know that the code base is changing, and rapidly
so - and as Caolan said, nothing, not even missing documentation, is
as bad as wrong documentation.

So, I'd be committing myself to improve the developer experience -
but please let me make my own educated decision where to best spend
this effort. ;)

Cheers,

-- Thorsten

-- 
Unsubscribe instructions: E-mail to steering-discuss+h...@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/steering-discuss/
All messages sent to this list will be publicly archived and cannot be deleted