[development] CVS Approval Policy: was Re: new features in D6 core?

Kevin Reynen kreynen at gmail.com
Fri Oct 23 22:47:34 UTC 2009


Adding to the potential flame fodder...

We've actually encouraged non-developers who will likely never commit
anything to CVS to request CVS accounts so we can leverage Project on D.O.
as a project management tool.   While anyone can take ownership of an issue
themselves, the list of people someone with CVS access can assign an
issue/task/feature to is limited to the other users with CVS access to the
module or theme.

We've just started scratching the surface of this functionality, but every
person from the Open Media Project who requested a CVS account was
approved.

- Kevin Reynen

On Fri, Oct 23, 2009 at 4:35 PM, Dave Reid <dave at davereid.net> wrote:

> This is going to be one of those discussions we always have like backwards
> compatibility between major versions.
>
> Yes, the main point is there are way too few people helping review
> applications. I do agree that whoever is reviewing always needs to be
> compassionate and be able to justly explain his or her decision, which
> currently doesn't always happen.
>
> Just because someone can follow CVS licensing doesn't mean I should approve
> a better_views module or a better_cck module. This is also our opportunity
> to prevent duplicate or unnecessary modules, the latter being a fine line. A
> small, trivial 10-line customization that runs hook_form_alter() should be
> approved?
>
> This needs effort from all sides:
> 1. CVS admins/reviewers to always be helpful and make sound decisions since
> it is usually the applicant's beginning attempt at contributing code.
> 2. The existing community (the 8 non-CVs admins) to actually care about the
> new members and help with application review. This only happens where there
> are problems. If people were looking at the CVS applications and chime in
> and say "Wow, I've always needed this. This would make a great module," that
> would make the decision easier for the admins and we probably wouldn't be
> having this discussion.
> 3. CVS applicants always submitting thoughtful and thorough application. I
> think Andrew falls into this case, but there are a lot that don't. Makes the
> job harder for both 1 and 2.
>
> See http://drupal.org/cvs-application/requirements and
>
> Dave Reid
> dave at davereid.net
>
>
>
> On Fri, Oct 23, 2009 at 4:50 PM, Bill Fitzgerald <bill at funnymonkey.com>wrote:
>
>> A quick observation here, and feel free to flame this mercilessly [1].
>>
>> As I see it, the purpose of the review of application should be to
>> determine whether the applicant will comply with the d.o requirements
>> regarding licensing, etc -- it should *not* be to judge the merits of the
>> proposed module.
>>
>> In this case, and in others I have seen, people have been unnecessarily
>> hassled during the CVS application process.
>>
>> As a community, we are shooting ourselves in the foot if we hassle/turn
>> away developers, especially when we are turning them away for invalid
>> reasons.
>>
>> If Andrew hadn't posted to the Dev list, his good idea would not have had
>> the opportunity to make it into the community. I wonder how many other good
>> ideas have been lost for the exact same reason.
>>
>> Cheers,
>>
>> Bill
>>
>> [1]. Yes, I know that there are a small number of people triaging a large
>> number of CVS applications.
>>
>> Andrew Schulman wrote:
>>
>>>  You could always build it out as a contrib module, though. It sounds
>>>>>> pretty
>>>>>> useful.
>>>>>>
>>>>> Thanks.  Unfortunately, when I tried that the CVS masters said that my
>>>>> proposed
>>>>> module was "too simple" to justify granting me an account
>>>>> (http://drupal.org/node/606962).
>>>>>
>>>>>
>>>> This has been rectified.
>>>>
>>>>
>>>> Cheers,
>>>>        Gerhard
>>>>
>>>
>>> Thank you.
>>> Andrew.
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20091023/aa4c4f73/attachment.html 


More information about the development mailing list