Why not Zoidberg? If someone wants to gather stats, that's great - if someone wants to gather stories etc, that is also great. One doesn't exclude the other, and considering we have nothing at the moment, anything is a step up.
With regards, Daniel On 12/05/2016 06:18 PM, Alex Harui wrote: > IMO, rather than gathering statistics, it would be better to gather > stories, tips and advice. It doesn't seem to me that statistics would be > helpful, folks just need to know that it can have great benefits or great > cost and some ideas of the reasons why. Even if it hasn't been helpful in > the past for the vast majority of ASF projects, if it benefits some other > minority of projects, the important takeaway is that it can work for > certain reasons, not that it isn't a good idea for your project because it > didn't work for most other projects. Each project is different. > > My 2 cents, > -Alex > > On 12/5/16, 9:10 AM, "Suresh Marru" <sma...@apache.org> wrote: > >> Hi Rich, >> >> Do you prefer to see cumulative statistics or PMC wise? With a small >> effort, I can get detailed statistics from Apache Airavata. GSoC has been >> great for the project and is one of the primary sources to induct fresh >> blood. We have a decent retention rate, students have stayed around, >> earned committerships, then became PMC Members, graduated and moved onto >> real jobs and still continue to contribute (not always by code though). >> >> Engaging the students and mentoring them takes time, but we have spun it >> around and used it as an opportunity to improve documentation and >> contribution workflow. >> >> Hope this experience summary helps the discussion, will be happy to >> elaborate and provide specific examples. >> >> Cheers, >> Suresh >> >>> On Dec 5, 2016, at 12:01 PM, Rich Bowen <rbo...@rcbowen.com> wrote: >>> >>> Nobody is suggesting we have a 10 year plan with milestones and >>> deliverables. I'm suggesting that when we do something under the heading >>> of "community development" we have an obligation to make some attempt to >>> measure it to determine if it actually moves us in that direction. >>> >>> Nobody is saying that we shouldn't participate in GSoC. I'm suggesting >>> that before we promote GSoC to our projects, we should have some numbers >>> (we've been doing this for years. surely there's some numbers that we >>> could gather her?) that show projects that it's worth their time. Or >>> warns them that it might not be. >>> >>> I don't care how much time individuals spend on GSoC. I care that we are >>> telling projects that it's a worthwhile thing for them to spend *their* >>> time on, and we don't appear to have actually taken the time to find out >>> of that's true. >>> >>> >>> On 12/05/2016 08:59 AM, Bertrand Delacretaz wrote: >>>> Hi, >>>> >>>> On Mon, Dec 5, 2016 at 2:30 PM, Daniel Gruno <humbed...@apache.org> >>>> wrote: >>>>> ...The task of ComDev is developing community. If we don't have any >>>>> data or >>>>> interest in acquiring such to show that this is in fact helping >>>>> towards >>>>> that, then we should consider whether the current strategy is the >>>>> right >>>>> thing to focus on.... >>>> >>>> I disagree with the need for comdev to have a strategy. >>>> >>>> At the technical level the ASF doesn't have a strategy, it just >>>> provides space for its projects to exist and flourish. >>>> >>>> I think comdev can operate in the same way, as a loose group of >>>> volunteers who collectively help develop communities, without >>>> necessarily having a global comdev strategy to follow. >>>> >>>> Three examples: >>>> >>>> 1) A small group is running GSoC, which as Uli mentions doesn't cost >>>> the ASF anything and actually brings some money in. GSoC clearly helps >>>> our mission by helping a few community members join the ASF every >>>> year. Exactly how many is not very important if volunteers agree to >>>> run it. >>>> >>>> 2) Sharan and others have started work on diversity initiatives - >>>> another subset of folks sharing common interests that match the >>>> overall comdev mission. >>>> >>>> 3) I led a small group to develop our maturity model, I think it's a >>>> very useful tool. I think we made just one change to it in 2016, it's >>>> stable but useful and maintained. Others don't care about that or >>>> didn't have time to help - no problem. >>>> >>>> You could argue that these things are disjoint but they are all small >>>> steps that help towards our overall mission. We don't need much >>>> coordination between them, IMO just making sure the comdev PMC agrees >>>> with these things happening, and doing out best to unify their >>>> communications channels to create synergies is good enough. >>>> >>>> Comdev can just provide a space for volunteers to help develop >>>> communities, that's good enough for me. If others want more structured >>>> activities feel free to do them but don't expect all PMC members to >>>> necessarily join or to feel bad if they don't. >>>> >>>> -Bertrand >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org >>>> For additional commands, e-mail: dev-h...@community.apache.org >>>> >>> >>> >>> -- >>> Rich Bowen - rbo...@rcbowen.com - @rbowen >>> http://apachecon.com/ - @apachecon >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org >> For additional commands, e-mail: dev-h...@community.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
