On Fri, Nov 16, 2012 at 7:13 AM, jan iversen <jancasacon...@gmail.com> wrote: > I have added a couple of comments below, based on my small (but to some > noticeable) experience. > > Jan > > On 16 November 2012 15:39, Rob Weir <robw...@apache.org> wrote: > >> As you have probably seen, we're currently doing a call for QA >> volunteer, supported by a blog post, the website and social media. >> They all direct users to an "Introduction to QA" page: >> http://incubator.apache.org/openofficeorg/orientation/intro-qa.html >> >> We've been promoting this for a week now and have received 5 or 6 good >> responses. Of course, not everyone who responds will become a >> longer-term volunteer, but this is how we start. I invite anyone with >> some spare time (ha!) to jump on the QA list to help >> coach/mentor/orient the new volunteers. Their initial experience, in >> the first few days and weeks, is critical. >> >> This QA promotion follows some initial experiments with putting >> targeted calls for volunteers on NL home pages. You cans see an >> example here: http://www.openoffice.org/hi/ >> >> This approach has been very successful, perhaps because we get the >> plea in front of exactly the audience that can most help in the >> translation tasks. In some cases we received 2 or 3 volunteers for a >> language within a few days of adding this kind of message. I'm >> hoping we can do a broader call for localization volunteers as well. >> Juergen has promised a blog post on this topic, based on his ApacheCon >> presentation. >> >> Next up I have a call for marketing volunteers: >> http://incubator.apache.org/openofficeorg/orientation/intro-marketing.html >> We're still reviewing that page, and I need to prepare a blog post. >> Hopefully we can start promoting this in a week or two. >> >> Which all brings us to Dev. We all know how critical developers are. >> I'm pretty sure that was why beer was invented. I saved Dev for the >> end because I wanted to "fine-tune" the recruitment approach before >> doing Dev. I'd like to brainstorm a little on what kind of >> information we should gather together, in the form of new material or >> links to existing (or updated) material, to make an "Intro to Dev" >> page, in the style of the ones above. >> >> Assumptions: >> >> -- Volunteer has practical C++ and platform skills on at least one >> core platform. It is not practical for us to teach someone C++. >> >> Goals: >> >> -- Volunteer is able to download and build AOO >> >> -- Volunteer is able to run AOO in a debugger >> >> -- Volunteer is able to fix an "easy" bug in Bugzilla >> >> -- Volunteer is able to submit a patch to fix the bug >> >> -- Volunteer understands the basics about how we work on the lists, >> how we make decisions, etc. >> > > -- Volunteer understand the structure of the AOO source tree.
On this one, maybe a link to the Developer's Guide would be of benefit. http://wiki.openoffice.org/wiki/Documentation/DevGuide/OpenOffice.org_Developers_Guide > > -- Volunteer understand how QA work hand in hand wih dev (this is > something I still do not understand). > >> >> IMHO, someone who does the above, and repeats it 3 or 4 times, and >> sticks around for a month or more, and is not a jerk, then they are >> probably a good committer candidate. I think that would be one >> success metric for us. >> >> Considering the above, I think we'd want the Intro to Dev page to >> feature (not necessarily in this order): >> >> -- Link to intro on Subversion >> > The apache introduction, was very helpful for me having experience with > other version control systems. > > >> -- Patch submission instructions >> > which should include a brief mail, saying "I will work on" > >> >> -- Link to the Building Guide -- but might need a refresh >> > not "might" that is an absolute must...there are at least 3 different build > instructions for Ubuntu, and I actually ended up doing a 4th variation > (thanks to help from the list). I will gladly help here. > > >> >> -- Link to a debugging guide (does this even exist?) >> > +1 > > -- Link to Bugzilla and a pre-defined search for unclaimed "easy" >> bugs. (Also, we need to mark some easy bugs in advance) >> > +1 > -- Link to OpenGrok for source search. > -- Description of source tree, especially what is "dead" code. > >> >> -- Link to previous write up on Discussion lists, Apache Way, etc. >> > +1 > >> >> >> Also, another idea was whether we might make the initial build >> experience far easier for the developer if we encouraged the use of a >> single platform and version. A developer can use whatever they want, >> within reason, of course. But what if we said, if you use Ubuntu >> 12.04 LTS then here is a script that will install the exact pre-reqs >> you need and bring down the build, set all the flags and kick off a >> build? In other words, control the environment and we can make the >> initial build be painless. In a world of virtual machines, this is >> possible. >> > +1, but even better offer a prebuilt directory tree, ready to debug. > >> >> Anything else for the guide? What else does a new developer need to >> know to get started? Also, is anyone interested in helping me put >> this together? >> > If wanted, I will be happy to assist, since I still have a lot of my > problems in fresh memory. > > >> >> >> -Rob >> -- ---------------------------------------------------------------------------------------- MzK “How wrong is it for a woman to expect the man to build the world she wants, rather than to create it herself?” -- Anais Nin
