Great idea! See https://github.com/haskellfoundation/tech-proposals/issues/12#issuecomment-916310039, which will eventually work its way into a more proper proposal.
Thanks, Richard > On Sep 7, 2021, at 9:04 PM, Chris Smith <cdsm...@gmail.com> wrote: > > Oops, I meant to include this URL: > 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> > 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 > <mailto: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 > <mailto: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 > <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 <mailto:ghc-devs@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > <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
