[steering-discuss] Candidacy for Board: Michael Meeks

Board Discuss
#4

Hi Jesus,

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

#5

Hi David,

Hi Jesus,

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

I think your proposal is interesting and I really see your point here,
but, at the same time, I'd create a group of people with different
skill levels to work on it. I don't deny that it will not be as
effective, but I could also be a chance for wannabe developers to
learn a lot about the project while they work in benefit of the
community.

Just my two cents :slight_smile:

#6

Hi Jesus,

I'd create a group of people with different
skill levels to work on it. I don't deny that it will not be as
effective, but I could also be a chance for wannabe developers to
learn a lot about the project while they work in benefit of the
community.

This is an important initiative and really needs time from the people
with the best knowledge to be a genuine success. We don't need wannabe
devs guessing how it works or making mistakes due to incomplete
knowledge. We need the guys at the top of the pyramid to help give us
an eagle eye's view of how the software really works. This *is*
priority work if the software is to be really open and if we are
really to attract people to work on it.

#7

Jesus,

I'm hoping to see from three of our leading devs who are candidates
for the BoD how committed they are to *Open Source* software. :wink:

Open the doors wider, and more people might come in.

#8

I do not think that this discussion should happen during the election
time, as it might have an influence on the election outcome based on
parametres which are not relevant for being a director (based on bylaws).

On the other hand, improving our documentation - in general - is a very
important objective for the entire project, and therefore I suggest to
bring this idea to the attention of the SC/BoD.

In a few days, we are going to meet face to face in Paris, and we have
the opportunity of discussing many topics.

Best, Italo

#9

Hi Italo,

I do not think that this discussion should happen during the election
time, as it might have an influence on the election outcome based on
parametres which are not relevant for being a director (based on bylaws).

I regret that I don't really agree. People are standing as candidates
for the BoD and TDF members have a right to ask questions and learn
what candidate's policies and attitudes are with regard to issues of
concrete importance to the community...

It's for sure that candidates answers to community members' questions
should indeed have an influence on the outcome of the election, no?
:wink:

#10

Hello David,

Hi Italo,

> I do not think that this discussion should happen during the
> election time, as it might have an influence on the election
> outcome based on parametres which are not relevant for being a
> director (based on bylaws).

I regret that I don't really agree. People are standing as candidates
for the BoD and TDF members have a right to ask questions and learn
what candidate's policies and attitudes are with regard to issues of
concrete importance to the community...

It's for sure that candidates answers to community members' questions
should indeed have an influence on the outcome of the election, no?
:wink:

I'll let the candidates you have asked your question to answer. I had
one question for you though: will you be in Paris next week?

Best,

#11

Hi Charles,

I'll let the candidates you have asked your question to answer. I had
one question for you though: will you be in Paris next week?

Sadly not. :frowning: I'm wrapped up in a client project for which the
deadline is the 14th, and the geographical distances between us would
not allow me to make it there on time... :frowning:

#12

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

#13

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:

#14

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:

#15

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:

#16

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

#17

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:

#18

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

#19

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

#20

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

#21

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.

#22

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

#23

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,

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.