[drupal-devel] Should we make project issue status more nuanced?

[Andre Molnar]

The idea of additional statuses (e.g. "reviewed" or "tentatively
approved") is good IMHO.

 >As an additional step, we could create a new drupal.org role, and 
limit >the ability to set these new status categories to users in this 
role >i.e., recognized core contributors/developers).

Is likewise a good idea.

Ironically, you could get the ball rolling by submitting a patch to the 
project module.

andre

Nedjo Rogers wrote:
> Following up on recent discussions on drupal decision-making and 
> structure (thanks for the many comments, particularly Steven's recent
>  succinct summary, http://drupal.org/node/15916#comment-26377), I'd 
> like to look at some practical improvements to the system we use for 
> evaluating patches, see my reply to Steven's comment at 
> http://drupal.org/node/15916#comment-26627.
> 
> I know I could suggest this as a patch on the project module, but I'd
>  like to start with a more general testing of the waters.  And, if 
> your eyes are glazing over as you mutter "not him again with his 
> structure babble", please bear with me, I think we might be on to 
> something.
> 
> The basic issue is that too much is put on the single status, 
> "patch".  To see the problem in action, we only have to do a search 
> on Drupal project issues with status=patch.  I currently get a total 
> of 124 matches, some ranging up to 33 weeks old.
> 
> I'm not suggesting the CVS review team is doing anything but 
> excellent work. I know that for my part I can't properly keep up even
>  with the issues for the modules I maintain.  I have nothing but 
> appreciation for the work Dries, Steven, and Kjartan do.
> 
> But they're not able on their own to work through everything.
> 
> When I go through the outstanding patches, I find quite a few that 
> look (to my not wholly qualified eye) ready to apply--that is, they 
> received discussion, support was evinced, issues raised were to all 
> appearances addressed.  Some proposals were very small, but useful. 
> Often the only obvious missing factor is that the patch is now 
> outdated, having sat for so long.
> 
> Others don't meet these criteria (e.g., lack demonstrated support).
> 
> What happens currently is that an issue jumps straight from "patch" 
> to "applied"--that is, the status change comes *after* the 
> decision-maker (most often, Dries) has made the change.
> 
> What's missing is a way for Drupal contributors - more specifically, 
> the subset of developers who are qualified to do so - to pre-filter 
> the patches--basically, to put them in a queue for approval, 
> indicating that, in their view, the patch meets our approval criteria
>  (set out in the Handbook at http://drupal.org/node/10262).
> 
> Concretely, I'm thinking of an additional status category after 
> "patch":
> 
> * "reviewed" or "tentatively approved"
> 
> This would be set when a qualified Drupal member (e.g., a maintainer,
>  or other recognized core contributor) judged the patch meets our 
> criteria.
> 
> To help even further to increase the community role in 
> decision-making (and thereby relieve the pressure or bottleneck on 
> the CVS review team), we could also consider a time factor.  I'm 
> thinking that, when a given amount of time has passed after a patch 
> was deemed "tentatively approved" and no further issues have been 
> raised, the patch would (likely, automatically) move to a second 
> additional category:
> 
> * "pending application"
> 
> providing a further indication of readiness.
> 
> Of course, the actual decision would remain with the CVS review team,
>  who could still raise issues (downgrade the status, deny the 
> proposal, etc.).
> 
> As an additional step, we could create a new drupal.org role, and 
> limit the ability to set these new status categories to users in this
>  role (i.e., recognized core contributors/developers).  Thus we could
>  make sure this judgement was made by qualified members (and would be
>  roughly equivalent to what I think we do e.g. for documentation--a 
> role with permissions to edit the Handbook).
> 
> What to people think of these suggestions?  Would they help improve 
> our code review system?
> 
> Thanks, Nedjo Rogers
> 
>