Hi David,
On Sat, 2011-10-08 at 18:12 +0300, David Nelson wrote:
> 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. ;-)
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 :-)
> Open the doors wider, and more people might come in.
They *might* :-) 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 :-) 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 :-) 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 :-) 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 ? :-)
"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 :-) 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 ;-) No idea if you can help fix that one.
--
michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot
--
Unsubscribe instructions: E-mail to steering-discuss+h...@documentfoundation.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/steering-discuss/
All messages sent to this list will be publicly archived and cannot be deleted
