[steering-discuss] Candidacy for Board: Michael Meeks

Hi there,

  I'd like to formally offer myself as a candidate for the Board
of The Document Foundation. While, as a developer I have no great
love for meetings and politics, my hope is that I'd have some useful
perspectives to offer, with time to invest into working on issues
which would enrich the board.

  Who am I ? briefly: a Christian, Hacker & Husband. I bring
lots of experience from many years at SUSE, helping to grow, lead and
hack with some of the best Free Software developers in the world. That
would allow me to bring a reasonably diverse set of skills and passions
into the board on your behalf:

  + a pragmatic love of Free Software
  + IANAL; a deep legal and licensing understanding of the
    basis of successful Free Software communities
  + developer community building / mentoring / nurturing
  + marketing and PR experience with relationships to journalists
  + deep code understanding & hacking experience
  + good relationships with many key hackers and companies
    in our space

  I've also been privileged to have lived through many
spectacular failures inside communities outside OpenOffice, such as
GNOME, or MeeGo, and hopefully gained some useful insights into
avoiding their repetition.

  I am focused, on making LibreOffice the very best, most fun
and featureful project that it can possibly be. I want us to attract
and inspire the largest number of contributors to drive Free Software
forward. Though I plan to carry on with that regardless of being a
board member, if you think I'd be valuable there then please vote for
me. I'd love to serve the membership in that way.

  Thank you,

    Michael.

Hi Michael,

Please let me start by thanking you for your past service on the SC,
and your important contributions to TDF and the LibreOffice project.

I would like to ask whether you would be willing to make a commitment
for a term of office on the BoD.

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

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. This is not yet the case with the source
code of LibreOffice.

There is no global design documentation available to someone who would
like to learn to hack it. The devs have made some progress towards
documenting the code base, but only at a more-microscopic level (the
API documentation at http://docs.libreoffice.org, for example).

But, IMHO, it would be extremely valuable to have more-global
documentation outlining the architecture and working of the code base
and its various components and modules.

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.

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?
I am thinking of something along the lines of:

- a global description of the architecture of LibreOffice;
- a global description of the architecture of the LibreOffice
programs, Writer, Calc, Impress, Draw, Math and Base;
- a listing of all the libraries and components used in the software,
and an explanation of why they are used and what they do;
- a description of the differences between the versions of LibreOffice
for *nix, Mac and Windows;
- whatever other material that your expertise as a core dev tells you
is useful and needed for genuinely opening up the source code to the
world in the broadest possible sense.

This could usefully be a collaborative initiative actively worked on
by Caolan McNamara, Thorsten Behrens and Michael Meeks.

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

In any case, wishing you all the best and, again, thanking you for
your past work for us. :slight_smile:

This could usefully be a collaborative initiative actively worked on
by Caolan McNamara, Thorsten Behrens and Michael Meeks.

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.

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.

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:

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.

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.

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

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:

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,

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:

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