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. Regards, Kevin On Mar 27, 2012, at 10:47 PM, Rob Weir <robw...@apache.org> wrote: > On Mon, Mar 26, 2012 at 9:39 PM, Louis Suárez-Potts <lui...@gmail.com>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
