incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: [DISCUSS] Re: [VOTE] Tim Kim as committer
Date Fri, 23 Mar 2012 18:00:24 GMT

>> I would be a fan of a "if x people vote +1, and no one voted -1, let the
>> person in" mentality.
>That's the recommended practice for all ASF projects. Nothing I said
>suggests I'm saying this should be otherwise does it?

Nothing you said implied anything like that, Ross. Rather, there was a
discussion that came up earlier on the private mailing list where a mentor
said that a potential committer coming in and being voted on inclusion
*needs* some manner of patch / code / documentation / anything contributed
to the project (or at least in the queue for inclusion) before being
allowed in. This essentially stopped someone's inclusion into the project
(first ever -1 vote!).

Forgive the vagueness of the above but it was on the private list ;)

I would prefer we eliminate that requirement and simply rely on the
community's existing committers to use their vote responsibly.

>What I asked for is for someone on this project to document what is
>expected of a contributor who is a candidate for committership. I did
>not say such a document should make it hard. Therefore I'm a little
>confused by your question below. Please restate if I'm missing your

Agreed, I started that here:

We will work towards fleshing that out.

>> What downsides does this approach pose?
>> On 3/23/12 9:55 AM, "Ross Gardler" <> wrote:
>>>Thank Jukka, I've been avoiding casting my mentor vote as I was
>>>unclear about the policies being adopted here. They felt uneven to me
>>>but I thought it was perhaps because I've not being paying enough
>>>attention, or perhaps it was because of this (to me) unfamiliar way of
>>>working with github forks.
>>>It's kind of strange because I'm a fan of very low barriers to entry
>>>for projects. Usually as a mentor I find myself having to prompt
>>>podlings to bring in new people. Here I find the opposite.
>>>I'd really appreciate it if the project team could put together some
>>>guidelines against which new committers will be evaluated. What is is
>>>that they are looking for?
>>>I'd also really appreciate it if VOTE threads contained some evidence
>>>of contributions in the form of appropriate likes to commits, mail
>>>traffic, documentation edits, etc. This both helps reviewers of the
>>>vote and helps demonstrate to others how easy it is to gain an input
>>>here (which is often a motivating factor)
>>>On 23 March 2012 16:37, Jukka Zitting <> wrote:
>>>> Hi,
>>>> On Thu, Mar 22, 2012 at 11:36 PM, Brian LeRoux <> wrote:
>>>>> Lets try this again! Tim has been working w/ the BlackBerry platform
>>>>> for some time and taken a lead on the coho release tool.
>>>> +1
>>>> This is a hard call if you look at just the community interactions
>>>> recorded on [1]. There's a lot of people with similar
>>>> levels of participation around here, so singling Tim out as someone to
>>>> be given commit access raises all sorts of questions about fairness
>>>> and equal access.
>>>> That said, I see his work on the coho tool on GitHub and since coho
>>>> really should be an integral part of Cordova, it makes sense to grant
>>>> Tim committership along with bringing coho to Thus my +1.
>>>> As for BlackBerry, I don't see related commits or issues from Tim on
>>>> either or GitHub. Perhaps I'm just not looking at the right
>>>> place.
>>>> PS. I hate to question someone's commitment on a public list, which is
>>>> why votes like this one should IMHO be held on private@.
>>>> [1]
>>>> BR,
>>>> Jukka Zitting
>>>Ross Gardler (@rgardler)
>>>Programme Leader (Open Development)
>Ross Gardler (@rgardler)
>Programme Leader (Open Development)

View raw message