-
Notifications
You must be signed in to change notification settings - Fork 18
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
Comments
FYI getting this done is being discussed at haskellfoundation/tech-proposals#24 |
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. :) |
Maybe some kind of phase could be introduced to aid in communicating the first steps?
I'd certainly appreciate more formality. |
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. |
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.) |
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?
The text was updated successfully, but these errors were encountered: