On 9 May 2013 09:07, 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. > I think rob have a number of valid points, that we need better documentation and a better build system, but this is a "devils circle", we need it to keep committers and do have enough resources to do it over night....IMHO we need to take an alternative path.
> > 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/<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<http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO> > need some rewriting? That building guide, can be seen as a guideline...it needs updating to a much more precise step-by-step guide...no guessing follow this. (I had f.x. to talk with arist to get a danish language built, configure --help did not really help). I think there are 2 points that would really help newcommers or lower the ladder: 1) provides a zip / tgz files with a preconfiguration and maybe a simple setup.bat / setup.sh for the main platforms: ubtuntu, windows 2) Provide a big zip / tgz file, with a copy of a built AOO (including .o etc), with a simple instruction "it must be installed in directory x with your own user" I have done number 2) for a couple of friends, and they were happely up and running in an hour. I am very well aware this is NO mid-term solution, but only a fast fix to the problem at hand. > > 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). > The side bar might very well be a challenge, please remember for many developer "hot" means an intelectual challenge, and something they can show friends. Doing something like GSoC descriptions might very well be time well spent. > > 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. > Look at it as an investment, spending time now getting others started, ensures that we in mid-term have more helping hands. I will happely also identify 2-3 tasks in l10ntools, likewise maybe someone could mentor (helping with templates and cmd) a new web design. If we dare, we could use rejuvenate01 (I really start to like the name), to make a call for skilled system builders...saying we are starting a little team to reinvent the infrastructure of AOO. Correctly formulated and put on the right places, this could very well attract skilled makefile people who would see it as a challenge (and be proud of) rejuenating that part. If we do that, I would gladly be flag leader/mentor with the help of the community. Ps. it is not bugs, but product enhancements....bugs is something very boring, finding problems in other peoples code it not very fun. > > > people.apache.org/~jani/**topCommit6mdr.txt<http://people.apache.org/~jani/topCommit6mdr.txt> >> people.apache.org/~jani/**topCommit1year.txt<http://people.apache.org/~jani/topCommit1year.txt> >> people.apache.org/~jani/**topCommit2year.txt<http://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. > UPS !! my fault !!! sorry about that....it is corrected, please look and see if the disclaimer fits the bill. Looking at the numbers again (80 (2 years) -> 58 (1year) -> 26 (this year)), I cannot judge if people are just taking a break enjoying real life, or if it signals people stopping working. I think it would be worth while to investigate that part as well, and depending on the result take some proper action. My problem is that I have not a clue to how to do such an investigation. Thanks for all the positive feedback from both rob and andrea. rgds jan I. > > Regards, > Andrea. > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@openoffice.**apache.org<dev-unsubscr...@openoffice.apache.org> > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
