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