On Feb 3, 2015, at 3:26 AM, Adi Roiban <adi@roiban.ro> wrote:

On 2 February 2015 at 19:18, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
[snip]
Candidates should submit an application to this new list,
commit@twistedmatrix.com which is a list of links to at least 10 tickets, at
least 5 of which are patches they've submitted, and at least 5 of which are
code reviews they've done which have been accepted by a committer.  At least
2 of their authored patches should have gone all the way through the process
to be landed.

I am not a supporter of private discussions for public projects... but
I am ok with having something.
I agree that Twisted general discussion

As a general rule I would agree with these sentiments, but generally, open projects are discussing specific bits of code.  In this case, we're talking about actually evaluating people as worthy or unworthy of commit access.

Open source contributors should take a rejection as an opportunity to improve.

Sure, we accept this as part of the normal review process.  And we accept it here as well, as part of a private discussion.  But it is hard to accept public shaming as an opportunity to improve.  Private feedback is much easier to give, and it is much easier for the contributor to take.

Open source maintainer should not accept patches or add new contributors just to be nice.

We do not have trouble rejecting patches, because we are able to keep the focus entirely on the patch, because that is what is being evaluated, and not the contributor.  Of course here the focus should be entirely on the work too, but it is hard enough to keep the discussion centered that way in code review :).

I would say that we should ask for 5 patches which were merged.
I find that 2 patches are too few.

This is more of a minimum; if they are 2 substantial patches, that seems like more than enough.  But the committee reserves the right to say "this is not enough significant work".

Also 2 patches for cleanup jobs are fine, but I don't think that they
are enough.

As with the other parts of our process, if there is at least one sponsor,
and no objections from anyone on the committee within 7 days, any member of
the committee may add the committer.

New committers should then be announced on the mailing list.

This is not really an ideal process - particularly, it lacks a good way to
give contributors something specific and useful to do - but it's something
at least.  If there is general assent that this is an improvement, I'll go
make a wiki page and a mailing list.

Should be a start and much better than current process.

As soon as the committee is in place I will apply for commit rights to
practice the process and also validate that I deserve the commit
right.

Thank you for volunteering :-).

Meanwhile I will start recording my activity.

For new contributors, I suggest that they can create a wiki page to
keep track of the tickets.

That sounds like a great idea.

I have no idea how you can use Trac report to give you a list of
tickets you have reviewer or you have contributed patches to.

I'm not sure if external contributors have enough access to the SQL.  Maybe we can make a report that queries the database directly rather than going through trac, like <http://twistedmatrix.com/highscores/>.

------

Since some Twisted related project are on GitHub it would be nice to
discuss some direction about how to get edit rights for those
projects.

Thanks!

I think we should probably follow the same process; the main question is whether each project should have its own set of core reviewers.  I honestly don't have an idea for that :).

-glyph