[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tools-leads] Guidelines for nominating a committer in a Tools sub-project

We certainly haven't stated a guideline. And I think every project has different needs especially depending on how healthy the contributor community is.

Even over the life of the CDT we've adjusted our criteria depending on how desperate we were to get contributions. And today, it really comes down to how annoyed a committer gets at having to work on so many patches from a contributor that they nominate them.

I guess the guideline I'd like to promote is that you don't nominate someone until you trust them well enough to give them write access to the code. Also make sure your fellow committers are comfortable also. Vetoes are ugly things but are the right of any committer in an election. Make sure everyone is happy and that of course is made easier if you can show them the good work that the nominee has already done.
That's very hand-wavy, but at the end it comes down to "Do the right thing", my motto for everything. Nominating someone before they've contributed anything probably isn't a good idea and will be subject to a veto from the PMC, unless it's someone you dearly trust and can convince the community they can trust them too.

Does anyone else have opinions?

> -----Original Message-----
> From: tools-leads-bounces@xxxxxxxxxxx [mailto:tools-leads-
> bounces@xxxxxxxxxxx] On Behalf Of ERIC CLONINGER
> Sent: Wednesday, April 27, 2011 2:26 PM
> To: List for all of the Tools projects PLs
> Subject: [tools-leads] Guidelines for nominating a committer in a Tools sub-
> project
> Sequoyah has recently moved over from the defunct DSDP, so there will be
> some learning how things are done "over here".
> In DSDP, we had a guideline that we tried to follow before accepting a new
> committer. We usually wanted to see at least 3 "quality contributions" and
> some assurance that contributions would continue before nominating
> someone as a committer. I think the intentions were good in that we wanted
> to know someone was willing to support their contributions and was
> interested in the future of the project. It worked differently for sponsoring
> companies as those entities had a monetary interest in seeing various Eclipse
> projects succeed. But still, we wanted to see that anyone who is adding code
> into a project could maintain the expected quality level.
> Is there a similar guideline within Tools? Either as an individual or as an
> employee of a sponsoring company?
> Thanks!
> --
> Eric Cloninger (ericc@xxxxxxxxxxxx)
> Product Line Manager, MOTODEV Tools
> Eclipse Sequoyah Project Lead
> _______________________________________________
> tools-leads mailing list
> tools-leads@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/tools-leads