incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Grignon <>
Subject Re: After AOO 3.4, attracting new contributors
Date Wed, 28 Mar 2012 01:42:29 GMT
Another thought. 

Perhaps we could expand the message to reference open source product design and development,
rather than focus solely on technical tasks. 

This could help us attract a wider range of takented contributors. 


On Mar 27, 2012, at 10:47 PM, Rob Weir <> wrote:

> 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
> contributing.
> 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.
> -Rob
> 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

View raw message