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

[Eric Scouten]

A couple of radical-thought ideas (almost certainly too late for 4.6):

* Admin-configurable status options (not all of the existing status 
fields will work for everybody)

Taking that idea a bit further...

* Scrap the existing project & issue node types and rebuild them as 
default packages for flexinode. This would mean flexinode (or a related 
module) would have to gain a lot of search, sort, and display tabular 
summaries. IMHO that would be a useful addition.

-Eric



Andre Molnar wrote:
> 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
>>
>>
> 
>