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