[xslt-conformance] Tracking review status

[David Marston/Cambridge/IBM <david_marston@us.ibm.com>]

I'm trying to understand Carmelo's status codes within the structure of
our review policy (reviews.htm in the Submissions Package). The status
codes currently are:
<statusflag id = "s0" displayname= "non-consensus"/>
<statusflag id = "s1" displayname = "accepted"/>
<statusflag id = "s2" displayname = "rejected"/>
<statusflag id = "s3" displayname = "remanded"/>
<statusflag id = "s4" displayname = "referred"/>
<statusflag id = "s5" displayname = "under-review-need-one-decision"/>
<statusflag id = "s6" displayname = "under-review-need-two-decision"/>
(I fixed the spelling in s0.)

Clearly, a newly-submitted test is s6, because the codes don't cover
assigned-to-reviewer vs. awaiting-assignment.

After one review, the test moves to s5, though it might be helpful to
distinguish those where the first reviewer calls for rejection. Also,
the first reviewer could say that a larger group of Committee members
ought to look at the case.

If two reviews both say OK, then the test moves to s1.

If reviewers disagree, then the test could go to s0. But I think it
also goes to this status if either reviewer thinks that a larger
group needs to look at it.

If both reviewers agree to reject, then the test normally moves to s2,
but it could also go to s3 if some small fix would make the test
acceptable. (Am I correctly recalling what "remanded" means to us?
"Sent back for repair"?)

From s0, a test could go to any of s1-s4. Presumably, s4 means
referred to the W3C. While s1 and s2 are stable terminal states,
s4 is a pending state. Once we hear back from the W3C, the test may
go to any of s1-s3.

I'm leaving out several details that a state-transition or workflow
fanatic would want to address. If anyone on the Committee wants to
revise this scheme, please request an agenda item for Wednesday's
meeting.
.................David Marston