Re: Working Group procedure - change proposal

Merged.

Cheers,


> On 9 Oct 2017, at 3:43 pm, Mark Nottingham <mnot@mnot.net> wrote:
> 
> 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/
> 
> 

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

Received on Friday, 13 October 2017 02:23:46 UTC