On Thu, May 9, 2013 at 5:05 AM, janI <j...@apache.org> wrote: > 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've had some parallel thoughts as well. Maybe even provide a VM with a complete Linux AOO dev environment already set up. A script, of course, would be smaller but needs to deal with more platform differences. > 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. > It might make sense to make a list: What are all the things that a new dev volunteer needs to know or do before they can make their first patch? 1) What knowledge do we assume as a pre-req? Obviously we cannot tutor them in C++. But what else is an absolute prerequisite? 2) Of the other items the need to know, what is already written down? I bet a lot of it already exits, but it is scattered about and/or out-of-date. 3) Create a new index page (or update an existing one) to bring together links to all this information. 4) Where needed update this information 5) Set up a feedback mechanism so new developers can point out information that is not accurate or confusing. We could do this ourselves to some extent, by pretending we're new and following the instructions literally. Regards, -Rob > > >> >> 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
