I agree with Sebastian. The criteria should look not only at Quantity but at the Quality of work as well.
This page for Apache committer criteria describes the criteria pretty well. https://hadoop.apache.org/committer_criteria.html - *A history of sustained contribution to the project. This is a way for a contributor to demonstrate their expertise in an area, and thus their ability to help review and commit contributions by others in that same area. Sustained contribution is also a way of demonstrating commitment to the project, essentially that someone will continue contributing even after they become a committer.* - *High-quality contributions. As experienced contributors, committers set an example for others in the project, and help inculcate a culture of high-quality contributions. For code contributions, this means clean, documented code which includes unit tests if appropriate and passes precommit checks. For reviews, this means thorough, actionable feedback, and a +1 vote (even non-binding) only when there is a high degree of confidence in the change.* - *Community involvement. Contributors are always expected to be polite, constructive, and respectful of others during community interactions. Disagreement can (and will) happen over technical issues, but the discussion should remain friendly and focused on technical merits. Committers also have the additional responsibility of mentoring newer contributors, as well as helping to grow the community through actions like responding to emails on the user and dev list.* I would add another point that the committer should have the backbone to say no to contributions that do NOT meet the high quality bar but yet mentor the contributor in reaching that high bar. This is difficult to quantify but is a quality that is expected to be demonstrated in various conversations of the person being nominated to be the committer. Bhavin Thaker. On Wed, Aug 9, 2017 at 11:03 PM, Sebastian <s...@apache.org> wrote: > > Another thing might be that having too many committers makes it less >> valuable to >> become a committer and therefore discourage new people. >> > > In my experience, quite the opposite is true: Having many committers is > beneficial for a project and makes life easier for everybody. There's more > eyes to look at code contributions, more people answer questions and it > also makes it easier for other committers to take time outs from the > project (which might be necessary if they change jobs, have kids, etc) > > I think the important thing to look at is not the number of committers, > but the culture and processes in a project. > > Best, > Sebastian >
