Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of rgardler@opendirective.com
 designates 74.125.82.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CB920524.284C%fil@adobe.com>
References: 
 <CAKQbXgALvEB3ETNxDY-fbmEb+Z8WDFo5uBXrxyFg3hpbCd4B5Q@mail.gmail.com>
	<CB920524.284C%fil@adobe.com>
Date: Fri, 23 Mar 2012 18:40:56 +0000
Message-ID: 
 <CAKQbXgApZ2z1mXvfOSSZVXiccUnHarcjFmFV0nkJC=LryMJrFA@mail.gmail.com>
Subject: Re: [DISCUSS] Re: [VOTE] Tim Kim as committer
From: Ross Gardler <rgardler@opendirective.com>
To: callback-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=f46d043bdce870cbee04bbed5ded

--f46d043bdce870cbee04bbed5ded
Content-Type: text/plain; charset=ISO-8859-1

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" <fil@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" <rgardler@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 <jukka.zitting@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" <fil@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" <rgardler@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 <jukka.zitting@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
>
>

--f46d043bdce870cbee04bbed5ded--