<div dir="ltr">Oops, I meant to include this URL: <a href="https://github.com/google/codeworld/issues?q=label%3Aerror-message+%22code.world%2Fhaskell%22">https://github.com/google/codeworld/issues?q=label%3Aerror-message+%22code.world%2Fhaskell%22</a> is the full list (including closed issues) of cases where someone has reported a misleading error message at code.world/haskell</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 7, 2021 at 9:03 PM Chris Smith <<a href="mailto:cdsmith@gmail.com">cdsmith@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Richard,<div><br></div><div>One thing that I've done with CodeWorld for years now was to integrate reporting poor error messages into the core workflow by adding a report button on the compiler output directly in the tool.  This integration files github issues with a special tag for error messages.  Because CodeWorld is targeted at younger users and already rewrites error messages, most of the reports I get from CodeWorld itself are not directly applicable to GHC.  Here's a list of cases where someone clicked that button at code.world/haskell, but I usually close them with no action unless there's something egregious because I want code.world/haskell to be an authentic GHC experience.  In any case, I strongly suggest looking into similar tooling for more standard Haskell environments with editors like VSCode or Emacs.  I don't know if this could be done in HLS, or would need to be separately implemented for each editor.  I'll happily offer to implement a CodeWorld endpoint for filing GitLab error message reports similar to this which such integrations could post to.  The lower you can make the friction to report a misleading message, the more likely you'll get authentic reports from users rather than idle issue-theorizing.</div><div><br></div><div>These will probably need some kind of a triage process to turn them into actionable issues, and perhaps in my experience to just close 75% of them where it's unclear what was meant or the user just wanted to gripe.  (That may have something to do with the fact that my users have often procrastinated on their homework, though...)  But that triage process is something that you could easily ask for help on.  I would be willing to comb through reports now and then, for example, and look for opportunities to do better.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 7, 2021 at 2:51 PM Richard Eisenberg <<a href="mailto:lists@richarde.dev" target="_blank">lists@richarde.dev</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi devs,<br>
<br>
I've just created a new label in GitLab, called "diagnostic quality". (Diagnostics = errors ∪ warnings.) I intend for this label to be used when the report is about the quality of an error message or warning. That is, the existing message is not wrong, per se, but it's somehow not as helpful as it can be to users. I think it's helpful to separate out such issues from those describing error messages that are just wrong.<br>
<br>
In particular, if you spot a ticket arising from <a href="https://github.com/haskell/error-messages" rel="noreferrer" target="_blank">https://github.com/haskell/error-messages</a>, you may want to give it the "diagnostic quality" label.<br>
<br>
If you disagree with the choice to make this label, please push back!<br>
<br>
Thanks,<br>
Richard<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>
</blockquote></div>