[steering-discuss] Candidacy for Board: Michael Meeks

But here you are taking advantage of the fact that these candidates
happen to also be core developer to corner them.
Their candidacy to the Board and the task they propose to tackle is
completely orthogonal to your proposal, the best proof is that you did
not ask such commitment from Italo.

Norbert

Hi Norbert,

But here you are taking advantage of the fact that these candidates
happen to also be core developer to corner them.

Of course. :slight_smile: That's "politics" right? But seriously, this is - to
me, a non-dev but someone who would dearly like to be able to step
across the threshold - a crucial issue. Perhaps established devs do
not see it like that. But, as a technical documentation professional,
perhaps I see it in a different light.

In any case, I can tell you - and you perhaps already know this well
through your own work - in a commercial environment, programmers are
generally expected - *contractually required* - to properly document
their product, especially from the design and maintenance viewpoint.

For me, the LibreOffice project can only gain in credibility and
numbers of "hackers" from having design documentation that opens the
doors to a much larger number of code contributors and maintainers.

Fed up with hearing people demanding features that can't be
implemented or that you don't have time to implement? Provide good
design documentation and a) they might understand better the reasons
for the non-feasibility or b) they might start offering more patches
and practical contributions to implementation.

I realise that some people will feel that this design documentation
will be a non-optimal usage of valuable core dev time, and will hold
up (only slightly) dev work.
But I am convinced that it will bring real fruits in terms of
contributor recruitment - more individual hackers but also
enterprise/organizational contributors.

I also feel it will enhance the project's image and credibility, and
will set an important example in the Open Source community in general
and to our audiences in particular.

The availability of decent design documentation can certainly be a
deciding factor for many potential organizational and enterprise
adopters.

Their candidacy to the Board and the task they propose to tackle is
completely orthogonal to your proposal, the best proof is that you did
not ask such commitment from Italo.

Sincerely, I feel that, as a TDF member, I have every right - duty
even - to inform myself about the policies and attitudes of the
candidates, and to see what their responses are to my specific
requests.

Voilà, with a friendly smile. :slight_smile:

Hi :slight_smile:
One of the top priorities for the Documentation Team right now is a guide to help people that want to start programming for LibreOffice.

There is already a good one for Extensions but most of the scattered things we have for programmers are apparently for OpenOffice when it was under Sun.  LibreOffice has significantly improved things, for example the "Easy Hacks" and probably details about the infrastructure and work-flow.

At the moment the Docs Team can only point to
http://wiki.documentfoundation.org/Documentation#Other_Documentation_and_Resources
Regards from
Tom :slight_smile:

Hi, :slight_smile:

Minor addition after a few hours sleep and before starting work:

This kind of design documentation is really essential for various reasons.

What would happen if there was some kind of disaster and we were to
lose the essential core of our lead devs for some horrible reason?
We'd be scuppered. Among the other members of the LibreOffice project,
is there anyone who knows how the thing works? Is there any record,
useable by a non-geek, of the state of evolution of the code base?

We say that people are free to take the source and do what they want
with it, but - at the moment - they'd have to reverse engineer the
whole code base. How "open" is that?

No, I apologise for insisting, and I realise that this initiative will
take some initial footwork, and will require on-going maintenance, but
it really should be considered to be essential work.

But I firmly believe there will be a pay-off in quite a few ways.

In any case, I'll be at the next couple of SC/BoD meetings to follow
up and discuss the idea.

Bonne journée, les amis. :slight_smile:

Hi, :slight_smile:

Minor addition after a few hours sleep and before starting work:

This kind of design documentation is really essential for various reasons.

What would happen if there was some kind of disaster and we were to
lose the essential core of our lead devs for some horrible reason?

Seriously ? for a distributed open source software, _that_ is your
doomsday scenario ?
If that were to happen, it would probably means that your immediate
problem would be survival: finding food and shelter. Computer software
will be the least of our problem for few generations...

We'd be scuppered. Among the other members of the LibreOffice project,
is there anyone who knows how the thing works? Is there any record,
useable by a non-geek

No amount of documentation will turn a 'non-geek' into a core dev.
Clean, well written code, with the least amount of 'trick' is the best
documentation: It is by definition accurate, complete and
authoritative. Quality that no Documentation ever equaled no matter
how much effort you put into it.

, of the state of evolution of the code base?

We say that people are free to take the source and do what they want
with it, but - at the moment - they'd have to reverse engineer the
whole code base. How "open" is that?

Reading source code is not 'reverse engineering'... That is what any
software engineer do on a daily basis to maintain existing code.
It is 'open' because anyone have access to the source code and
therefore _can_ read it and figure out how it works (or doesn't).

No, I apologise for insisting, and I realise that this initiative will
take some initial footwork, and will require on-going maintenance, but
it really should be considered to be essential work.

But I firmly believe there will be a pay-off in quite a few ways.

In any case, I'll be at the next couple of SC/BoD meetings to follow
up and discuss the idea.

There is no need for that. You can find volunteers and start working
on that without the blessing of anyone. It _is_ free software, and
_this_ is a meritocracy.
If you _do_ something in that line -- the wiki is a perfect place for
you to make that work available and gather with like minded volunteers
-- no-one will get in the way.

What do you expect the BoD to do ? issue an Edict ? Give you a
size-able budget to hire technical writer ? If your proposal attract
people from the community (our even better attract new people to it)
then your proposal will become reality, regardless of the BoD opinion.
That is how it is supposed to work.

Norbert

Hello Norbert,

Seriously ? for a distributed open source software, _that_ is your
doomsday scenario ?
If that were to happen, it would probably means that your immediate
problem would be survival: finding food and shelter. Computer software
will be the least of our problem for few generations...

Let's not get side-tracked. The contingency could be anything. But the
need for proper documentation remains. For instance, it might be
needed by a group of developers wanting to start an auxiliary project
investigating a different path for development than being followed by
the main track. BTW, this does not necessarily mean a fork, before I
hear the word used.

No amount of documentation will turn a 'non-geek' into a core dev.
Clean, well written code, with the least amount of 'trick' is the best
documentation: It is by definition accurate, complete and
authoritative. Quality that no Documentation ever equaled no matter
how much effort you put into it.

No, the very best is clean, well-written code accompanied by
good-quality documentation. Sorry, you will not convince me that
design documentation is unnecessary.

Reading source code is not 'reverse engineering'... That is what any
software engineer do on a daily basis to maintain existing code.
It is 'open' because anyone have access to the source code and
therefore _can_ read it and figure out how it works (or doesn't).

Trying to figure out from zero how a system works, because there is no
documentation of the code base, is indeed reverse engineering. A
software project that has no design documentation to enable a proper
and facilitated understanding of its code base is *not* fully
implementing the best principles of an Open Source project. Ask the
FSF for an opinion about this.

No, I apologise for insisting, and I realise that this initiative will
take some initial footwork, and will require on-going maintenance, but
it really should be considered to be essential work.

But I firmly believe there will be a pay-off in quite a few ways.

In any case, I'll be at the next couple of SC/BoD meetings to follow
up and discuss the idea.

There is no need for that. You can find volunteers and start working
on that without the blessing of anyone. It _is_ free software, and
_this_ is a meritocracy.
If you _do_ something in that line -- the wiki is a perfect place for
you to make that work available and gather with like minded volunteers
-- no-one will get in the way.

No, I am not going to s*d off and reverse engineer the code base
myself. I am asking three of our leading devs whether they would be
willing to collaborate with me on this perfectly-justifiable
initiative.

What do you expect the BoD to do ? issue an Edict ? Give you a
size-able budget to hire technical writer ? If your proposal attract
people from the community (our even better attract new people to it)
then your proposal will become reality, regardless of the BoD opinion.
That is how it is supposed to work.

I put my question to three of our leading devs, and I will wait for
them to reply to the original posts.

Sorry, Norbert, but your responses do not change my views in any way.

Your arguments resound with the sideways logic and suave patter of a
dishonest used car salesman combined with the moral values of a
larcenous banker. :smiley:

(Above to be read tongue in cheek with a smile.)

Nonetheless, have a good Sunday. :wink:

To give you an idea of the kind of collaboration I'm proposing to our
leading devs, you could read this Wikipedia page:

http://en.wikipedia.org/wiki/Software_design_document

Hi David,

David Nelson wrote (08-10-11 16:38)

In my opinion, I don't think it's best for the project to put some of
the most skilled developers to work in documentation, when other
developers can also do this task perfectly well.

It is precisely these guys who could put the most effective work into
this initiative, and probably the fastest.

I'm asking the potential
future members of the BoD to lead the way on this.

I see no link between the role of the BOD and individual members making commitments to certain day to day tasks.
Is there something why I should, in your opinion?

Documentation is
always considered to be some kind of unnecessary-to-optional
accompaniment to software -- unless you're some poor blighter trying
to understand how the thing works.

When I directed some people new on LibreOffice hacking to the various developer wiki pages, they were positively surprised.

Hmm, I do not want to say that there is no room for improvement, but as said: commitment on that topic is IMO not the item to consider when talking to an individual candidate for the BOD.
Pls note: I did not make any remark about the work done by, or commitment of, Michael or any of the other devs on this area :wink:

Regards,
Cor

Hi Cor,

I see no link between the role of the BOD and individual members making
commitments to certain day to day tasks.
Is there something why I should, in your opinion?

I don't see anything incongruous about asking a candidate in the Board
of Directors election about what commitments he might be willing to
take on if elected. In fact, what else are you supposed to ask of
candidates?

When I directed some people new on LibreOffice hacking to the various
developer wiki pages, they were positively surprised.

Surprised? Or do you mean shocked and amazed at how little developer
documentation there is about a major software project that has been
developed for so many years? :smiley:

I'm quite surprised you seem equate the very little content on the
wiki to a useful provision of design documentation. In fact, there is
little more than basic tips and instructions about compiling the code
and a few other related issues. There is also a very small amount of
API documentation at http://docs.libreoffice.org.

I'm sure you'll agree that there is absolutely no design documentation
of the kind I'm discussing (see [1]). There would be many advantages
to developing some.

I am putting this question before Michael, Thorsten and Caolan
because, AFAIK, they are full-time, senior project members (sponsored
by Novell, Suse and Red Hat, if I'm not mistaken), who most certainly
have the greatest knowledge about LibreOffice's design and code base.

They are the ideal people to work on design documentation, and I'm
volunteering to work hard alongside them (without any suggestion of
payment or sponsorship).

It would be a major contribution and example to the community if they
were willing to provide some time and expertise for this.

I don't think I need to repeat the multiple other reasons why I think
it's worth devoting some time and effort to this initiative, so I'll
sit back and wait to see what answers might be forthcoming from the
three BoD candidates I was originally addressing. :wink:

[1] http://en.wikipedia.org/wiki/Software_design_document

Hi David,

David Nelson wrote (09-10-11 13:30)

I don't see anything incongruous about asking a candidate in the Board
of Directors election about what commitments he might be willing to
take on if elected. In fact, what else are you supposed to ask of
candidates?

Taking care for documentation, is not a task of an individual member of the BOD, as far as I know.

Hello Norbert,

No amount of documentation will turn a 'non-geek' into a core dev.
Clean, well written code, with the least amount of 'trick' is the best
documentation: It is by definition accurate, complete and
authoritative. Quality that no Documentation ever equaled no matter
how much effort you put into it.

No, the very best is clean, well-written code accompanied by
good-quality documentation. Sorry, you will not convince me that
design documentation is unnecessary.

I'm not trying to convince you of anything. I'm merely giving you my
opinion, grounded on having been in the trenches, designing software
and writing code for a living for the past for 20 years...
Anyway, I am apparently in good company: http://kerneltrap.org/node/5725

"A "spec" is close to useless. I have _never_ seen a spec that was both big
enough to be useful _and_ accurate." Linus Torvalds

I'd also refer you to :
http://www.agilemodeling.com/essays/agileDocumentation.htm#ProjectSuccess

[..] code base is *not* fully
implementing the best principles of an Open Source project. Ask the
FSF for an opinion about this.

I've been hacking gnu make recently... please do point me to such
documentation (no, not the _user_ documentation, the supposedly
indispensable 'design spec' )
so... I don't know about their opinion, but I do know about their practice...

No, I am not going to s*d off and reverse engineer the code base
myself. I am asking three of our leading devs whether they would be
willing to collaborate with me on this perfectly-justifiable
initiative.

We must have a different definition of 'collaboration' than me.
If you you are "not going to s*d off (what-ever that means) and
reverse engineer the code base" yourself, it sound that you conception
of collaboration is 'do as I said... I'm watching', or as we say in
french 'Armons-nous et partez"

What do you expect the BoD to do ? issue an Edict ? Give you a
size-able budget to hire technical writer ? If your proposal attract
people from the community (our even better attract new people to it)
then your proposal will become reality, regardless of the BoD opinion.
That is how it is supposed to work.

I put my question to three of our leading devs, and I will wait for
them to reply to the original posts.

Then this is the wrong list... if you want to ask devs, you should do
that on the dev mailing list.

Sorry, Norbert, but your responses do not change my views in any way.

I have no such hope. I merely re-stated to you the reality of a
volunteer based effort. If you want something to happen, you need to
roll-up your sleeves and _make_ it happen.
Trying to extract election promises out of some people, on ground
completely unrelated to the office they seek, is not going to get you
there.

Your arguments resound with the sideways logic and suave patter of a
dishonest used car salesman combined with the moral values of a
larcenous banker. :smiley:

(Above to be read tongue in cheek with a smile.)

You can add all the smiles you want to an insult it is still one.

Norbert

Norbert Thiebaud wrote (09-10-11 14:25)

Trying to extract election promises out of some people, on ground
completely unrelated to the office they seek, is not going to get you
there.

Correct.
I would assume (have seem some mails swiftly after posting my initial contribution to this thread) that there has been some exchange on the usefulness of documentation and such.
Would people like to continue: IMO not on this list.

Regards,

You're asking a development question that's not among the duties of a member of the Board of Directors. You're obviously welcome to ask community members about your project proposal, but I suggest you wait until after the election. Appropriate questions for candidates relate to their suitability to perform the duties of a Director of The Document Foundation[1], which definitely and intentionally do not include developing the code or the documentation.

S.

Hi,

Norbert Thiebaud wrote (09-10-11 14:25)

Trying to extract election promises out of some people, on ground
completely unrelated to the office they seek, is not going to get you
there.

Correct.
I would assume (have seem some mails swiftly after posting my initial
contribution to this thread) that there has been some exchange on the
usefulness of documentation and such.
Would people like to continue: IMO not on this list.

Norbert, it would be good if you read things carefully and accurately.
Cor, it would be good if you did not jump to conclusions.
Norbert and Cor, it would be polite and in keeping with the bylaws and
election rules if you allowed me to put my questions to the candidates
without butting in.
Thank you, guys.

Hi Simon,

You're asking a development question that's not among the duties of a member of the Board of Directors. You're obviously welcome to ask community members about your project proposal, but I suggest you wait until after the election. Appropriate questions for candidates relate to their suitability to perform the duties of a Director of The Document Foundation[1], which definitely and intentionally do not include developing the code or the documentation.

The candidates invited questions. I am asking mine. Are you guys censoring me?

I am indicating that questions about development plans and intentions fall outside the scope of questions for Board candidates as regards their suitability for election, as the role of directors[1] does not include development tasks. I'm inviting you to note that observation and save your valid but out-of-scope question for later. I am not censoring you at this point as I hope you will choose to desist voluntarily.

Thanks

S.

Hi Simon,

I am indicating that questions about development plans and intentions fall outside the scope of questions for Board candidates as regards their suitability for election, as the role of directors[1] does not include development tasks. I'm inviting you to note that observation and save your valid but out-of-scope question for later. I am not censoring you at this point as I hope you will choose to desist voluntarily.

I have put my questions to the candidates. I am hoping that they are
going to answer.

I object to your arbitrary judgement that my questions are out of scope.

They are perfectly reasonable, perfectly friendly and perfectly
courteous questions, in response to an invitation to ask questions.

I hope you are not going to blemish this first election with
thoughtlessness and unnecessary declarations that go against the
freedom of expression that the bylaws stand for.

It would have been so much simpler if the candidates had been allowed
to answer for themselves.

Hello David,

Hi Simon,

I am indicating that questions about development plans and intentions fall outside the scope of questions for Board candidates as regards their suitability for election, as the role of directors[1] does not include development tasks. I'm inviting you to note that observation and save your valid but out-of-scope question for later. I am not censoring you at this point as I hope you will choose to desist voluntarily.

I have put my questions to the candidates. I am hoping that they are
going to answer.

I object to your arbitrary judgement that my questions are out of scope.

They are perfectly reasonable, perfectly friendly and perfectly
courteous questions, in response to an invitation to ask questions.

I hope you are not going to blemish this first election with
thoughtlessness and unnecessary declarations that go against the
freedom of expression that the bylaws stand for.

It would have been so much simpler if the candidates had been allowed
to answer for themselves.

No big and high words please :slight_smile:
What we're trying to say is that the functions of a BoD member do not
relate to these matters. Your question is indeed valid but is simply out
of context, because it is not up to the BoD members to decide these
questions or to take part in this kind of work because they would be BoD
members. That's all...

Best,
Charles.

I'm disappointed, Charles. Quite disappointed...

Hey, cool it. No-one is stopping them answering; I'm explaining why they are
not. Please read what I wrote calmly and, if you still don't understand the
point, get back to me.

S.