janI wrote:
On 9 May 2013 00:23, Rob Weir wrote:
5) Development is also made more difficult by the intrinsic complexity
of the code base, the build system and the poor state of the developer
documentation.
yes because we try to tell people to grasp the whole system in one-go
"start by build AOO", that is a nice way of making a developer feel
insecure.
What can be done to improve this? Building OpenOffice is the first step
for any core code contributor, I can't understand why this makes people
feel insecure. But it's a critical point, so whatever we can do to
improve this stage will help.
For example, impatient people who do not use "./configure --help" will
have a hard time figuring out the errors with dmake and epm, and
downloading the prebuilt unowinreg from
http://www.openoffice.org/tools/unowinreg_prebuild/ could be simplified
or automated... But none of this seems a tremendous improvement to me.
Can we do better? Does
http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO
need some rewriting?
What we need to do (in my opinion) is to define small tasks
(preferable "hot" topics), not solve a bug (remember an office system is
not really "hot" for developers, and solving bugs is boring.
The "hotness" concept is correct. For example, a key feature of
OpenOffice 4 is the sidebar; it may well be one of the "hot"
developments you describe. So far it has been developed in a branch,
with no public communication, then moved to trunk, again with no public
communication, then subject to QA (again, no public communication except
for mailing lists).
If we identified 3-5 small development tasks to make the sidebar better
or fix the discovered bugs, and exposed them in a blog post, we could
(realistically) attract 3-5 new developers. But the trade-off would be
that Andre, or some other expert developer, must spend time on mentoring
new developers instead of making the fixes himself, which would probably
take him less time. And those developers would need to work on less
documented (since they are evolving) features, so this is feasible only
if an experience developer is willing to invest a lot of time on it, as
an investment to get more developers and better documentation.
people.apache.org/~jani/topCommit6mdr.txt
people.apache.org/~jani/topCommit1year.txt
people.apache.org/~jani/topCommit2year.txt
Before we see direct links to these resources appearing everywhere and
purported as official published statistics from the project, I'd
recommend putting the URL of this discussion (from markmail or
mail-archive) in the files, so people can get your accompanying
explanation and the follow-up. As you say, it's always dangerous to
interpret numbers... but it's also very easy to play with numbers, so
explanations are always needed when presenting numbers.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
