On 12 Jul 2016, at 18:42, Edward Z. Yang <ezyang@mit.edu> wrote:

Excerpts from Oleg Grenrus's message of 2016-07-12 04:03:43 -0700:
Looks good indeed!

I have few questions:
- what is purpose of `paging:*` labels, to help people see issues they are interested in? How it’s different from assignees (which can be multiple)?

Beyond what Mikhail stated:

   - Multiple people can be paged, only one assigned
Yes you can. https://github.com/blog/2178-multiple-assignees-on-issues-and-pull-requests


   - I can put more metadata in the tag name than assignable
     (to help people decide who to page)
Ah, page as in ping. That meaning I always find weird (and don’t remember).

> summon (someone) over a public address system, so as to pass on a message

IMHO multiple assignment would work better as it actually sends notification (if one choose to receive such).

Yet, you’re right, deciding whom to page/assign is often non-obvious. Not sure if few-word description if any helpful. (e.g. whom to contact on hackage-security problems, I’m actually unsure whether it’s edsko or dcoutts, or on something else...).


But it's an experiment. If it's not useful we can delete the tags.

- why “bug” has “ezyang planning to delete this tag”. I’d prefer to have “type: bug” and other “type:*” labels as:  “type: discuss”, “type: enhancement”, “type: question”, and maybe more as e.g. stack has https://github.com/commercialhaskell/stack/labels <https://github.com/commercialhaskell/stack/labels>

OK, the tag served it's purpose! I planned to delete it because there
are lots of bugs in the issues tracker and no one has been methodically
tagging them bug or not, so it seemed that the tag was just not that
helpful.  Just look at Stack's issues list: https://github.com/commercialhaskell/stack/issues
who is tagging things as bugs!

If we go for type:* tags, I’ll help with triaging all issues with type:* tag.


discuss/enhancement/question are useful and I support tags for them.
Presently we have "priority: enhancement" but we can rename that as
needed.

I’d like priorities to have a total-order. high > low is obvious, but what about enhancement and user-question? I’d change latter two into type:*, and maybe later introduce third priority level if we feel we need one.


- how priority labels interact with milestones?

Agreed with Mikhail; priority within milestone.

- Should we add “pr welcome” or “awaiting pr” for issues which are discussed, but nobody have interest or time implementing right away (will help new contributors especially when combined with `meta: easy`)

Sure! I wonder, however; for tickets that are tagged this way, I feel
the onus is on us to write a clear spec at the top of the bug for what
is desired (even better: link to a commit with a test!)  Will help
contributors a lot.

Yes, we should help as much as possible. I’d tag only “clear” issues, and add a comment that I can help with it, if there are some questions (or/and assign it to myself).

Also I forgot to ask about "attention: please-merge”. What’s it purpose, to tag PRs that author thinks are amerceable? IMHO the comment is enough, and also would work for external-contributors, who **cannot** tag issues/prs. (This is the reason why I got push-rights in the first place, I’m still quite uncomfortable pushing changes myself).

And what’s the idea behind “attention: regression”? How it’s different from a `type: bug` (its special case of a bug, but does it matter that much. Regressions could be critical or not, so priority tag, with type:bug would be enough?)

E.g.
    is:open label:"priority: high" label:"bug (ezyang is planning to delete this tag)" milestone:"Cabal 1.26" 
filter
 https://github.com/haskell/cabal/issues?utf8=%E2%9C%93&q=is%3Aopen%20label%3A%22priority%3A%20high%22%20label%3A%22bug%20(ezyang%20is%20planning%20to%20delete%20this%20tag)%22%20milestone%3A%22Cabal%201.26%22%20

shows not that many.

OTOH there are 210 open issues (is:open is:issue no:milestone) without any milestone. Should we put them all into _|_ - milestone, and then promote to version milestones, when the discussion advanced enough we know when we want to release them (the soonest, or the latest?). As Cabal-1.26 165 open issues indicates, it’s more like “the soonest”, at least at this point. 

cabal-install-1.24.0.1 has 12 open issues, should we create cabal-install-1.24.1 -milestone and move them there?

- Oleg