[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Tracking system and Requirements Info.
Regarding Carmelo's review.html: We could think of this in workflow terms, where tests move through the statuses... Incoming Under Review (see COMPLICATION below) Deferred Remanded Accepted (a terminal state) Rejected (the other terminal state) The COMPLICATION is that we need to track more than one reviewer looking at a test. But reviewers look at bunches of tests, so maybe we can deal with multiple reviewers in a per-bunch tracking table. If we did that, then "Under Review" might split into "Under Review--need two decisions" and "Under Review--need one decision", kinda like your three tries to move out of Jail in Monopoly. Other bits of information from the proposal can be associated with a stage of the flow. When the test is "Incoming", you can initiate the status and you know 1.Who submitted this test? 6.Who wrote this test? and you also know whether the submitter/writer is actively involved and would thus be willing to modify a remanded test. I think we also need to capture the submitter's Date information from the test catalog, so we can be unambiguous about versions that have been reviewed, especially when we remand a test and get a repaired one. As the test moves into review, then you can track the who/when stuff and each individual reviewer's determination. We may need a "reason" field for each reviewer to accompany their "decision" field. Perhaps "other comments" should be separate from "reason" so that we can also have a place for the more occasional observations. (I suspect that every decision other than "Accepted" probably needs a reason.) .................David Marston
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC