This is a proposal for an update to the current 'Project Application' issue page, which would add the ability to flag statuses to individual components of an application.
Implementation
Implementation would be through a custom sub-module containing a hook_preprocess function, which would add the component status and update form to the page only for "Project Application" issues. This sub-module would be submitted as a patch to the Drupal.org Customizations project. If a pre-process function affecting all issues is considered too intrusive for d.o, a jQuery-based approach could also be used.
Operation
To discourage applicants from self-promoting gates to 'Passed', users would only have access to the 'Pending', 'Needs Review', and 'Needs Work' component statuses on their own application. Other reviewers would have access to set any status.
Updating the review component status would also update the status for the overall issue:
- Any component set to 'needs work' would result in the project application being set to 'needs work'.
- Any component update that results in no more 'needs work' or 'blocked' statuses remaining would result in the project application being set to 'needs review'.
- Any change of component status would be recorded in the Project Application comments, indicating who modified the status and the before/after value.
Actual component names are yet to be determined ... what I've included here is just to illustrate the concept.
| Attachment | Size |
|---|---|
| Codereview.png | 179.36 KB |
| Codereview_v2.png | 181.1 KB |
Comments
great proposal
I like this a lot. Its a bit petty, but I am not a big fan of the word "Gates", simply because it suggests an order of things, which I don't think there really should be.
--
zzolo
Agreed ...
I didn't explicitly make the point, but I'm on board with the concept that any of the individual 'gates' could be performed in any order ... but I used the term in the sense that each item were parallel 'gates' required to pass the application.
I considered 'checks', which seems a little too generic, and 'stages', which also suggests an order. 'Hurdles' is somewhat accurate, except for the connotation ;)
After a breif tour through the thesaurus, I think it would probably have to be one of "gate, check, test, step, bar, or block"; where I'd vote for any of the first three.
Responding to to ccardea's
Responding to to ccardea's post (but placing it here to try and keep related discussions within the same thread), his suggestion of 'status' helped me realize that we don't really need any label. I've attached a second version of the mockup, which uses the terms 'Current review status' and 'Components' ... I think it neatly avoids the 'sequential' notion that zzolo referred to.
Issue queue redesign
This is very similar to the planned redesign of issue queues in general here:
http://groups.drupal.org/node/144574
Given the similarity, I think our implementation effort will be best spent pushing for that general issue queue redesign to be flexible enough to fit our needs, rather than trying to do something completely ad hoc.
Timelines?
What is the timeline of the Prairie Initiative?
While I agree whole-heartedly that we should be working to ensure the redesign helps meet our needs, is there room for an interim solution which will help us with the current queue?
Of course, this assumes that the maintainers would accept a submodule for this purpose ... you may have a better idea than I regarding those odds.
Gates alone won't solve the problem
We also need to be able to filter by "gate" on issue queue page. Actually all that would be needed would be a set of custom status (stati?, states?). I like the word status better than gates too. But then you would need to have a sequence of steps for the process.
Agreed ... a filter on the
Agreed ... a filter on the issue page was also part of the concept, but I realize now that I didn't actually mention that anywhere. But as the statuses would be in a seperate database table, this would be slightly more difficult than just an exposed filter on the view ... given that the view doesn't appear to have a uniquely identifiable name, I suspect another page link next to "Advanced Search" would be the only real implementation option.
Using issue status for filtering solves this problem
If we use this issue status codes for tracking applications, that takes care of this objection. The checklist would be a nice addition to the page. The only thing I would suggest would be to include the name of the person who changed the status.