After the discussion on private@geode, I personally came away liking this criteria the best - A person should become a committer at the point at which it is obvious that I'd rather have them check directly into SCM than merge the patch myself based on the contributions I've seen from them so far.
I do think being involved in these different areas - code changes,mailing list, jira, wiki, etc. - helps build trust, but I don't think potential committers should be required to contribute to a bunch of different categories. Also, I think looking at the dashboard is not a good way to judge a potential committer - a count doesn't really tell you that much about how much you trust someone's contributions. -Dan On Wed, Jan 6, 2016 at 5:30 PM, Greg Chase <[email protected]> wrote: > With the occasion of a request to vote in our first additional committer, > its become clear that we don't have clear criteria for when someone should > become a committer. > > The steps for becoming a committer are listed here in the wiki: > https://cwiki.apache.org/confluence/display/GEODE/Becoming+a+committer > > And include these steps: > > > > 1. Once you become a contributor you *will probably be invited by* > > another committer to be a new committer and *the community will vote* > > > > > > 1. *If the vote pass *and you get accepted... > > > > > But there are no criteria by which someone should be nominated, or by which > committers / PPMC should vote according to. > > In a discussion on private@geode, a number of good points have been raised > which I will paraphrase. The makers of these points can choose to weigh in > directly to this thread if they want their statement refined or attributed > to them. > > 1. "The Committers" are currently the same as "The PPMC". So at this > point, voting someone as a committer is voting them as the potential future > PMC of Apache Geode. > > 2. Becoming a committer should be used to recognize a contributor as having > further potential to contribute even more, and to encourage them to > participate with and collaborate more with the community. > > In my personal opinion, contributors who show themselves as collaborative, > community building, or supportive of users with a likelihood of > contributing even more should be nominated and likely voted by the PPMC to > be a contributor. > > While not the only source, many behaviors related to being collaborative, > community building, or supportive of users is captured by our community > dashboard: http://projects.bitergia.com/apache-geode/browser/ > > Thus I'd expect high contributors in these areas to rank in top lists as > follows: > > Collaborative: > Jiras: open, comment, close > Dev mail list: open threads, reply > Git: commits > Code reviews > > Someone who does not collaborate and only develops would likely only show > up in pull requests, but not other collaborative infrastructure. > > Community building would include: > Dev & user mail lists > Wiki / confluent editing > > User supporting would incldue: > User mail list responses > Jiras opened and commented on > > I'm sure these lists can be better refined. > > While I wouldn't quantify this, I would argue that if someone shows up in > multiple categories of contribution on top lists for more than one 30 day > period, they are likely candidates to be nominated as a committer. > > I know of at least a couple of companies that pay their employees to be > contributors to Apache Geode. If their job changes, or they move to a > different company, will they stay as a contributor if we make them a > committer? I'd argue this is much more likely if we see them contributing > in multiple categories rather than just a single way. > > Finally, we need to create a model and standard of how we want our > community to act. By being more specific about asking for broader > contribution to be recognized as a committer, this will help train new > members of this community how to participate fully. > > I'll appreciate comments on these, and if I get enough agreement, I will > add a proposed criteria to the wiki. > > Regards, > > -Greg >
