new label: diagnostic quality

Chris Smith cdsmith at gmail.com
Wed Sep 8 01:03:19 UTC 2021


Hi Richard,

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.

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.

On Tue, Sep 7, 2021 at 2:51 PM Richard Eisenberg <lists at richarde.dev> wrote:

> Hi devs,
>
> 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.
>
> In particular, if you spot a ticket arising from
> https://github.com/haskell/error-messages, you may want to give it the
> "diagnostic quality" label.
>
> If you disagree with the choice to make this label, please push back!
>
> Thanks,
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210907/dcad7f51/attachment.html>


More information about the ghc-devs mailing list