>From a mobile device - forgive errors and terseness On May 29, 2012 12:14 PM, "Shane Curcuru" <a...@shanecurcuru.org> wrote: > > Doesn't the IPMC (and not any individuals, even Roy) decide what the official Incubation policies should be? Ralph's reply, and my general reading of the feeling in the IPMC is that graduation votes *should* take affiliation diversity into account. >
+1 on both counts. For me what is important is not so much diversity in numbers but diversity in engagement, particularly in decision making. I've not reviewed Flume myself so I have to listen to mentors. What I hear is a concern about numbers, but no explicit concern about decision making. > Note that some could argue Flume technically meets the diversity criteria, however I really like Jukka's analysis of who's actually making the commits - which means they may not necessarily meet the diversity criteria in spirit yet. > Although when the RTC process is considered this point becomes less valid. Ross > - Shane > > P.S. For our public readers, note that Roy's emails are always worth reading. > > > On 2012-05-27 5:17 AM, Ralph Goers wrote: >> >> >> Roy, What you are saying directly contradicts >> http://incubator.apache.org/guides/graduation.html#community, >> especially the statement "Basically this means that when a project >> mostly consists of contributors from one company, this is a sign of >> not being diverse enough". Now, if that page is wrong and diversity >> is not a requirement for graduation then, of course, that would >> certainly remove any objections I have for Flume's graduation. >> However, I've heard it said that the ASF does not want to simply >> provide the infrastructure for companies to host their products on. >> >> Ralph >> >> >> On May 27, 2012, at 1:35 AM, Roy T. Fielding wrote: >> >>> There is no diversity requirement for graduating from the >>> incubator. In many ways, incubation hinders community growth. The >>> requirement is that the project makes decisions as an Apache >>> project, not in private, which is harder to get used to doing if a >>> lot of people share the same office. >>> >>> Diversity is only a warning sign that means we need to check for >>> decisions made in our forums and advise accordingly. It is not an >>> end in itself, nor has lack of diversity hindered other projects >>> from continuing on to build a larger community as a TLP. >>> >>> ....Roy >>> >>> >>> On May 26, 2012, at 11:44 PM, Ralph >>> Goers<ralph.go...@dslextreme.com> wrote: >>> >>>> >>>> On May 26, 2012, at 9:29 PM, Arvind Prabhakar wrote: >>>> >>>>> Hi Jukka, >>>>> >>>>> On Sat, May 26, 2012 at 4:43 PM, Jukka >>>>> Zitting<jukka.zitt...@gmail.com>wrote: >>>>>> >>>>>> >>>>>> IIUC Flume operates under an RTC model where people are not >>>>>> supposed to commit their own changes, which obviously makes >>>>>> the above data less relevant for evaluating the true >>>>>> diversity of the community. However, seeing only a single >>>>>> trivial commit by both jarcec and juhanic even though they >>>>>> became committers already over three months ago does seem to >>>>>> suggest that they may not be as comfortable in their >>>>>> committer role as people from Cloudera are. >>>>>> >>>>> >>>>> As you noted in your comments above - the Flume project tends >>>>> to follow RTC with the reviewer committing the code. I happen >>>>> to have taken up the role of the reviewer for the most part and >>>>> hence you see the skewed commit counts. If you want to see the >>>>> actual contribution, I would suggest looking at fixed JIRA >>>>> issues by assignees. A quick report yields the following: >>>>> >>>>> aprabhkar - 26 - Cloudera [6] brocknoland - 19 - Cloudera [7] >>>>> esammer - 56 - Cloudera [8] hshreedharan - 34 - Cloudera [9] >>>>> jarcec - 6 - AVG Technologies [10] jmhsieh - 8 - Cloudera [11] >>>>> juhanic - 9 - CyberAgent [12] mpercy - 34 - Cloudera [13] >>>>> m...@apache.org - 1 - Trend Micro [14] prasadm - 34 - Cloudera >>>>> [15] t...@cloudera.com - 3 - Cloudera [16] w...@cloudera.com - 3 >>>>> - Cloudera [17] >>>>> >>>>> Looking at this, the average number of issues resolved by >>>>> Cloudera committers (not counting Tom who is a mentor) is 26, >>>>> and that for non-Cloudera committers is 5. Note that this >>>>> number does not include other committer work such as the number >>>>> of code reviews they have done, the number of design >>>>> discussions they have participated in, something that is very >>>>> valuable to the project. >>>> >>>> >>>> Another way of looking at these same statistics: Cloudera - 217 >>>> Other - 16 >>>> >>>> That means Cloudera is responsible for over 93% of the Jira >>>> issues. It is great that Cloudera is doing so much work but >>>> those stats hardly prove diversity. >>>> >>>> >>>> Ralph >>>> >>>> >>>> --------------------------------------------------------------------- >>>> >>>> > 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 >
