haskell
Timeline for error message improvements?
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?
FYI getting this done is being discussed at https://github.com/haskellfoundation/tech-proposals/pull/24
I beg to disagree with @tomjaguarpaw -- I don't think https://github.com/haskellfoundation/tech-proposals/pull/24 covers this. That proposal is all about internal architecture, not about the phrasing of error messages. My previous HF proposal (https://github.com/haskellfoundation/tech-proposals/pull/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? Like,
- Issue Confirmation (Coverage Check?)
- Establishing Specification
- Summarizing to a GHC issue
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.)