[drupal-devel] Should we make project issue status more nuanced?
drupal.org at list.ericscouten.com
Wed Jan 26 07:19:37 UTC 2005
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.
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.
> 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
>> 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
>> 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
>> 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
More information about the drupal-devel