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
