Oops, I meant to include this URL: https://github.com/google/codeworld/issues?q=label%3Aerror-message+%22code.world%2Fhaskell%22 is the full list (including closed issues) of cases where someone has reported a misleading error message at code.world/haskell
On Tue, Sep 7, 2021 at 9:03 PM Chris Smith <cdsm...@gmail.com> wrote: > 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 <li...@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@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
