On May 23, 2012, at 10:15 PM, Benson Margulies wrote: > 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.
I have reason to doubt the collaboration in the hallway aspect and I certainly do not doubt everyone's good intent. I'm not objecting to the collaboration style as an issue preventing graduation. I'm just saying I find it difficult to participate with that style and that simply makes me wonder if that is making it harder to attract new committers. I fully realize that that issue might just be with me, but the fact remains that there is practically no diversity in the project and I cannot in good conscience recommend graduation for a project in that situation. Ralph > > >> >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
