Changes between Initial Version and Version 1 of IssueTracking


Ignore:
Timestamp:
11/08/09 19:51:01 (13 years ago)
Author:
hartmans-ietf@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • IssueTracking

    v1 v1  
     1
     2= LISP Issue Tracking Policy =
     3
     4We use the tools.ietf.org issue tracker to track open issues
     5with the LISP specifications to make sure that they are addressed.
     6However, discussion will take place on the mailing list.  The issue
     7tracker represents summaries of the issues and their resolution; new
     8content needs to appear on the list.
     9
     10The issue tracker will be managed by document editors, the WG
     11secretary and the WG chairs. These people will be responsible for
     12creating, updating and resolving issues based on the WG discussion.
     13Especially for creating issues, we hope that the document editors will
     14take the initiative.
     15
     16==                           Creating an Issue ==
     17
     18Whenever a WG participant flags a problem they believe needs to be
     19addressed or an enhancement they would like to see made in one of our
     20documents in a message, the document editors should open a new issue
     21and reply to the message including the issue number in the subject.
     22
     23WG participants should try to include only one issue per message when
     24opening a issue.  However when opening issues in the tracker, it may
     25be necessary to split a message into multiple issues.  It may be
     26tricky to figure out where the boundary between issues is.  It's
     27probably reasonable to include several editorial recommendations in an
     28issue.  It may be reasonable to include several text changes to
     29different sections that together effect one consistent technical
     30change as a single issue.  However it is desirable to separate
     31technical issues where the WG may have different opinions.  It is
     32better to err on the side of separating rather than combining issues.
     33
     34==                          Commenting on Issues ==
     35
     36It is important that whenever possible a reply to an issue include the
     37issue number in the subject and only address one issue per message.
     38WG participants are strongly encouraged to wait for an issue to be
     39opened and assigned a number before replying to a message opening an
     40issue.
     41
     42==                            Closing Issues ==
     43
     44If the document editor replies to an issue, and the person opening the
     45issue agrees then the issue can be closed.  There need not be text
     46changes; some times discussion reveals that the text is clear or that
     47the desired change is not a good idea.  If an issue is closed with no
     48text change, it should be closed as resolved/withdrawn.  If an issue
     49is closed with text changes resolving the issue it should be closed as
     50resolved/fixed. If someone objects to the issue being closed within a
     51reasonable time then it will be reopened.
     52
     53If agreement is not reached between the document editor and person
     54opening the issue or if objections are raised by others, then the WG
     55chairs will judge the consensus of the working group.  In this case document editors must wait for the results of the consensus call before  making text changes to address the issue.
     56
     57Whenever an issue is marked fixed, a description of the text changes
     58to address that issue need to be attached to the issue.
     59
     60==                          Content of Issues ==
     61
     62The issue tracker should contain a description of the issue, a summary
     63of the discussion and the resolution of the issue.  If specific text
     64changes are made in response to an issue they need to be included.
     65Quoting messages to the list to provide the description of the issue
     66and the summary of discussion is encouraged.  However it is not
     67important to quote all traffic on the list unless doing so adds
     68clarity.
     69
     70==                           Changes Summaries ==
     71
     72When Document editors post new versions of their drafts, they should
     73briefly describe the changes in the draft and their motivation.  An
     74example might be something like "Changed LISP header (issue 32)".
     75Editorial changes do not need to be explicitly called out.  Not all
     76changes need to be linked back to the issue tracker, although more
     77explanation for the change is needed if an issue is not referenced so     
     78the WG can tell why the change was made and the level of                   
     79discussion/consensus.
     80