[jsdl-wg] Tracker status value proposal - take 2

[Michel Drescher]

Andreas,

thanks for this review. I like this take two.

Cheers,
Michel

On 19 Apr 2005, at 13:57, Andreas Savva wrote:

> Ok, here's a slightly revised proposal for the status values. Again 
> note that this is just for the *specification* tracker and not for the 
> general 'Agenda/Topic' tracker.
>
> At the moment the tracker artifact status values are the gridforge 
> default:
> 	open, pending, closed.
>
> These cannot be changed but new values can be defined. I propose to
> augment them with the following values:
> 	resolved, fixed
>
> "open", "pending", "resolved" and "fixed" would be of status class Open
> "closed" of status class Closed
>
> Status value definitions will be clearly documented on the tracker 
> summary page.
>
> A typical workflow would be  open->pending->resolved->fixed->closed
>
> (Michel's email gives a more detailed proposal for these transitions.)
>
> The meaning of these values (for the typical path) would be as follows:
>
> Open: the issue has been proposed by a member but not yet
> 	accepted by the WG.
>
> Pending: the issue has been accepted and is still pending
> 	resolution by the WG. (Includes 'waiting response from 	author' 
> mentioned by Donal.)
>
> Resolved: The WG has decided and accepted a resolution, but the
> 	actions are still pending
>
> Fixed: The editor has completed the proposed actions, but the
> 	actions are awaiting verification. Both the schema and spec
> 	may have to be revised in order to reach this state.
>
> Closed: The issue has been resolved and is reflected in the
> 	 work products of the WG. The completion of the changes
> 	must be reported by the primary editor and verified by
> 	the secondary editor (or other WG member). 	
> Issues that have been deferred or rejected also get closed with an 
> appropriate comment. Issues that have been deferred are moved to the 
> post-v1 tracker.
>
> (After checking the tracker settings again, "deferred" or "rejected" 
> should probably be 'resolution' values rather than status values. The 
> resolution field exists but is not enabled at the moment. I propose we 
> first try out the new status values. We can come back and enable the 
> 'resolution' field if we decide we really need it.)
>
> Andreas