What are the objections to this? To me, it's a no-brainer. The sorting capability is built into the system, it requires only a small change in the workflow to implement, and it gives you a nice listing of projects. The only alternative that I know of that's been discussed is tags. I think tags will give you a tag page instead of the issues listing. I don't know for sure because I don't know what tags people have been using, and I'm not sure where to find them.
If we don't have a way to find which applications have completed a stage, I think a lot of them are going to fall through the cracks, so if you don't like this proposal, please come up with something else.
My first objection would be that is assumes there is more than one person completing the review. While I think multiple people "should" be handling reviews, this may not be the case and screening checks are relatively quick and simple to do - and therefore a "technical reviewer" could choose to do this.
I personally prefer a checklist based approach that would say what steps have been completed/yet to be done. As simply having 'another' filtration method doesn't actually do anything to get a review completed. I could see tags being good for this, but also seems overkill when there are so many new variants of submission that could be proposed.
People want to have a flexible process which would support the splitting up of reviews ... this does not infer that all reviews MUST be split up. Using the active status is one means of tracking review status, but there's nothing wrong with preferring an alternative which accomplishes the same goal.
There's nothing inflexible about using 'active' status. Nothing says that you can't complete the entire process. Take a close look at http://drupal.org/node/894256. It encourages reviewers to stay with an application from start to finish, and the workflow is built around that. I actually think that is a wise approach, because we have seen occurrences where an application sits for several weeks, somebody does a partial review, and then it sits for several more weeks waiting for somebody to complete the review. This happens because there is no way to quickly differentiate between a new application and one that somebody has done a partial review on and moved on to something else. If a single reviewer stays with the application, its not a problem, but if he doesn't, then it is a problem.
Most people seem to support the idea of splitting up the reviews between different people in order to help get more people involved in the process. If we do that, then we really do need a way to facilitate it. If you think about it, what we are doing is changing the workflow...from a single reviewer doing the whole process to potentially multiple reviewers doing different parts of the process. This does require a change in the way the process is managed.
Using 'status' to do this is really the only viable solution. It could conceivably be done with tags but they are too cumbersome to work with. I support the checklist idea, but it really doesn't give us the capability we need, because you have to open up the application to see what the status is. You cannot change the process and not change the management of the process. If we change the process, then we have to do this. With the tools we have, this is the best way.
Your responses continue to try and paint this as "the only way" to identify that a project application has been screened. Please try to keep an open mind, rather than locking in on a single option ... it's too easy to put up the blinders and miss other obvious solutions.
For example ... We could simply ask people to changethe project name to "[Screened] Project Name" when they've completed a screening, and accomplish the same result. Thoughts?
My objection is based on the impact this would have on existing reviews already in the queue, and the opinion that there are other potential alternatives which, while possibly more effort in the up-front implementation, would be more intuitive (for both reviewers and applicants). Applicants have been trained to open issues as 'active' in every other Drupal.org queue, and have been trained to set things to 'needs review' any time they fix an identified issue in this queue ... I don't feel that we'll see enough consistency in how users set these fields in order to use either of them for tracking review progress with 95% accuracy.
The checklist approach lines up nicely with the ongoing 'Prairie' initiative, which has taken on accountability for a complete redesign of the issue queues; and has included the checklist concept (though they call them 'gates') as an integral part of the future vision for issue queues. As I see this as the probable 'end goal' for the issue queue, and considering the changes to the applicant workflow that this will drive in the future; I hesitate to introduce any interim changes to that same workflow (from the applicant perspective) ... my preference is to 'fix once and fix right' rather than 'fix often'.
It's not really an either/or thing. I'm not against the checklist, as a matter of fact one of my first posts in this group suggested a checklist of some sort. But you can't filter with the checklist, and we need a way to filter. Also that Prairie Initiative thing is a mess, and its likely to take a year or two to get anything done.
As for the impact on existing applications, that's really a transition issue. If there really is a problem (which I'm not sure there really is), it will resolve itself of its own accord after a few weeks, and I'm sure we could find a way to manage the transition to minimize any potential impact.
You say that a checklist is not really an alternative, and then you say it's not an either/or thing. That's quite the mixed message.
Your poll question doesn't state 'filtering' as a requirement, and you explicitly asked for alternatives - if you're going to solicit input, I'd suggest you resist the urge to go finding flaws in each alternative; and instead focus on identifying how they could be enhanced.
Probably my fault, trying to be clever with the title. What I mean is that 'active' status and checklist are not alternative solutions. It's not one or the other. They actually would work well together. Using 'active' status is all about filtering. There's no other reason to use it. I thought that was understood.
I think that I will back off my original suggestion that the status should remain active until all issues related to the screening process are resolved. The status would be active only until the screener completes his review, then it would be changed to either needs work or needs review. That is really a very small change to the present workflow and should give us what we need. As far as I'm concerned, the only thing that remains to be done is to figure out how to manage the transition, and then change the documentation.
Comments
Objections and Alternatives Please
What are the objections to this? To me, it's a no-brainer. The sorting capability is built into the system, it requires only a small change in the workflow to implement, and it gives you a nice listing of projects. The only alternative that I know of that's been discussed is tags. I think tags will give you a tag page instead of the issues listing. I don't know for sure because I don't know what tags people have been using, and I'm not sure where to find them.
If we don't have a way to find which applications have completed a stage, I think a lot of them are going to fall through the cracks, so if you don't like this proposal, please come up with something else.
My first objection would be
My first objection would be that is assumes there is more than one person completing the review. While I think multiple people "should" be handling reviews, this may not be the case and screening checks are relatively quick and simple to do - and therefore a "technical reviewer" could choose to do this.
I personally prefer a checklist based approach that would say what steps have been completed/yet to be done. As simply having 'another' filtration method doesn't actually do anything to get a review completed. I could see tags being good for this, but also seems overkill when there are so many new variants of submission that could be proposed.
Dreamleaf Media
You can't have itboth ways
People apparently want to split up the reviews, so we need to be able to manage that scenario.
Not black and white
People want to have a flexible process which would support the splitting up of reviews ... this does not infer that all reviews MUST be split up. Using the active status is one means of tracking review status, but there's nothing wrong with preferring an alternative which accomplishes the same goal.
Not black and white
There's nothing inflexible about using 'active' status. Nothing says that you can't complete the entire process. Take a close look at http://drupal.org/node/894256. It encourages reviewers to stay with an application from start to finish, and the workflow is built around that. I actually think that is a wise approach, because we have seen occurrences where an application sits for several weeks, somebody does a partial review, and then it sits for several more weeks waiting for somebody to complete the review. This happens because there is no way to quickly differentiate between a new application and one that somebody has done a partial review on and moved on to something else. If a single reviewer stays with the application, its not a problem, but if he doesn't, then it is a problem.
Most people seem to support the idea of splitting up the reviews between different people in order to help get more people involved in the process. If we do that, then we really do need a way to facilitate it. If you think about it, what we are doing is changing the workflow...from a single reviewer doing the whole process to potentially multiple reviewers doing different parts of the process. This does require a change in the way the process is managed.
Using 'status' to do this is really the only viable solution. It could conceivably be done with tags but they are too cumbersome to work with. I support the checklist idea, but it really doesn't give us the capability we need, because you have to open up the application to see what the status is. You cannot change the process and not change the management of the process. If we change the process, then we have to do this. With the tools we have, this is the best way.
Never said it wasn't flexible ...
"You can't have it both ways" != "flexible"
"The only viable solution" != "flexible"
Your responses continue to try and paint this as "the only way" to identify that a project application has been screened. Please try to keep an open mind, rather than locking in on a single option ... it's too easy to put up the blinders and miss other obvious solutions.
For example ... We could simply ask people to changethe project name to "[Screened] Project Name" when they've completed a screening, and accomplish the same result. Thoughts?
Alternatives
My objection is based on the impact this would have on existing reviews already in the queue, and the opinion that there are other potential alternatives which, while possibly more effort in the up-front implementation, would be more intuitive (for both reviewers and applicants). Applicants have been trained to open issues as 'active' in every other Drupal.org queue, and have been trained to set things to 'needs review' any time they fix an identified issue in this queue ... I don't feel that we'll see enough consistency in how users set these fields in order to use either of them for tracking review progress with 95% accuracy.
The checklist approach lines up nicely with the ongoing 'Prairie' initiative, which has taken on accountability for a complete redesign of the issue queues; and has included the checklist concept (though they call them 'gates') as an integral part of the future vision for issue queues. As I see this as the probable 'end goal' for the issue queue, and considering the changes to the applicant workflow that this will drive in the future; I hesitate to introduce any interim changes to that same workflow (from the applicant perspective) ... my preference is to 'fix once and fix right' rather than 'fix often'.
Checklist is not really an alternative
It's not really an either/or thing. I'm not against the checklist, as a matter of fact one of my first posts in this group suggested a checklist of some sort. But you can't filter with the checklist, and we need a way to filter. Also that Prairie Initiative thing is a mess, and its likely to take a year or two to get anything done.
As for the impact on existing applications, that's really a transition issue. If there really is a problem (which I'm not sure there really is), it will resolve itself of its own accord after a few weeks, and I'm sure we could find a way to manage the transition to minimize any potential impact.
I'm confused.
You say that a checklist is not really an alternative, and then you say it's not an either/or thing. That's quite the mixed message.
Your poll question doesn't state 'filtering' as a requirement, and you explicitly asked for alternatives - if you're going to solicit input, I'd suggest you resist the urge to go finding flaws in each alternative; and instead focus on identifying how they could be enhanced.
Sorry for the confusion
Probably my fault, trying to be clever with the title. What I mean is that 'active' status and checklist are not alternative solutions. It's not one or the other. They actually would work well together. Using 'active' status is all about filtering. There's no other reason to use it. I thought that was understood.
Making this more palatable
I think that I will back off my original suggestion that the status should remain active until all issues related to the screening process are resolved. The status would be active only until the screener completes his review, then it would be changed to either needs work or needs review. That is really a very small change to the present workflow and should give us what we need. As far as I'm concerned, the only thing that remains to be done is to figure out how to manage the transition, and then change the documentation.