Housekeeping: issue labels

[Mark Nottingham]

Everyone,

When we set up our most recent work mode at <https://github.com/httpwg/http-core/blob/master/CONTRIBUTING.md>, 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' CONTRIBUTING.md 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 CONTRIBUTING.md and flag any concerns as they arise.

Cheers,

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

[Mike Bishop]

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 <***@mnot.net>
Sent: Sunday, October 28, 2018 10:59 PM
To: HTTP Working Group <ietf-http-***@w3.org>
Cc: Patrick McManus <***@gmail.com>
Subject: Housekeeping: issue labels



Everyone,



When we set up our most recent work mode at <https://github.com/httpwg/http-core/blob/master/CONTRIBUTING.md>, 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' CONTRIBUTING.md 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 CONTRIBUTING.md and flag any concerns as they arise.



Cheers,

[Martin Thomson]

With multiple drafts and tags for each draft, I have used absence of a
draft tag to indicate that it hasn't been triaged. In that case, not
having a design label is OK. If we have one-draft-per-repo, then design
might still be useful to indicate that it's been triaged.

Post by Mike Bishop
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-----
Sent: Sunday, October 28, 2018 10:59 PM
Subject: Housekeeping: issue labels
Everyone,
When we set up our most recent work mode at <
https://github.com/httpwg/http-core/blob/master/CONTRIBUTING.md>, 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' CONTRIBUTING.md 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 CONTRIBUTING.md and flag any concerns as they arise.
Cheers,
--
Mark Nottingham https://www.mnot.net/