Subject: [nfsv4] Priorities in the issue tracker

From: "Noveck, Dave" <[email-masked]>
Date: Sun, 25 Jun 2006 10:02:52 -0400

I think we should consider how we use priorities in the issue-tracker
and tie them a little bit more to the stages that we expect to go
through in getting to a spec.  In particular, the current distinction
between required and nice-to-have is really at variance with that.
 
Examples of what I mean are issues 53 and 65.  These are things that we
might or might not put in the protocol so we have made the priority
nice-to-have.  The problem is that from the viewpoint of coming to
closure on the set of things that are in the protocol, we have to decide
on whether each of these are in that set and so the priority of that
work has to be considered high or else we will never to closure on the
set of things.  Once we have that discussion, we may close the issue but
having the discussion and making the decision has to be considered
high-priority.
 
Spencer has propose two stages of spec and I've added a stage-0 in
front.  Whatever we decide to do about that issue, I'd like to propose
that we make the priorities follow the spec staging model we adopt.  At
the top of the priority list is things that we need to get done for the
first stage completion (whether that is Spencer's stage 1 or my stage 0)
and that has to include making decisions on any new material for the
spec.  I think we are at the point where we have to consider when we
will decide the spec is closed to new items, even small ones.  I'm not
saying we're there yet, but we are getting close.
 
So my proposal is that we have priorities required[012] for things that
must be addressed by a certain stage (even if being addressed means
deciding we won't do it), nice-to-have and nit for things we really feel
we don't need in a spec and would not hold up any of the earlier stages
of the spec.  All of these latter items would have to fit in the
explanation/clarification class.
 
A final related point is that for items that propose additions to the
protocol that have not been discussed by the working group it, it is
time to get that discussion going, or close the issue.  If there are
things you want to add to the protocol (e.g. ACL extensions discussed
recently), now is the time to create an issue and get the discussion
going so that we can reach consensus on those.  I think it is a
reasonable rule to establish at this point that if you create an issue
for a protocol addition you assign that issue to yourself or find a
willing colleague who will drive the discussion and produce any needed
spec text. 
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4