Hi Eric, you wrote: > Let's imagine I'm a new dev willing to contribute to OpenOffice.org : > > [H] : like common people who want to help, I do have C/C++ background > ( something like 3 to 10 years of coding something somewhere) > > - first question : where are things ? How is organized > OpenOffice.org code ?( build OpenOffice.org can really help here ) > > - second question: what is the design of the feature I want to > contribute ? > > [snip] > > Facts: because I didn't find the answer to the first question(s), I > do like 1 developers over 2 did -> I give up > > For Mac OS X port, we lost 1 over 2 new devs, willing to help us, > this way, and I have to use a lot of energy and must take care every > day about that. > You are right - and the problem is, there's no easy fix for that. It's a multi-dimensional optimization problem, and maximizing one aspect might pessimize other. I agree with you that the barrier for entry is high for new devs, but efforts to improve on this are ongoing (build times, integration of ooo-build build system ease-of-use, lightweight spec processes, unit tests etc). High-level design documentation is sorely missing for most modules, but: OOo is too big, and internal stuff changes much too frequently, that static design description would really cut it (except it's _really_ high level, like the module manifestos on the source code directories wiki page). I guess a mix of problem-specific HowTo entries (like e.g. adding a new menu entry, a new import filter, etc.), knowing where to ask (->irc, dev list), and tooling (lxr, bonsai, refactoring toolkit) has the best chance of being up-to-date, and at the same time avoiding to frustrate people too much.
> -1 for a new C++ list of best practices : I already got the > Stroustrup's book (and will continue to learn it) > I'd really hope that the best practice examples from the coding standards pages are more than what you could glean from the Stroustrup book (it should rather be a distilled extract from a lot of sources, including gurus like Stroustrup). Besides, it's less to read. ;-) > To complete, as suggestion, we should add keywords (or sub- > categories) in the wiki description like : > > - knowledge only > - practical > - tips ( good examples in the code ) > - autonomy ( idea to improve ) > - tools ( interaction between code and tools, how compile and test > my code ... ) > - resources ( people, code snippets , where/how find/join us, > bibliography ... ) > - (complete) > Would you like to add some of them? > But don't forget the first point: we currently continue to lose new > devs regularly ... > We don't forget - but please bear in mind that OOo is one of the largest and most complex OSS projects (maybe /the/ largest), and in contrast to e.g. Linux kernel, there's no such clean separation between device drivers and core kernel (because of the vastly different problem domain, I'd assume). So, a certain survival-of-the-fittest preselection should be accepted (in fact, necessary), but I'm with you that we haven't reached the sweet spot here. Cheers, -- Thorsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
