Re: Working Group procedure - change proposal

Just an update on this -- after some discussion, I've modified this to align more closely with the process used in the QUIC Working Group (and which is starting to be used elsewhere).

The editors will close issues when a proposal is incorporated, and then we'll announce changes to the list when a new draft is published. If we determine consensus on an issue after that, we can mark it with `has-consensus` -- although not every issue might be flagged as such, especially if it's not contentious.

The underlying principle here is that consensus is something we don't formally determine on every issue, but instead we work towards generally and confirm in WGLC.

Contentious issues might be flagged as `has-consensus` so that we don't continually revisit them, but generally we don't need to formally declare consensus on an issue-by-issue basis.

As per the document, issues can be reopened if you disagree with the proposal that's in the drafts, and the editors have a responsibility to clearly communicate changes to the WG. 

Please have a look:
  https://github.com/httpwg/http-extensions/pull/362
... and raise any concerns. 

Cheers,


> On 26 Jun 2017, at 9:31 pm, Mark Nottingham <mnot@mnot.net> wrote:
> 
> Hi everyone,
> 
> I've proposed a few changes to CONTRIBUTING.md (i.e., our working process) here:
>  https://github.com/httpwg/http-extensions/pull/362
> 
> I've pasted the changed section below. In a nutshell, it allows editors to close issues with proposals, as long as they're marked with "proposal". 
> 
> This more closely mirrors the process that the QUIC WG uses (which evolved from our process), which has proven more natural than leaving issues open until we declare formal consensus.
> 
> The first paragraph reminds us that the issues list is a mechanism for tracking our discussion, not the sole arbtrar of consensus. 
> 
> Comments?
> 
> 
> """
> ## Resolving Issues
> 
> As in all IETF Working Groups, final consensus of the Working Group is determined during Working
> Group Last Call; consensus established in discussion of issues provides a limited precedent, to
> prevent revisiting topics unnecessarily. Our issues list provides a mechanism for tracking those
> discussions and their outcome.
> 
> Issues will be labeled by the Chairs as either `editorial` or `design`:
> 
> * **Design** issues require discussion and consensus in the Working Group. This discussion can happen both in the issue and on the [Working Group mailing list](https://lists.w3.org/Archives/Public/ietf-http-wg/), as outlined below. 
> 
> * **Editorial** issues can be dealt with by the editor(s) without consensus or notification. Typically, any discussion will take place on the issue itself.
> 
> The `open` design issues in the issues list are those that we are currently or plan to discuss.
> When a design issue is `closed`, it implies that the issue's proposed resolution is reflected in
> the drafts.
> 
> The editors can also propose resolutions to design issues for the group's consideration by
> incorporating them into the draft(s). When they do so, the issue will be closed and flagged with
> the `proposal` label.
> 
> When a new draft is published, the design issues that have been closed since the last draft will be
> highlighted on the mailing list, to aid reviewers. 
> 
> If new information (in the judgement of the Chairs) about a decision comes to light, or there is an
> objection to a proposed resolution flagged with `proposal`, the issue will be reopened by the
> Chairs. If there is no objection, the `proposal` flag will be removed from those issues, to denote
> that their resolution has been accepted.
> """
> 
> 
> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Monday, 9 October 2017 22:43:58 UTC