RE: Housekeeping: issue labels

This is probably partly aimed at me, since I habitually tag issues and PRs as "editorial" or "design," and I noticed earlier this week that you'd un-designed some of my issues. 😊  This explains why.

Since creators of issues often don't have permission to tag, I usually assume that blank is implicit "no one with tag permissions has classified this yet," and on the QUIC repo will periodically sweep blank issues and tag them appropriately.  Having two possible meanings of blank is slightly confusing, but they are two different WGs and are free to operate differently.

-----Original Message-----
From: Mark Nottingham <>
Sent: Sunday, October 28, 2018 10:59 PM
To: HTTP Working Group <>
Cc: Patrick McManus <>
Subject: Housekeeping: issue labels


When we set up our most recent work mode at <>, it was heavily influenced by the just-concluded work on HTTP/2.

In particular, we had been in a habit of using the `design` label to explicitly denote issues requiring Working Group consensus, and `editorial` for those that did not. However, in practice we've stopped using design, both on the extensions and the core repo.

So, to simplify things and reflect how we actually work, I've adjusted both repos' to reflect this; now, any issue that isn't labeled as `editorial` is implicitly a design issue.

Likewise, we'd previously documented a fairly onerous process for denoting which issues achieved working group consensus, using the `has-consensus` label. In practice, we judge consensus on a document continuously during its lifetime, especially towards the end, and haven't been using that label. So, I've also adjusted the documentation for `has-consensus`; now, it only reflects when we've done an explicit consensus call (e.g., for a contentious issue), to remind us of that.

Please have a read over and flag any concerns as they arise.



Mark Nottingham

Received on Thursday, 1 November 2018 03:55:48 UTC