On 11 May 2013 01:20, Rob Weir <robw...@apache.org> wrote: > On Thu, May 9, 2013 at 3:07 AM, Andrea Pescetti <pesce...@apache.org> > wrote: > > 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 > > It took less than a day, and these numbers are already being used on > Lwn.net: > > http://lwn.net/Articles/550079/ > > There is an art to working on a high-profile project that is monitored > closely by detractors, and part of it is not to quote statistics > unless you are sure they are meaningful. The comparison of this year > versus last year, without regard for the fact that last year had 12 > months of data while this year has had only 4, is something that is > easy to forget when the data is quoted out of context. But it makes a > huge difference when you consider that contributors come and go > according to their interests, and any longer period of time will show > more of them. >
I strongly disagree with you here, but to follow your point I think the comparesion of active committers is meaningfull otherwise I would not have written the mail. When you look at the number of active committers over time, the actual time period is not critical (if it is relavetively big). The number are explained why the are not compareable. It cannot be correct, that we cannot discuss facts in here....this mail thread have in my opinion had a good giving discussion, which I dont think we would have had without the initial mail (I have tried to start exactly this discussion before). Just for the record, the number files do have a disclaimer, meaning the direct usage they have done is not legal, furthermore the first mail in the mail thread contains a description of the numbers. rgds jan I. -Rob > > > > 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
