-
Notifications
You must be signed in to change notification settings - Fork 21
Issue template, take 2 #11893
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue template, take 2 #11893
Conversation
One small nudge for a bug, a giant time-saver for us.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For comparison, in the Dotty repo the menu of choices is: https://github.com/lampepfl/dotty/issues/new/choose
And when you pick "bug report" you see: https://github.com/lampepfl/dotty/issues/new?assignees=&labels=itype%3Abug&template=bug.md&title=
My overall take is: I'm 100% in favor of having the menu of choices, it's super awesome. But then after a choice is made, let's try to keep each individual template minimal. Fsvo "minimal".
// TODO add compilation output here | ||
``` | ||
|
||
## expectation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about condensing the second & third sections into a single one, maybe "## Expected vs. actual results"
Let's err on the side of less structure rather than more structure, is my personal take this. I hate filling out forms like I'm at the DMV.
Happy to accede to consensus on this, though. Or to authority :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Painting yellow lines on the road probably won't magically remove all traffic accidents. But in the aggregate, having them should improve the median driver's behavior when they are driving on unfamiliar roads. imho, separating out the expectation and asking people what they expect is similar: It makes the tone of the bug reports more constructive, setting up for a more collaborative fact finding.
For example, on sbt/sbt recent bug reports like sbt/sbt#5444 and sbt/sbt#5449 are good example of good bug reports.
I should also note that headers etc are meant as guidelines, and advanced users are free to ignore them as they see fit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm with Eugene on this one. Even on the receiving end the little moment's thought having to figure out if what I'm writing are my expectations or if they're what I think should be fix/changed/etc, is very valuable for the resulting issue.
To me the biggest win is avoiding those tickets where the sense is "well, isn't it obvious what should've happened?! Excercise for the reader." It's good to be black-on-white about this. Sometimes I even forget what I expected at the time, when I stumble upon old sbt issues. It's net positive, IMHO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
## What the hell did you expect?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM like this, we can give this a try
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
Thanks, I'm going to go find a bug so I can try it out! |
Fixes #11831
One small nudge for a bug, a giant time-saver for us.
This is a resend of #11454, but more like Dotty's.