[development] Very concerned over Drupal's core development

[Alex Barth]

On Apr 20, 2009, at 3:39 PM, Angela Byron wrote:

>
> On 20-Apr-09, at 2:44 PM, Earl Miles wrote:
>
>> The reason I think more committers in targeted areas will work is  
>> because I think it will create more activity in those areas. The  
>> people who have the right to commit will have a more vested  
>> interest, and therefore you will get more of their time, effort and  
>> energy, plus any that they can draw to them. webchick commented  
>> earlier that one of the issues was providing an incentive to do  
>> reviews. And that's certainly a key issue, right there. There isn't  
>> much incentive to do reviews. There's the good of the project, but  
>> there is no pride of ownership in a review. The pride of ownership  
>> drives a lot of the initial development, and it drives the  
>> committers, but the reviewers?
>>
>> I cannot remember a time in the 4 years I've been with this project  
>> that we haven't had a longstanding complaint about lack of good  
>> patch reviews. That is one of the first complaints I heard then,  
>> and it is one of the complaints I hear now. It has not changed, and  
>> asking people to do more reviews has already proven to be  
>> ineffective in combatting the issue.
>>
>> Give your reviewers some ownership and you'll find a lot more  
>> people interested in reviewing.
>
> Now this "how to get more reviewers" is a line of discussion I'm  
> *very* interested in having since, regardless if we have subsystem  
> committers or not, we need to resolve it.

A huge disincentive for getting involved in core is that it doesn't  
yield immediately deployable results. This keeps shops  and  
individuals from putting more labor towards core work.

Robert Douglass suggested on this thread to remove modules that don't  
absolutely need to be in core (aggregator, blog, blogapi, forum). I  
absolutely concur. This would not just make core easier to overlook  
and remove a huge tax from the drupal core infrastructure, but it  
would most importantly allow us to release and deploy these modules  
quicker.

Like mentioned already by others on this thread, these modules could  
create a new tier of Drupal modules on d.o. that would be packaged  
with installer profiles and maintained for core compatibility for  
every release of the current Drupal release branch and Drupal HEAD.

In my mind, such a third tier of modules would fill the gap between  
core and contrib: it would create a peer reviewed space between Drupal  
core and Drupal contrib while not suffering from long release cycles.  
In turn we would get more reviewers for the new tier of modules but I  
also for Drupal core as there is going to be more activity on modules  
that will be available in the current release branch *and* in HEAD.

A third tier of Drupal modules does not solve all issues of course,  
but I think it makes our problem *a lot* smaller.

>
>
> Here are some ideas around that:
>
> 1. A community-led mentorship/journeyman program for people who want  
> to get involved in core development and don't know where to start.  
> Basically, taking what we do at code sprints at Drupalcons twice a  
> year that always lead to a big increase in new core contributors,  
> and making an e-version of it, or something that could be done in  
> person at camps and local meetups.
>
> 2. Developing some sort of system that can formalize a bit more  
> "patch review swaps." The biggest incentive people currently have  
> for reviewing a patch is that they want one in core and need to get  
> other reviewers to look at it in order to do so. Making it easier to  
> identify people who are willing to engage in this would help  
> everyone out.
>
> 3. Providing tools on g.d.o, d.o, or elsewhere to make it easier for  
> core subsystem maintainers to nurture their pocket of Drupal core.  
> Not really sure what those would be yet. Perhaps one aspect could be  
> liaising with the documentation team to help get their subsystem  
> documentation cleaned up and some clear step 1, step 2, step 3 stuff.
>
> 4. Monthly contests for "review queue smashing," like other projects  
> have "bug fix days" or similar. Winners get their name in lights on  
> the d.o front page, or we could pony up for some cash incentives or  
> similar.
>
> 5. Calling specific attention out to people who did thorough reviews  
> in commit messages, either by including them in the list of  
> contributors or something like "#xxxx by dev1, dev1, and reviewed by  
> rev1: wah wah wah."
>
> 6. Add more people to MAINTAINERS.txt, and have it reflect the  
> current committer "trust" model. If that document can be trusted,  
> this makes it easier for reviewers to know who to talk to if they're  
> interested in helping out with X system. We could also add subsystem  
> maintainer names to the pages on http://drupal.org/community-initiatives/drupal-core 
>  perhaps.
>
> Curious about others people might have as well.
>
> -Angie
>

Alex Barth
http://www.developmentseed.org/blog
tel (202) 250-3633