Re: Housekeeping: issue labels

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.

On Thu, Nov 1, 2018 at 2:59 PM Mike Bishop <mbishop@evequefou.be> wrote:

> 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@mnot.net>
> Sent: Sunday, October 28, 2018 10:59 PM
> To: HTTP Working Group <ietf-http-wg@w3.org>
> Cc: Patrick McManus <patrick.ducksong@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,
>
>
>
> --
>
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
>