Re: I reorged labels on Cabal's GitHub

[John Alfred Nathanael Chee]

On Tue, Jul 12, 2016 at 1:48 PM, Edward Z. Yang  wrote:

> > >- 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...).
>
> OK, I am convinced we should drop it.
>
> Let's do this:
>
> - To page someone, just write CC @blah in the message
> - We should add an issue template that requests you
>   CC someone and explains who you might want to CC


If you don't already know about it, this bot:
https://github.com/facebook/mention-bot is worth investigating in addition
to the work you've mentioned.

-- 
Love in Jesus Christ, John Alfred Nathanael Chee
http://www.biblegateway.com/
http://web.cecs.pdx.edu/~chee/
___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Re: I reorged labels on Cabal's GitHub

[Edward Z. Yang]

Thanks for the note. I went ahead and enabled it. Let's see if it's
useful!

Excerpts from John Alfred Nathanael Chee's message of 2016-07-12 14:18:03 -0700:
> On Tue, Jul 12, 2016 at 1:48 PM, Edward Z. Yang  wrote:
> 
> > > >- 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...).
> >
> > OK, I am convinced we should drop it.
> >
> > Let's do this:
> >
> > - To page someone, just write CC @blah in the message
> > - We should add an issue template that requests you
> >   CC someone and explains who you might want to CC
> 
> 
> If you don't already know about it, this bot:
> https://github.com/facebook/mention-bot is worth investigating in addition
> to the work you've mentioned.
> 
___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Re: I reorged labels on Cabal's GitHub

[Oleg Grenrus]

Great, it looks awesome.

Issue template is great idea as well. (for ones who aren’t familiar: 
https://github.com/blog/2111-issue-and-pull-request-templates 
)
(I’m +1 for having GitHub stuff under .github/ directory)

The issue template could ask for
- Cabal/cabal-install/ghc versions
- ask to run cabal-install with -v2 flag and add that to the issue?

with quick glance it doesn’t apply to many issues, but when it does, it would 
be helpful.


- Oleg

> On 12 Jul 2016, at 23:48, Edward Z. Yang  wrote:
> 
> Excerpts from Oleg Grenrus's message of 2016-07-12 12:45:05 -0700:
>> 
>>> On 12 Jul 2016, at 18:42, Edward Z. Yang  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 
>> 
> 
> Haha! Learned something today.
> 
>>>   - 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...).
> 
> OK, I am convinced we should drop it.
> 
> Let's do this:
> 
>- To page someone, just write CC @blah in the message
>- We should add an issue template that requests you
>  CC someone and explains who you might want to CC
> 
 - 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 
 
>>> 
>>> 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.
> 
> OK, fine. I've reorged accordingly.
> 
>>> 
>>> 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.
> 
> Added.
> 
 - 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).
> 
> Dropped it.
> 
>> 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?)
> 
> Regression is in here because we used to have a regression tag. I'll
> reclassify them.
> 
>> E.g.
>>

Re: I reorged labels on Cabal's GitHub

[Edward Z. Yang]

Excerpts from Oleg Grenrus's message of 2016-07-12 12:45:05 -0700:
> 
> > On 12 Jul 2016, at 18:42, Edward Z. Yang  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 
> 

Haha! Learned something today.

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

OK, I am convinced we should drop it.

Let's do this:

- To page someone, just write CC @blah in the message
- We should add an issue template that requests you
  CC someone and explains who you might want to CC

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

OK, fine. I've reorged accordingly.

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

Added.

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

Dropped it.

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

Regression is in here because we used to have a regression tag. I'll
reclassify them.

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

Re: I reorged labels on Cabal's GitHub

[Edward Z. Yang]

For the PR, we can put in a checklist:

[ ] If you made a BC-breaking change, did you add an entry to the
changelog?
[ ] If you added a new user-level feature, did you add an entry
to the changelog?  Did you write docs for it?
[ ] If you added a new, public API function, did you add a
@since annotation to it?
[ ] Did you Haddock all of your new functions?
[ ] Did you add a test? (If not why was it hard to write the test?
Maybe open a bug for it.)

Any did I forget?

Excerpts from Oleg Grenrus's message of 2016-07-12 14:03:01 -0700:
> Great, it looks awesome.
> 
> Issue template is great idea as well. (for ones who aren’t familiar: 
> https://github.com/blog/2111-issue-and-pull-request-templates 
> )
> (I’m +1 for having GitHub stuff under .github/ directory)
> 
> The issue template could ask for
> - Cabal/cabal-install/ghc versions
> - ask to run cabal-install with -v2 flag and add that to the issue?
> 
> with quick glance it doesn’t apply to many issues, but when it does, it would 
> be helpful.
> 
> 
> - Oleg
> 
> > On 12 Jul 2016, at 23:48, Edward Z. Yang  wrote:
> > 
> > Excerpts from Oleg Grenrus's message of 2016-07-12 12:45:05 -0700:
> >> 
> >>> On 12 Jul 2016, at 18:42, Edward Z. Yang  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
> >>  
> >> 
> > 
> > Haha! Learned something today.
> > 
> >>>   - 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...).
> > 
> > OK, I am convinced we should drop it.
> > 
> > Let's do this:
> > 
> >- To page someone, just write CC @blah in the message
> >- We should add an issue template that requests you
> >  CC someone and explains who you might want to CC
> > 
>  - 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 
>  
> >>> 
> >>> 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.
> > 
> > OK, fine. I've reorged accordingly.
> > 
> >>> 
> >>> 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.
> > 
> > Added.
> > 
>  - 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 

Re: I reorged labels on Cabal's GitHub

[Mikhail Glushenkov]

Hi,

On 12 July 2016 at 23:58, Edward Z. Yang  wrote:
> For the PR, we can put in a checklist:
>
> [ ] If you made a BC-breaking change, did you add an entry to the
> changelog?
> [ ] If you added a new user-level feature, did you add an entry
> to the changelog?  Did you write docs for it?
> [ ] If you added a new, public API function, did you add a
> @since annotation to it?
> [ ] Did you Haddock all of your new functions?
> [ ] Did you add a test? (If not why was it hard to write the test?
> Maybe open a bug for it.)
>
> Any did I forget?

LGTM. One other thing is that the "documentation" label should perhaps
be merged with "component:user-guide".
___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Re: I reorged labels on Cabal's GitHub

[Mikhail Glushenkov]

Hi,

On 12 July 2016 at 13:03, Oleg Grenrus  wrote:
> 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)?

"Assignee" usually means that the implementation is in progress and
the assigned persons are working on it (though we haven't always used
it for this purpose).

> - how priority labels interact with milestones?

In the obvious way, I guess: tickets targeted at a specific milestone
are ordered by priority.

> Should we add “pr welcome” or “awaiting pr”

+1 from me.
___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Re: I reorged labels on Cabal's GitHub

[Oleg Grenrus]

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

- how priority labels interact with milestones?
- 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`)

- Oleg

> On 11 Jul 2016, at 08:09, Mikhail Glushenkov  > wrote:
> 
> Hi,
> 
> On 11 July 2016 at 06:37, Edward Z. Yang  > wrote:
>> If you hate it I can change it back but give it a try for now.
>> If the "component" prefix in "component: solver" is too long we could go for
>> something like "C-solver" but I think that is less transparent.
> 
> Thanks, looks much better than the previous version.
> 
> Re: the "specification" tag, I think it's supposed to mark proposed
> changes to the .cabal file format and GHC/Cabal interaction (i.e. the
> Cabal spec).
> ___
> cabal-devel mailing list
> cabal-devel@haskell.org 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Re: I reorged labels on Cabal's GitHub

[Edward Z. Yang]

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
- I can put more metadata in the tag name than assignable
  (to help people decide who to page)

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 
> 

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!

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

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

Edward
___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Re: I reorged labels on Cabal's GitHub

[Oleg Grenrus]

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


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cabal-devel mailing list
cabal-devel@haskell.org