incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: After AOO 3.4, attracting new contributors
Date Tue, 27 Mar 2012 14:47:15 GMT
On Mon, Mar 26, 2012 at 9:39 PM, Louis Suárez-Potts <>wrote:

> Hi,
> On 2012-03-19, at 08:41 , Rob Weir wrote:
> > Any ideas and the best ways how we can improve in this area after AOO
> > 3.4 releases?
> Lots, and these would complement the rather good ideas already proposed.
> What we did at OOo actually worked--to attract developers and contributors
> of all sorts. What worked against us I do not think I need spell out, but
> the cussedness of the code was not really the determining factor.
> What really would help, besides giving would-bes a clean entry, is to have
> mentors, more or less do-able tasks that are identified as such. (We tried
> getting to this many times, and I strongly urged my erstwhile colleagues in
> this area for, uhm, years. Finally happened, and we got our to-dos but
> still not clearly identified according to level of difficulty. I can
> conceive of several  here whose work would assist in the identification of
> tasks newbies could approach--and even post-newbies-and perhaps even in
> mentoring.)
> Also, what helps tremendously is what we are doing already: presenting a
> community that is open, friendly, and generally has a good attitude about
> what it is doing and where it is going. There are millions using OOo as
> their primary ODF implementation, and those mostly include those who have
> come to it via the national or sub-national government agency. I think it's
> about time that they are looking to AOO for the next step.
I think the idea of a new contributor mentor is essential.   This is true
for coders, but also website, translation, documentation, test, UI, etc.
What we have today is very much a "swim or sink" and "drink from the fire
hose" approach.  If someone is highly motivated, highly skilled and
persistent, and is able to withstand the apparent chaos of the ooo-dev
list, and penetrates the noise and asks questions, and repeats their
questions until answered, then they might have a 50/50 chance of

But let's be honest with ourselves -- there are a range of projects someone
can contribute to.  For would-be volunteers it is a buyer's market.  If we
make it too hard to get involved and contribute, technically, procedurally,
socially, then we lose.

But getting new volunteers on board requires effort.  If someone is
spending 100% of their time on their own features, then they have no time
to help new volunteers become productive.

One approach might be to define "essential skills" or "essential knowledge"
that a new volunteer needs to master in order to become productive, and
then a list of project members who are willing to help mentor new
volunteers to acquire those skills.

For example, for the website, the essential skills might be:

1) Assume HTML/CSS, we're not here to teach that
2) Help them get started with Markdown Text
3) Help them use the CMS to generate patches
4) Help them build website locally via the scripts
5) Understanding the larger site design, including recurring page elements,
footers, etc.
6) In parallel with above, understanding Apache, roles, decision making,
lazy consensus, CTR versus RTC, what Infra does versus what the project is
responsible for, etc.
7) Help them establish a record of contributions to become a committer

Anyone who has done the above can do 95% of what is needed to become a
master of our website.

It would be wonderful if we had something like that, a check list even a
curriculum, for other common functions, as well as volunteers able to take
on new project volunteers willing to help.

This is all an investment in the future success of the project.  We grow by
attracting new volunteers.  But the investment is time spent on mentoring.
This would all be over-kill for the average Apache PMC of 8-12 people.  But
with 10 million lines of code, a PMC nearing 100 members, and the largest
project at Apache, we need an approach to training new volunteers that
works to scale.  I think something like the above helps get us closer.


And I can think of at least two, and probably more, national bodies so
> interested.
> Do these give us developers straight away? I don't know. The problem with
> OOo was, as [not] said ultimately political, not codical (comical?).
> Engaging these longtime users, as well as new ones, with the possibilities
> represented by this community, which is open and unencumbered--ought to be
> easier.
> My own approach is to focus on ODF and on the benefits offered not only by
> the AOO implementation but by its community.
> -louis

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message