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.

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

-- Patch submission instructions

-- Link to the Building Guide -- but might need a refresh

-- Link to a debugging guide (does this even exist?)

-- Link to Bugzilla and a pre-defined search for unclaimed "easy"
bugs. (Also, we need to mark some easy bugs in advance)

-- Link to previous write up on Discussion lists, Apache Way, etc.


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.

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?


-Rob

Reply via email to