Skip to content

Timeline for error message improvements? #32

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

Open
Abastro opened this issue Feb 1, 2022 · 5 comments
Open

Timeline for error message improvements? #32

Abastro opened this issue Feb 1, 2022 · 5 comments
Labels
tool:GHC For error messages originating from GHC type:question Question about the project, process, how something works, etc

Comments

@Abastro
Copy link

Abastro commented Feb 1, 2022

I'd like to know when these error message improvements would be reflected on the upstream GHC.
Surely such a communication would help many others as well.
Could you prepare some timeline for this purpose?

Plus, how are the improvements to the error messages implemented?
Are they manually implemented through PRs by volunteers? Any dedicated team in GHC for this?

@tomjaguarpaw
Copy link
Member

FYI getting this done is being discussed at haskellfoundation/tech-proposals#24

@goldfirere
Copy link
Contributor

I beg to disagree with @tomjaguarpaw -- I don't think haskellfoundation/tech-proposals#24 covers this. That proposal is all about internal architecture, not about the phrasing of error messages. My previous HF proposal (haskellfoundation/tech-proposals#21) was deemed to be too amorphous and far-reaching to be actionable. The new proposal capitalizes on what were deemed the interesting parts of the old one -- the internal improvements.

Right now, there is sadly no pipeline for getting ideas from this repo into production. Each ticket here needs to be shepherded to a conclusion with a new suggested wording / other improvement, then a GHC ticket made, and then the GHC ticket must be addressed. That last step is beyond the scope of this repo or the ability of most volunteers, but I would love to see more action on the first steps. I started this repo with @ketzacoatl in the hopes that others would help move things along. It really doesn't take much -- just consistent application of love. :)

@Abastro
Copy link
Author

Abastro commented Feb 2, 2022

Maybe some kind of phase could be introduced to aid in communicating the first steps?
Like,

  • Issue Confirmation (Coverage Check?)
  • Establishing Specification
  • Summarizing to a GHC issue

I'd certainly appreciate more formality.

@ketzacoatl
Copy link
Collaborator

Part of the problem is that we don't have a clear agenda or process laid out, no agreements with GHC HQ, and no clear / obvious course of action. So ATM most of these are on a case-by-case basis as opposed to having a clear path from open issue to closed as either no good or actionable and action complete.

@tomjaguarpaw
Copy link
Member

In these kinds of cases it requires a self-directed and motivated individual to determine what needs to be done and push it through, bringing in interested volunteers where possible. (Sadly, due to time constraints, I can't be that person.)

@ketzacoatl ketzacoatl added tool:GHC For error messages originating from GHC type:question Question about the project, process, how something works, etc labels Mar 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tool:GHC For error messages originating from GHC type:question Question about the project, process, how something works, etc
Projects
None yet
Development

No branches or pull requests

4 participants