issue process updates

[Diane Jordan <drj@us.ibm.com>]

I wanted to make everyone aware of a
couple items related to our issue process.  

To help keep us organized as we tackle
complex issues where the solution can be factored into pieces, we've added
the ability to create sub items on our issues list (thanks as always to
Peter).  If you are working on a piece of an existing issue, please
provide a description to him so he can open it as a "dot release".
This will result in a new issue with the existing issue number followed
by ".x" where the x is the number of subissues including this
one.  In proposing subissues, keep in mind that there should be no
overlap with the remainder of the issue or other subissues (otherwise,
its not a discrete piece that can be solved separately).  Also, since
this is being done to better track partial solutions to existing issues,
new subissues will not need to go through the new issue vote.  

At the face to face meeting, it was
suggested that we should "raise the bar" for proposed resolutions
to include more specifics on the changes they would require in the spec.
 It was generally agreed that we should encourage those writing resolutions
to observe this intent and that different options for how this might be
accomplished.  The following list of best practices were discussed.
 Note that they would not all apply to a given resolution, submitters
may choose to use them, or other members can request that they do so.  None
of these are normative - these do not restrict members from making motions
and requesting votes (they may help those motions get passed more easily
though! ;-)  ) 
Best practices for proposals to close
issues as discussed at f2f:  
–        Describe
the effect of a proposal on spec, not exact wording
•        Include
at least specific sections with concept of change
•        Example
changes should be included
–        Request
input from spec editing team  
        This
might involve a request for assistance on a proposal before submitting
it or asking them for input during the discussion 
–        New
issues being opened should contain the proposed solution, not necessarily
text
•        Apply
this to new non-bug issues - any bug that is found should be identified
without constraining the originator to identify the solution
–        Two
stage voting – approve concept then text  (note, this is similar
to what we've been doing in that we approve resolutions without line for
line reviews of the text and approve the final text when its incorporated
in the spec)  
–        Don’t
mark issues closed till in spec
–        Change
voting to yes, no, more work required/send to spec editing team

 If there are questions, we can
discuss via email or on the call next week. 

Regards, Diane
IBM  Emerging Internet Software Standards
drj@us.ibm.com
(919)254-7221 or 8-444-7221, Mobile: 919-624-5123, Fax 845-491-5709