On Wed, May 23, 2012 at 10:09 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > Right after I read Jukka's email that started this thread and I posted my > reply and discovered to my shock that they had started a graduation vote. I > am shocked because I have pointed out repeatedly the project's complete lack > of diversity. Virtually all the active PMC members and committers work for > the same employer. I have told them several times that I would actually like > to participate in the project but the way the project works is very different > then every other project I am involved with at the ASF and the barriers to > figure out what is actually going on is very high. Almost nothing is > discussed directly on the dev list - it is all done through Jira issues or > the Review tool. While all the Jira issue updates and reviews are sent to > the dev list most of that is just noise. Feel free to review the dev list > archives to see what I am talking about.
I don't follow flume, but I'd propose to soften your objection only slightly. I've met other groups of people who like a JIRA centric view of the world. I suspect that if they did a bunch of other good things called out below, you or others would find the JIRA business digestible. Also, on the other hand, I fear that the co-employed contributors are collaborating in the hallway, and the lack of the context in JIRA or on the list is contributing to the problem. > > Needless to say, when the graduation proposal reaches this list, and I'm sure > it will, I will strongly endorse the IPMC to reject the proposal. > > FWIW, I found the post below to be 100% on target. > > Ralph > > > > On May 23, 2012, at 7:31 PM, Marvin Humphrey wrote: > >> 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 >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
