[steering-discuss] Candidacy for Board: Michael Meeks

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.

David Nelson wrote (09-10-11 14:55)

Norbert, it would be good if you read things carefully and accurately.
Cor, it would be good if you did not jump to conclusions.

David, it would be good if you just understood the point :wink:

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.

It is not about stopping you or anyone else to ask questions. It is about whether this question is relevant for the elections.

Trying to explain it again in other words:
The BOD is about steering the foundation.
Might the opinion in the BOD be, that there is a problem in e.g. the documentation area, then they will do what is within their means to improve the work in that area.
Whether an individual wants to work on documentation, is not related to ones candidacy/membership of the BOD.

It might be relevant to know if an individual finds documentation important, and maybe also if she thinks improvement in that area is a good idea. But again, that is not the same as that individual working on (in this example) on documentation.
On the contrary: if the BOD thinks more documentation is needed, they try to find others (i.e. people not in the role as BOD member) willing to step in and do the job.

Cheers,

Cor,

Apparently you enjoy an argument. :smiley:

I wasn't going to write further to this thread, but apparently you
need to have the last word, and I don't see why you should. I'll
explain why below.

My only mistake in writing to the candidates was that I continued in
the threads they started on this SC list, and election rule #6 says,
"All discussion related to the elections should be held on
discuss@documentfoundation.org. Members are invited to ask questions
to one or all candidates on that list."

But that's maybe the candidates' fault, too, because I guess they
should have posted their candidate statements to the discuss list
rather than the SC list. No matter, further discussions about the
original subject can be continued there.

However, I just re-read the election rules and the bylaws, and there
is absolutely nothing to say that the questions I asked Thorsten,
Michael and Caolan were out of order. So you have absolutely no
justification in trying to lay down the rules about this.

This is an election, right? And the candidates are asking for our
votes and invited our questions, right? So I would say I'm entitled to
ask them whatever is close to my concerns and interests. And, for
their part, they have the right to answer what they like, or even not
to answer at all if that's their preference.

The rules that we all have to keep to are the rules of courtesy,
friendliness and decent behavior. From that viewpoint, I'm perfectly
within bounds.

So why do you feel that I'm only allowed to broach subjects that *you*
feel are acceptable? Don't you feel you're a little out of line here?
Because I definitely think you are.

I'm rather disappointed by the development of this thread.

And I don't think it was a welcome event in the first BoD election.

Please allow me to remind you of some relevant clauses of the community bylaws:

"There are no differences of equality between Members, even though
certain Members may be granted particular powers, appointed to certain
roles and responsibilities, and entrusted with access to certain
Community resources. Every Member is expected to always remember that
he/she is part of an egalitarian Community of which a key guiding
principle is public service, and that membership is a status which is
truly earned through contributive work, not something acquired by
unproductive activities such as idle posting to mailing lists and
forums, etc.

Every Member is expected to deal with other Community Members and with
our end users with courtesy, forbearance, objectivity,
open-mindedness, friendliness, understanding, patience and goodwill."

I don't think you're putting all that into practice.

Therefore, I'd propose that we don't post further to this thread and,
if you want to continue the discussion, we should continue on the
discuss list.

Sigh... We've lost many contributors to the project over the past 8-10
months, but I had thought that the upside of that shedding of
interested community members was that communication within the project
had improved to a more-mature level than the flaming discussions of
the first few months...

Please read the above as meant in a friendly manner, although I am
exercising my right to intellectually disagree with you. :slight_smile:

I regret that I won't be at the conference, or I would definitely buy
you a beer to show you that there are no hard feelings on my side. :wink:

Hi David,

David Nelson wrote (09-10-11 22:55)

I regret that I won't be at the conference, or I would definitely buy
you a beer to show you that there are no hard feelings on my side. :wink:

Thanks, would really love to have that beer. But we can do it on a next opportunity.

And I really have to apologise for not being able to explain myself clear enough of course.
Kind regards,

Hi David,

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:

  So I just saw this thread; and of course the topic is worth responding
to. Firstly, let me say that I believe this issue per-se is nearly 100%
orthogonal to board membership, and how committed anyone is to Open
Source software ( and as a semantic nit-pick I'm committed to Free
Software in contrast to Open Source ;-). But perhaps by asking and
responding to it, we can see something of my stumbling approach to such
questions :slight_smile:

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

  They *might* :slight_smile: here is the judgement call. Your question to me boils
down to:

  * Will you dedicate a substantial part of your time to
    addressing my perceived blocker to attracting developers ?

  Here are some of your quotes:

  "But I am convinced that it will bring real fruits ..."
  "This kind of design documentation is really essential ...
  "... they'd have to reverse engineer the whole code base.
  "How "open" is that?
  "I also feel it will enhance the project's image and credibility

  This is your opinion of course, and one I do not entirely share. It
seems to be a firmly held one - and I like that :slight_smile: The more people we
have that are passionate about improving something - the better life
will be: assuming we get our governance right and can translate that
into action. If you profoundly believe that there is serious, systemic
risk from not having (more) code / overview documentation - then you
should -really- do something about it, and I'd like to help you do it.
Personally I see other more major risks in other places (though many of
them are getting addressed), and perhaps this will be my biggest one
soon - who knows.

  However - what you should -not- do is to harass other people to try to
make them meet your need. Instead to winsomely and gently try to
persuade them that you're right, and lead by example. So far, personally
I'm not overly concerned by this area -because- the initial fixes people
do to enter the project tend not to require this level of design
overview. Subsequently they make relationships and can ask questions of
people, and learn more, and as they go deeper (reading more code), the
structures start to become more obvious. So I don't see a huge issue
here, we have an on-ramp with a reasonable gradient. Furthermore, I
(personally) almost never read documentation - only code or headers or
specs - and the best hackers I know tend to do the same.

  Here is what I recommend: if you are truly passionate about this and
worried about it, then I suspect my (and Norbert, and other developer's)
relative lack of concern will only annoy you :slight_smile: So - I suggest that you
focus that annoyance into action: gather together existing sources of
information on code overviews make a wiki / launching page that talks
about the code structure and put it somewhere where people can find it
if they want it (a link in the top-level code README perhaps ?). I'd
resist putting that on the easy hacks page - since "here is the monster"
type documentation can put people off and is not necessary for easy
hacks.

  Then - of course, we have an existing Easy Hack to improve:

  http://wiki.documentfoundation.org/Development/Code_Overview

  IIRC, which incidentally needs re-structuring, now the code is not
packaged up into those separate repositories. Note - that I started this
page and added the easy hack to improve it :slight_smile: so I do deeply care about
code overviews & good docs [ incidentally, I started the page this was
derived from in the OO.o wiki - so, at some level I feel your pain ;-]

  Personally, I'd like that information (and more) in a README file in
each top level source-code directory as well: transferring what little
we have in the wiki, into text files would be a valuable low-skill task
too: perhaps this could be your first code commit ? :slight_smile:

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

  Of course ! but primarily I am eager to ensure that people are
liberated to do what -they- consider most important, and there are
few-to-no barriers / processes / annoyances in the way to doing that. So
- I'm most happy to help you succeed in creating relevant, useful
developer documentation: but I'd invest my time as an enabler, not as a
primary author.

  Failing that, I suspect the question behind the question is: how can I
get stuck into fixing XYZ bug that annoys me, and of course we'd love to
help out with that through the existing mentoring process - but it's
best done by posting to the dev list / poking on IRC.

  Does that help ? I hope there are some concrete steps above that would
improve the situation, that are easy for you to get stuck into, and I'd
love to get your first patch into git :slight_smile: As/when these are done lets
sync - there is much more that can be easily improved here (as
everywhere).

  All the best,

    Michael.

PS. wrt attracting developers, I'd love it if the big "please donate"
button on the web-page went to a page that didn't seem to say
(erroneously) "we are rich, don't bother supporting us" (of course in
more words ;-). If we had more cash on-hand with SPI (eg.) we could fund
a rather interesting program to attract developers I'm looking at
now :wink: No idea if you can help fix that one.

Hi Tom,

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

  Cool ! :slight_smile: and of course, it's something that can be dead useful.

There is already a good one for Extensions

  Right - and of course, we'd prefer people to write code that can be
integrated into the core cleanly, and have code sharing between
different implementations (it's easier to hack that up, debug it, and
deploy it too FWIW).

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

  I like the collection; it'd be great to excerpt / re-write some more
functionally focused flows for the things we know happen lots:

  "How to add a new language"
  "How to add a new translation"

  But of course many things are simply not documented at all; and worse
most of the existing docs are *heavily* UNO focused, which is (IMHO) a
big mistake.

  Anyhow - there were some starter tasks I mentioned to David, when
they're done - lets have a call & brainstorm on what more can be done,
and how best to do it; will you be in Paris to discuss ?

  I suspect there is enough out there to dig out and re-hash in a helpful
way. As an example if we systematically discard anything that talks
about UNO - and condense what little is left (code structure diagrams /
functional descriptions etc.) I think we might end up with something
quite useful for new core hackers: or at least a nucleus to work from.

  Thanks,

    Michael.

Hi David,

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:

  This is totally out of line; even with a smile. Tone is really
important to attracting and retaining developers - far more so than
documentation, and this -really- lowers it.

  I very strongly suggest, that you don't tell a core developer that it
is impossible for him to have become one because he can't possibly have
understood the code without design documentation, when it turns out he
didn't need it :slight_smile:

  There is a very high risk of looking silly here. Somehow the discussion
turned into an argument, (via flat contradiction), and that a
pointlessly polarised one, and I hate that. There is something in what
you're saying, and a huge weight of experience behind what Norbert is
saying.

  This is usually best fixed on a high-bandwidth, interactive,
inflection-full medium - IRC or phone I guess.

  All the best,

    Michael.

Hi :slight_smile:
Thanks :)  I'm not going to be at Paris but thanks for the offer.

Documentation on how to join in with other teams (including the Docs Team (following recent upgrades to their infrastructure)) also needs to be done.

I don't know what UNO is.  It seems to be something that depends on javascript or .Net or something??  Seems a bit strange.  Of the links i found this link made the most sense
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/FirstSteps/Programming_with_UNO
and even that was a tad confusing imo.  Does the limited guidance on how to add a language or new translation push people into using UNO?

Oddly we don't get many calls for how to translate or how to add a new language and when we do people seem satisfied with the links we give them to specific teams or to the global translations list.  We do need to get decent guides for those things but we get a lot more people asking about how to join in with programming and people seldom seem happy with what we can give them.

It would be good to have a proper LO Guide that reflects LO's direction instead of the direction under Sun.

If there are other guides that could be usefully added to the collection that would be great.  Anyone can either edit the page or pass the links to the documentation list.

Anyway, thanks hugely for your considerate reply. 
Regards from
Tom :slight_smile:

Hi Michael,

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:

This is totally out of line; even with a smile. Tone is really
important to attracting and retaining developers - far more so than
documentation, and this -really- lowers it.

That was a *joke*. Failed apparently. I must remember that humor
doesn't work on these mailing lists. :frowning: However, I'm sorry you didn't
seriously reply to the many serious and (IMHO) valid points I made...

Hi Michael,

Thanks for the answers. I don't have time to reply in detail this
week, but I will certainly be thinking about what you said. I don't
intend to let go of this subject, but will be planning my next
"attack" (let me register that as a joke already) on the discuss list.
I'll be coming up with a concrete plan, and this will certainly take
account of your kind suggestions above.

Read you around, and have a good time at the conference. :wink:

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.