[DISCUSS] Re: [VOTE] Tim Kim as committer

[Ross Gardler <rg...@opendirective.com>]

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)

Ross

On 23 March 2012 16:37, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Thu, Mar 22, 2012 at 11:36 PM, Brian LeRoux <b...@brian.io> 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 apache.org [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 apache.org. Thus my +1.
>
> As for BlackBerry, I don't see related commits or issues from Tim on
> either apache.org 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] http://callback.markmail.org/search/from:kim
>
> BR,
>
> Jukka Zitting



-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Re: [DISCUSS] Re: [VOTE] Tim Kim as committer

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Fri, Mar 23, 2012 at 7:00 PM, Filip Maj <fi...@adobe.com> wrote:
> 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!).

To elaborate a bit on that vote (I was the one who cast the -1), while
contributions are a prerequisite for committership (Apache is a
meritocracy) the exact amount and level of expected contributions is
up to the (P)PMC to set. You could even decide that just joining the
dev@ list and asking for committership shows enough committment to the
project.

The important bit here is that this level is applied equally to all
contributors. At the time of the mentioned vote there were dozens of
other contributors with more merit in terms of public contributions,
but they hadn't yet been nominated for committership. This implies
that there indeed is an implicit entry barrier even if it hasn't
spelled out. Seeing that the nominee hadn't yet reached the level of
contributions from other non-committers, the only reasonable vote IMHO
was -1.

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

In general I agree with you here. There's always an aspect of
subjective judgement when casting votes like this, and trying to
reduce that to written rules is a futile effort.

However, since there's at least the perception of an uneven entry
barrier, I think it would be a good to clear up at least general
outlines of what is expected from contributors before they'll be
nominated for committership. The wiki page at
http://wiki.apache.org/cordova/BecomingACommitter is a good starting
point for that.

See also http://community.apache.org/newcommitter.html for related
Apache documentation and http://markmail.org/message/4nknqowil3yuw6tl
for a recent general@incubator thread about this.

BR,

Jukka Zitting

Re: [DISCUSS] Re: [VOTE] Tim Kim as committer

[Ross Gardler <rg...@opendirective.com>]

OK, with the context you provide below. I recall the discussion you refer
to and agree with the comments made by the other mentor (silence means
approval in the ASF). To summarize my general position commiters need to
earn their privileges they should not be awarded to someone simply based on
a promise of contribution.

Exactly what is needed to earn those privileges is up to the community to
define. Thanks for starting that process, I look forward to reviewing it
when the community are happy with it.

Ross

Sent from my mobile device, please forgive errors and brevity.
On Mar 23, 2012 6:00 PM, "Filip Maj" <fi...@adobe.com> wrote:
>
>
> >> 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
> >point.
>
> Agreed, I started that here:
> http://wiki.apache.org/cordova/BecomingACommitter
>
> We will work towards fleshing that out.
>
> >
> >Ross
> >
> >>
> >> What downsides does this approach pose?
> >>
> >> On 3/23/12 9:55 AM, "Ross Gardler" <rg...@opendirective.com> 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)
> >>>
> >>>Ross
> >>>
> >>>On 23 March 2012 16:37, Jukka Zitting <ju...@gmail.com> wrote:
> >>>> Hi,
> >>>>
> >>>> On Thu, Mar 22, 2012 at 11:36 PM, Brian LeRoux <b...@brian.io> 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 apache.org [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 apache.org. Thus my +1.
> >>>>
> >>>> As for BlackBerry, I don't see related commits or issues from Tim on
> >>>> either apache.org 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] http://callback.markmail.org/search/from:kim
> >>>>
> >>>> BR,
> >>>>
> >>>> Jukka Zitting
> >>>
> >>>
> >>>
> >>>--
> >>>Ross Gardler (@rgardler)
> >>>Programme Leader (Open Development)
> >>>OpenDirective http://opendirective.com
> >>
> >
> >
> >
> >--
> >Ross Gardler (@rgardler)
> >Programme Leader (Open Development)
> >OpenDirective http://opendirective.com
>
 On Mar 23, 2012 6:00 PM, "Filip Maj" <fi...@adobe.com> wrote:

>
> >> 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
> >point.
>
> Agreed, I started that here:
> http://wiki.apache.org/cordova/BecomingACommitter
>
> We will work towards fleshing that out.
>
> >
> >Ross
> >
> >>
> >> What downsides does this approach pose?
> >>
> >> On 3/23/12 9:55 AM, "Ross Gardler" <rg...@opendirective.com> 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)
> >>>
> >>>Ross
> >>>
> >>>On 23 March 2012 16:37, Jukka Zitting <ju...@gmail.com> wrote:
> >>>> Hi,
> >>>>
> >>>> On Thu, Mar 22, 2012 at 11:36 PM, Brian LeRoux <b...@brian.io> 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 apache.org [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 apache.org. Thus my +1.
> >>>>
> >>>> As for BlackBerry, I don't see related commits or issues from Tim on
> >>>> either apache.org 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] http://callback.markmail.org/search/from:kim
> >>>>
> >>>> BR,
> >>>>
> >>>> Jukka Zitting
> >>>
> >>>
> >>>
> >>>--
> >>>Ross Gardler (@rgardler)
> >>>Programme Leader (Open Development)
> >>>OpenDirective http://opendirective.com
> >>
> >
> >
> >
> >--
> >Ross Gardler (@rgardler)
> >Programme Leader (Open Development)
> >OpenDirective http://opendirective.com
>
>

Re: [DISCUSS] Re: [VOTE] Tim Kim as committer

[Filip Maj <fi...@adobe.com>]

>> 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
>point.

Agreed, I started that here:
http://wiki.apache.org/cordova/BecomingACommitter

We will work towards fleshing that out.

>
>Ross
>
>>
>> What downsides does this approach pose?
>>
>> On 3/23/12 9:55 AM, "Ross Gardler" <rg...@opendirective.com> 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)
>>>
>>>Ross
>>>
>>>On 23 March 2012 16:37, Jukka Zitting <ju...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> On Thu, Mar 22, 2012 at 11:36 PM, Brian LeRoux <b...@brian.io> 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 apache.org [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 apache.org. Thus my +1.
>>>>
>>>> As for BlackBerry, I don't see related commits or issues from Tim on
>>>> either apache.org 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] http://callback.markmail.org/search/from:kim
>>>>
>>>> BR,
>>>>
>>>> Jukka Zitting
>>>
>>>
>>>
>>>--
>>>Ross Gardler (@rgardler)
>>>Programme Leader (Open Development)
>>>OpenDirective http://opendirective.com
>>
>
>
>
>-- 
>Ross Gardler (@rgardler)
>Programme Leader (Open Development)
>OpenDirective http://opendirective.com

Re: [DISCUSS] Re: [VOTE] Tim Kim as committer

[Ross Gardler <rg...@opendirective.com>]

On 23 March 2012 17:09, Filip Maj <fi...@adobe.com> wrote:
> I'm confused as to why we have to have *any* barriers to entry, especially
> if the community votes on committership anyways.

Don't take my comments to indicate that their should be barriers, as I
said I'm a fan of low barriers.

> 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?

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
point.

Ross

>
> What downsides does this approach pose?
>
> On 3/23/12 9:55 AM, "Ross Gardler" <rg...@opendirective.com> 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)
>>
>>Ross
>>
>>On 23 March 2012 16:37, Jukka Zitting <ju...@gmail.com> wrote:
>>> Hi,
>>>
>>> On Thu, Mar 22, 2012 at 11:36 PM, Brian LeRoux <b...@brian.io> 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 apache.org [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 apache.org. Thus my +1.
>>>
>>> As for BlackBerry, I don't see related commits or issues from Tim on
>>> either apache.org 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] http://callback.markmail.org/search/from:kim
>>>
>>> BR,
>>>
>>> Jukka Zitting
>>
>>
>>
>>--
>>Ross Gardler (@rgardler)
>>Programme Leader (Open Development)
>>OpenDirective http://opendirective.com
>



-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Re: [DISCUSS] Re: [VOTE] Tim Kim as committer

[Filip Maj <fi...@adobe.com>]

I've started that here:

http://wiki.apache.org/cordova/BecomingACommitter


Cordova community: we should hash this out. Discuss here/contribute to the
article!

On 3/23/12 10:26 AM, "Jukka Zitting" <ju...@gmail.com> wrote:

>Hi,
>
>On Fri, Mar 23, 2012 at 6:09 PM, Filip Maj <fi...@adobe.com> wrote:
>> I'm confused as to why we have to have *any* barriers to entry,
>>especially
>> if the community votes on committership anyways.
>>
>> I would be a fan of a "if x people vote +1, and no one voted -1, let the
>> person in" mentality.
>>
>> What downsides does this approach pose?
>
>It should be fine as long as the same criteria is applied to all
>members of the community. We don't want a situation where only one of
>two otherwise identical community members gets nominated and voted in
>while the other is either not nominated in the first place or rejected
>with a -1 vote. Having the expected level of contribution (even if
>it's just "show up on the mailing list and ask to be given commit
>access") written down somewhere as Ross suggested helps prevent this
>problem.
>
>Note also that by granting someone membership in the (P)PMC, you also
>give them veto power [1] over all code changes. That's not necessarily
>a problem, just something to take in to account when inviting new
>people.
>
>[1] http://www.apache.org/foundation/voting.html#Veto
>
>BR,
>
>Jukka Zitting

Re: [DISCUSS] Re: [VOTE] Tim Kim as committer

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Fri, Mar 23, 2012 at 6:09 PM, Filip Maj <fi...@adobe.com> wrote:
> I'm confused as to why we have to have *any* barriers to entry, especially
> if the community votes on committership anyways.
>
> I would be a fan of a "if x people vote +1, and no one voted -1, let the
> person in" mentality.
>
> What downsides does this approach pose?

It should be fine as long as the same criteria is applied to all
members of the community. We don't want a situation where only one of
two otherwise identical community members gets nominated and voted in
while the other is either not nominated in the first place or rejected
with a -1 vote. Having the expected level of contribution (even if
it's just "show up on the mailing list and ask to be given commit
access") written down somewhere as Ross suggested helps prevent this
problem.

Note also that by granting someone membership in the (P)PMC, you also
give them veto power [1] over all code changes. That's not necessarily
a problem, just something to take in to account when inviting new
people.

[1] http://www.apache.org/foundation/voting.html#Veto

BR,

Jukka Zitting

Re: [DISCUSS] Re: [VOTE] Tim Kim as committer

[Filip Maj <fi...@adobe.com>]

I'm confused as to why we have to have *any* barriers to entry, especially
if the community votes on committership anyways.

I would be a fan of a "if x people vote +1, and no one voted -1, let the
person in" mentality.

What downsides does this approach pose?

On 3/23/12 9:55 AM, "Ross Gardler" <rg...@opendirective.com> 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)
>
>Ross
>
>On 23 March 2012 16:37, Jukka Zitting <ju...@gmail.com> wrote:
>> Hi,
>>
>> On Thu, Mar 22, 2012 at 11:36 PM, Brian LeRoux <b...@brian.io> 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 apache.org [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 apache.org. Thus my +1.
>>
>> As for BlackBerry, I don't see related commits or issues from Tim on
>> either apache.org 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] http://callback.markmail.org/search/from:kim
>>
>> BR,
>>
>> Jukka Zitting
>
>
>
>-- 
>Ross Gardler (@rgardler)
>Programme Leader (Open Development)
>OpenDirective http://opendirective.com