<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Great, it looks awesome.<div class=""><br class=""></div><div class="">Issue template is great idea as well. (for ones who aren’t familiar: <a href="https://github.com/blog/2111-issue-and-pull-request-templates" class="">https://github.com/blog/2111-issue-and-pull-request-templates</a>)</div><div class="">(I’m +1 for having GitHub stuff under .github/ directory)</div><div class=""><br class=""></div><div class="">The issue template could ask for</div><div class="">- Cabal/cabal-install/ghc versions</div><div class="">- ask to run cabal-install with -v2 flag and add that to the issue?</div><div class=""><br class=""></div><div class="">with quick glance it doesn’t apply to many issues, but when it does, it would be helpful.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">- Oleg</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 12 Jul 2016, at 23:48, Edward Z. Yang <<a href="mailto:ezyang@mit.edu" class="">ezyang@mit.edu</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">Excerpts from Oleg Grenrus's message of 2016-07-12 12:45:05 -0700:<br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">On 12 Jul 2016, at 18:42, Edward Z. Yang <<a href="mailto:ezyang@mit.edu" class="">ezyang@mit.edu</a>> wrote:<br class=""><br class="">Excerpts from Oleg Grenrus's message of 2016-07-12 04:03:43 -0700:<br class=""><blockquote type="cite" class="">Looks good indeed!<br class=""><br class="">I have few questions:<br class="">- 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)?<br class=""></blockquote><br class="">Beyond what Mikhail stated:<br class=""><br class=""> - Multiple people can be paged, only one assigned<br class=""></blockquote>Yes you can. <a href="https://github.com/blog/2178-multiple-assignees-on-issues-and-pull-requests" class="">https://github.com/blog/2178-multiple-assignees-on-issues-and-pull-requests</a> <<a href="https://github.com/blog/2178-multiple-assignees-on-issues-and-pull-requests" class="">https://github.com/blog/2178-multiple-assignees-on-issues-and-pull-requests</a>><br class=""></blockquote><br class="">Haha! Learned something today.<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""> - I can put more metadata in the tag name than assignable<br class=""> (to help people decide who to page)<br class=""></blockquote>Ah, page as in ping. That meaning I always find weird (and don’t remember).<br class=""><br class=""><blockquote type="cite" class="">summon (someone) over a public address system, so as to pass on a message<br class=""></blockquote><br class="">IMHO multiple assignment would work better as it actually sends notification (if one choose to receive such).<br class=""><br class="">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...).<br class=""></blockquote><br class="">OK, I am convinced we should drop it.<br class=""><br class="">Let's do this:<br class=""><br class=""> - To page someone, just write CC @blah in the message<br class=""> - We should add an issue template that requests you<br class=""> CC someone and explains who you might want to CC<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">- 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 <a href="https://github.com/commercialhaskell/stack/labels" class="">https://github.com/commercialhaskell/stack/labels</a> <<a href="https://github.com/commercialhaskell/stack/labels" class="">https://github.com/commercialhaskell/stack/labels</a>><br class=""></blockquote><br class="">OK, the tag served it's purpose! I planned to delete it because there<br class="">are lots of bugs in the issues tracker and no one has been methodically<br class="">tagging them bug or not, so it seemed that the tag was just not that<br class="">helpful. Just look at Stack's issues list: <a href="https://github.com/commercialhaskell/stack/issues" class="">https://github.com/commercialhaskell/stack/issues</a><br class="">who is tagging things as bugs!<br class=""></blockquote><br class="">If we go for type:* tags, I’ll help with triaging all issues with type:* tag.<br class=""></blockquote><br class="">OK, fine. I've reorged accordingly.<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">discuss/enhancement/question are useful and I support tags for them.<br class="">Presently we have "priority: enhancement" but we can rename that as<br class="">needed.<br class=""></blockquote><br class="">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.<br class=""></blockquote><br class="">Added.<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">- how priority labels interact with milestones?<br class=""></blockquote><br class="">Agreed with Mikhail; priority within milestone.<br class=""><br class=""><blockquote type="cite" class="">- 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`)<br class=""></blockquote><br class="">Sure! I wonder, however; for tickets that are tagged this way, I feel<br class="">the onus is on us to write a clear spec at the top of the bug for what<br class="">is desired (even better: link to a commit with a test!) Will help<br class="">contributors a lot.<br class=""></blockquote><br class="">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).<br class=""><br class="">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).<br class=""></blockquote><br class="">Dropped it.<br class=""><br class=""><blockquote type="cite" class="">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?)<br class=""></blockquote><br class="">Regression is in here because we used to have a regression tag. I'll<br class="">reclassify them.<br class=""><br class=""><blockquote type="cite" class="">E.g.<br class=""> is:open label:"priority: high" label:"bug (ezyang is planning to delete this tag)" milestone:"Cabal 1.26"<br class="">filter<br class=""> <a href="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" class="">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</a> <<a href="https://github.com/haskell/cabal/issues?utf8=%E2%9C%93&q=is:open%20label:%22priority:%20high%22%20label:%22bug%20(ezyang%20is%20planning%20to%20delete%20this%20tag)%22%20milestone:%22Cabal%201.26%22%20" class="">https://github.com/haskell/cabal/issues?utf8=%E2%9C%93&q=is:open%20label:%22priority:%20high%22%20label:%22bug%20(ezyang%20is%20planning%20to%20delete%20this%20tag)%22%20milestone:%22Cabal%201.26%22%20</a>><br class=""><br class="">shows not that many.<br class=""><br class="">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.<br class=""><br class="">cabal-install-1.24.0.1 has 12 open issues, should we create cabal-install-1.24.1 -milestone and move them there?<br class=""></blockquote><br class="">I think we should try to arrange a phone call behind all the Cabal<br class="">stakeholders and have a triage session to remilestone these bugs.<br class=""><br class="">Edward<br class=""><br class=""></div></blockquote></div><br class=""></div></body></html>