On 9 May 2013 18:59, Regina Henschel <rb.hensc...@t-online.de> wrote:
> Hi, > > janI schrieb: > > On 9 May 2013 14:40, Rob Weir <robw...@apache.org> wrote: >> >> On Thu, May 9, 2013 at 5:05 AM, janI <j...@apache.org> wrote: >>> >> [..] > > 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 >> >> > A new developer can help already before he is able to make a patch. My > first contribution was a comment to the function getRandbetween long before > I know any C++. > >>> 1) What knowledge do we assume as a pre-req? Obviously we cannot >>> tutor them in C++. But what else is an absolute prerequisite? >>> >>> >> With the current build system, they need to have fundamental knowledge of: >> - makefiles (we can provide a link, maybe it could be put in the >> "introduction" course >> - scripting languages (again with can provide links to documents) >> > > Here I disagree. Such knowledge is not necessary. For example my last > issue 122263. That is all inside one file. You need not know anything about > makefiles or scripting languages. Make the barrier as low as possible. A developer still needs to understand how to build AOO, or at least rebuild (if we provide a vm), in order to debug and test. So you are correct for the very first step it is not needed, but it is needed very fast...we do not provide visual studio solutions (which might have lowered the barrier quite a lot), so the developer needs to run "build" and/or "dmake". > > > >> 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. >>> >>> >> That is a bet I will not take, here is my list (what I missed, regina >> described most of it in an earlier mail): >> - a strict platfom related step-by-step build guide, with the >> variations >> (debug for a single module, language version, normal build) >> - An overview of our directory structure, with a short explanation what >> is this directory containing >> - An overview seen from the product e.g. writer consist of. >> - helper tools >> - Debug guide, how to do partial debugging (platform dependent), advice >> on inspecting our objects (especially strings) >> - Build guides pr. platform, with advice on rebuilding, especially if >> with different configure (e.g. with/without language) >> - short introduction to how we use svn (git?) and how to submit patches >> (svn diff) >> - A list of, at least but not limited to, pmc members and their field >> of >> expertice, so a new person feels he/she knows us. >> (actually such a list, helps a lot with the other missings) >> >> I have one wild idea, which I do not know if it is can be done....extend >> the introduction module with one lesson "solve your first bug", where we >> make a step-by-step guide for solving a "real" bug, the idea is that the >> developer can use it as a "template" to solve real bugs. This guide should >> problaly come in 2 versions windows/linux. >> > > And when the bug is fixed? Such lesson would need to be independent of a > bug. > a slight misunderstanding, I did not think of a real bug...but a bug we "introduced"...and the lesson would be kind of a slideshow with step-by-step guidenca to find, change, test this bugs. That way the developer can read the lesson multiple times to understand the steps involved. > > Nevertheless a "solve your first bug"-page is a good idea. But each such > bug needs an experienced developer to guide a newcomer. Unfortunately I'm > not 'experienced' but need such mentor myself. > I want to "save" our experienced developers time, by having one of them explain it once, in a slideshow fashion. > > Such page would be better visible to new developers than searching in > Bugzilla for "easy" tags and finding nearly nothing. +1 rgds jan I > > > >> >> 3) Create a new index page (or update an existing one) to bring >>> together links to all this information. >>> >>> +1 >> >> >>> 4) Where needed update this information >>> >>> +1 >> > > All together these seems to be tasks to start as soon as possible > (immediately after release of 4.0?) and before any actions to appeal for > developers. > > Kind regards > Regina > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@openoffice.**apache.org<dev-unsubscr...@openoffice.apache.org> > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
