> On 12 Jul 2016, at 18:42, Edward Z. Yang <ezy...@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. 

>    - 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 

    is:open label:"priority: high" label:"bug (ezyang is planning to delete 
this tag)" milestone:"Cabal 1.26"

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- has 12 open issues, should we create 
cabal-install-1.24.1 -milestone and move them there?

- Oleg

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

cabal-devel mailing list

Reply via email to