openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regina Henschel <>
Subject Re: After AOO 3.4, attracting new contributors
Date Tue, 20 Mar 2012 12:29:17 GMT
Hi Rob,

I do not code in my daily job, but do it only as hobby. My personal 
observations might be true for other volunteer coders too.

Rob Weir schrieb:
> There have been some side discussions on this topic.  I'd like to
> collect these ideas into one thread.
> My observations:
> 1) The OpenOffice code base has a reputation of being complex, hard to
> understand, even "haunted".  It is difficult for new developers to get
> involved with it.
> 2) We get regular offers of help from new volunteers for other project
> functions, such documentation, QA, website,etc., but we are not doing
> a great job getting them to be successful contributors in the project.
> 3) Nothing is free.  Making the code easier to understand, or
> mentoring new contributors to the project, these things time and
> effort.
> So there is a natural trade-off between short term progress on
> features and long term growing of the contributor base.  With AOO 3.4
> we have biases the effort toward forward progress on the release. Post
> AOO 3.4 we might want to adjust to a more balanced approach.
> Any ideas and the best ways how we can improve in this area after AOO
> 3.4 releases?

It is impossible to understand the code without guides and without 

Conclusion, wish or how you might call it:
(1) Document parts of the code very detailed in all steps, including 
help and accessibility. For example: How to make a new dialog? How does 
an Excel import filter works? I could start only after Eike Rathke has 
documented the process of adding new functions to Calc in

(2) Document an overview of AOO. For example: What parts are all 
touched, when a user drags a corner of a shape till the shape is 
changed? Or what parts are touched, when a writer document is opened. 
And the other way round, what is handled in vcl or cosv or all the other 

(3) Document AOO specific things. For example what are these OSL_*, 
which are used, when and why. What special types exists, why do they 
exist, when should they be used?

(4) Increase mentoring. Such mentor should identify a "nice to have" 
feature and offer to guide the volunteer. Armin has mentored the 
"linecap" feature that way and it has worked well. Although some 
essential parts are done by Armin, I did a lot by myself and got some 
new insides in the code.

Getting a build is a critical part for newcomers, especially on Windows.

(5) Work very hard to provide a buildable trunk on Friday. It is very 
frustrating when you plan to do some coding on weekend and the build fails.

(6) Without the document about building OOo on Windows by Mathias Bauer 
and the succeeding Wiki page 
I was not able to build OOo. So keep this information up to date; it is 
essential for newcomers.

Kind regards

View raw message