Process experiements (was Adjustments to our work mode - please read)

[Ted Hardie <[e-mail]>]

I'd like to remind folks involved in this discussion that the IETF actually
already has a documented process for how to run process experiments, set
out in RFC 3933.  I think the difference of opinion here is partly on
whether or not the changes being proposed here do or do not rise to the
level of "process experiment".  Reading through Mark's email again, I can
actually see it either way, depending on what is meant here:

"To that end, we're going to try allowing discussion and resolution of
issues in the issue tracker itself, rather than requiring discussion there
to be moved here -- thereby allowing people to participate without
subscribing to the mailing list, if they don't want to."

If the model here is that discussion in the issue tracker is like
discussion in a meeting, useful for moving things forward but always
subsidiary to the decision of the working group embodied in the mailing
list, then I agree that this is a modest enough experiment that it may not
require the whole IETF last call in advance required by RFC 3933.  In this
case the actual consensus calls might be made as decisions by working group
review of checkpoints of the draft, for example.

If, on the other hand, the intent is that the working group's consensus is
derived from looking at both the discussion on the issue and the discussion
in the mailing list, I agree that a document on approximate mechanics would
be useful.  It would be particularly useful to do so in advance of the
first decision reached in that manner, if that is the intent.  Mark's email
is a good start, but there are some points which may not be clear to all
parties (whether issue re-opening is automatic, for example, and the
determination that no new substantive changes are present done after the
re-open, or whether there is a gate to re-opening an issue and what the
shape of that gate is, if so).

As a data point on other users of github in the IETF, the RTCWEB working
group uses the issue tracker in our github repo extensively, and there is
often discussion there.  Each issue resolution, though, is brought to the
working group (in meeting or mailing list) with a specific proposal, and
the chairs judge the consensus on the proposed resolution in the usual IETF
way from that.  That means that we do not allow issue resolution, other
than on purely editorial changes, from the tracker alone.  As a chair, I
will be very interested to watch the results of this experiment, and in
particular its impact on speed.  I think others would also benefit from a
thorough description of the experiment and its results, whenever that is
produced.

regards,

Ted