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

[caolan]

Who am I: Reasonably experienced software developer, involved in
LibreOffice and predecessors since 2000. Employed by Red Hat since 2005,
and Sun Microsystems prior to that.

What I do: Full time LibreOffice developer. All round code dogsbody but,
historically at least, most interested in file format import/export,
e.g. much of binary MSWord import/export code is my fault. I currently
help man the documentfoundation security list, review code, fix bugs and
dabble in an occasional new feature.

Why I'd be useful: I'll make no great claims to my utility in organizing
matters legal, but both as a fulltime developer on the project and as a
representative of a growing number of LibreOffice developers at Red Hat,
I believe I can help provide a helpful balance of interests in the
board.

Full Name & email: Caolán McNamara <caolanm@redhat.com>
Cooperate Affiliation: Red Hat, Inc.

C.

[David_Nelson]

Hi Caolan,

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.

[caolan]

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

Sure.

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

Sure, apple pie and motherhood too.

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

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

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

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

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

No. I couldn't make such a commitment.

I am thinking of something along the lines of:

...

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

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

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

C.

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