On Wed, May 23, 2012 at 5:36 PM, Patrick Hunt <ph...@apache.org> wrote:
> Perhaps someone will have some insight on how to gather new
> contributors that hasn't been tried yet?

Jukka's written on this subject multiple times in the past.  Here are two
gems, one from a while back, the other recent:

    http://markmail.org/message/o3gbgam4ny2upqte

    Most of the cases I've been involved so far of podlings in the "hoping
    some more people come along" have had symptoms of the project team not
    paying enough attention on making it easy for new contributors to show up
    and stick around. Things like complex and undocumented build steps,
    missing "Getting started" or "Getting involved" guides, lack of quick and
    positive feedback to newcomers, etc., are all too common. Fixing even just
    some of such things will dramatically increase the odds of new people
    showing up.

    Those are things that are very easy to overlook when you're working on
    your first open source projects (it took me years to learn those lessons),
    but we here have a massive amount of collective experience on such things.
    That's what we could and IMHO should be sharing with the podlings. That's
    what "mentoring" to me is about and that's where our most precious "added
    value" is. Otherwise incubation just boils down to an indoctrination
    period on how to apply and conform to the various Apache rules and
    policies.

    http://incubator.markmail.org/thread/qpzg6wdoq7cwko55

    I've been involved with quite a few podlings with similar problems in
    attracting longer-term contributors. In my experience the best way to
    solve that problem is to change your mindset of expecting most such people
    to be just one-off contributors. If you instead treat them as your next
    new committers and engage with them as peers, many (though of course not
    all) will respond in kind and actually become more involved.

    Many developers, especially from commercial backgrounds, tend to treat
    such contributors as just users reporting a problem. A typical interaction
    goes like "What's the problem? Do you have a test case? OK, let me fix it
    (when I get around to it)." A better approach is something like "What's
    the problem? OK, here are some pointers to the relevant bits in code. How
    do you think this should be fixed?"

Here's another tip I picked up from Joe Schaefer: when you're voting in a new
committer and they have a big patch set sitting in the queue, hold off and let
*them* commit it so that they get the satisfaction, the new experience, and the
appreciation all at once.

It would be nice if stuff like this was collected in "Steps to building a
community" documentation somewhere, rather than scattered through the email
archives.  I suggest "Steps" as a format because different approaches are
required at different phases of the project and sizes of the community.

Marvin Humphrey

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Reply via email to