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
mentoring.
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
http://wiki.services.openoffice.org/wiki/Calc/Implementation/Spreadsheet_Functions
(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
modules?
(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
http://wiki.services.openoffice.org/wiki/Building_OOo_with_Cygwin_on_Windows
I was not able to build OOo. So keep this information up to date; it is
essential for newcomers.
Kind regards
Regina
