>> 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" <rgard...@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.zitt...@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
