Atompub WG Work Plan

[Tim Bray <tbray@xxxxxxxxxxxxxx>]

With thanks to Paul and Sam for hammering IT out, here is our initial 
work plan.  I'm sure we'll modify this with experience.

GOALS:
- First draft revisions by July 2nd, clearly marked "do not implement"
- Drafts with the "do not implement" mark removed published by Halloween

WORK METHOD:
- The WG secretary will schedule issues from the issues list for
  discussion.
- We'll handle a small number of issues in parallel, the number 
depending on
  issue complexity and how good we get at this
- The Chairs' duties will be mostly keeping debate civil and moving 
along, and
  ascertaining when the consensus is good enough.  We may occasionally 
use
  straw polls.

GETTING STARTED:
- As of now, debate is open as to whether the issues marked "Proceed" 
in the
  issues list are in fact sufficiently cooked.  Remember that we're not 
after
  perfection, the reason we have intelligent human editors is so that 
they
  can exercise their intelligence in polishing off rough edges.
  [http://www.intertwingly.net/wiki/pie/AtomPubIssuesList]
- As soon as possible but no later than next Wednesday June 30th, Paul 
and I
  will group the "Proceed" issues into "Proceed" and  "Revisit" based 
on what
  the group says.
- If our editors wanted to get going right now on the apparent 
low-hanging
  fruit in the "Proceed" list and start banging away on the drafts, that
  would be nice.

RULES OF ENGAGEMENT:
- Email to the list that does not contain an Issue ID in the title or 
the
  phrase "Propose new Issue" is apt to be ignored, at least by the 
chairs,
  secretary, and editors.
- New issue proposals without fully worked out text are apt to be 
ignored, at
  least by the chairs, secretary and editors.
- It would be good to mark with [Editorial] in the subject line things 
that
  probably don't constitute a material change.
- Statements of disagreement unaccompanied by specific suggestions for
  alternatives do not necessarily constitute evidence of lack of 
consensus.
  (A reasonable alternative is "drop this whole proposal" optionally
  accompanied by "and replace it with...").
- On any given issue, it is unlikely that, after 2 or 3 days of 
discussion,
  any new arguments will emerge.  Then your workload shifts from 
explaining
  why you're right to figuring out what spec language has a chance of
  gathering consensus and moving forward.
- The chairs will eventually declare that a good-enough rough consensus 
exists
  to mark an issue "Proceed" and turn the issue over to the editors to
  attempt to work the proposed language into the draft.  This will often
  require a bit more editorial creativity than you'd expect.

None of this is set in stone.  Meta-debate about process is OK, but 
let's run with this for a while until we have some experience to base 
it on.  -Tim