[DNA-BOF] Quality Plan, Review Process, Issue Tracker proposals

[Gregory Daley <Greg.Daley@eng.monash.edu.au>]

Hi all, 

I'll try to get into reading some of the mail from the
list soon, but Pekka and I have been working in the background
to address some of the issues raised by the IESG.

These issues have to be provided before chartering:
"...
 - Identified editors for each of the work item.
 - Some reason to believe that we will get sufficient
   review of these work items.
 - Plans for issues tracking and any other quality
   measures.
..."

I'll describe our progres towards these goals
below.

1. Editors

   We've got acceptances from editors for each of the documents.
   These will be announced shortly.

   We still need to initiate document development in a couple of
   cases.  Pekka and I will discuss with the editors an appropriate
   course of action in each case.

2. Reviewers 

   We're still building reviewer lists, and are now concentrating
   on specialist reviewers from other areas.  We really appreciate
   the interest shown already.  
   

3. Review process

   The proposed review process is articulated in a quality
   plan,  and a less formal, but more detailed review plan.
   These are included later within this e-mail.

4. Issue Tracking and Quality Measures

   At this stage, we propose all WG documents will require
   an issue list on the WWW, and that diffs between released
   versions of drafts be available form these sites.
   Further details about Issue tracking, including a prototype
   are included below.

   Additonally, the following Quality Plan, which describes
   document review and development policy has been developed.
   We propose that this plan is adopted for DNA, going forward.

DNA Quality Plan Proposal:
--------------------------
* All drafts will need to undergo review prior to
  acceptance as WG work items, which includes
  demonstration that the drafts provide a simple
  solution to a restricted and well-understood problem
  and that the solutions do not interact negatively
  with existing IPv6 Configuration and Neighbour
  Discovery mechanisms such as SEND.  The chairs
  will ask for specific WG members to perform the
  review, in addition to reviewing the draft themselves.

* This WG will not be chartered before sufficient resources
  can be demonstrated to be available. This includes
  recruitment of a core of editors and reviewers with
  significant IETF experience and demonstrated time commitment.

* Reviewers outside the WG (including SIRs, where availability
  permits) will be used to ensure quality of the drafts prior
  to sending them to the IESG.

* An effort will be made to determine interest from vendors and
  service providers about the inclusion of the proposed features
  in their plans.  The chairs will poll the WG members at the
  meetings to determine the level of interest.

* The WG will utilize an issue tracking system and automatically
  produce difference files between draft revisions.

--------------------------------


In order to provide a rough overview of how review will
be approached within DNA, an approximate review plan is
provided below.

This document is not strictly binding in order of steps,
or in completeness.  Essentially, additional steps or
loops of steps may be required for particular documents
on a needs basis.


Proposed DNA Review process (V. Rough):
---------------------------------------

1 Review by chairs and selected participants before
  adoption as a WG document.

2 Assess fitness of the document for security review
  based on previous review issues and stability

3 Seek Security Review (from experienced SEC reviewer).

4 Incorporate review feedback/Re-assess security

5 Cross Area and external review.

6 Incorporate reviewrs' feedback

7 WG Last Call

...
----------------------------

Issue Tracker Prototype.
------------------------

A prototype issue tracker, with an example
issue list is provided at the URL:

http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/

This system has revision control, basic
authentication (clear text?!) and access control
mechanisms, which have been set up to allow
editor write-access, and world read access.

The system is based on TWiki, with a few templates
added.  Markup is a simplified system which 
allows either HTML or a fairly simple but restricted
markup for tables, headings and hyperlinks.

I'll be discussing with editors whether they wish to
use the system, and trying to get some feedback
(from viewers' and editors' point of view), so please
tell me if there's something I've overlooked.

I hope this volume of information hasn't overwhelmed you.
If you're responding, please consider starting a new
thread.

Greg Daley