-
Notifications
You must be signed in to change notification settings - Fork 18
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
The index and the future of this repository #519
Comments
I hear you, @noughtmare . The thought process in putting the message index here was that we were hoping that describing them and improving them would fit nicely together, but the describing has completely overwhelmed the improving, and that's not good. I don't think that GitHub's tag feature is up to the task of making notifications work again for you and others, so I'll move the message index, its instructions, and its issues to a new repository in the coming week. I'm in the process of figuring out how to do that - it looks like I'll need a little shell script or something, because there's no "bulk transfer issues with this tag" feature as far as I can tell. I'm sorry to have made your life more difficult, and I'll fix it. |
@noughtmare Thanks for voicing your concern. While I like the error message index, I agree that the activity generated is a bit distracting for the original purpose of this repo (I felt similarly looking over my notifications in the last couple weeks). This consideration was definitely overlooked when we considered adding the index (at least I hadn't anticipated this). I appreciate that @david-christiansen is open to moving that index to another repo, that seems like a reasonable solution. |
As the person who opened the 400 issues, I apologise greatly to everyone whose inboxes and notifications I have overwhelmed. I didn't realise how many people actively used the repo to track the improvements of error messages within GHC itself (I naively assumed that discussion primarily happened within the GHC error tracker itself). |
Current status: I've got an alternative repository created, and I'm working on getting the index related issues transferred. I've got it scripted, but I'm getting some intermittent failures that make it require a bit of babysitting and some restarts. |
@david-christiansen could you link it here as well? Maybe also link it in the readme here with a small section explaining this repo is for improving messages and the other one for the index and same on the other repo? That it's for the index but if you want to suggest improvements to the error message in GHC to file it here. |
I will absolutely link to it once I get everything migrated - I'll add something like "This repository previously also hosted an effort to document Haskell error messages. It has moved to LINK" to the README. |
I've moved it to https://github.com/haskellfoundation/error-message-index . That repo needs a little bit more cleanup, but everything is gone from here now and I've added a link to the new repo in the README. My apologies once again for the inconvenience. |
The party here has ended, but I just wanted to pipe up that I may have been the one to recommend re-using this existing repo for the new work, though I agree that it was the wrong choice. Thanks @david-christiansen for separating out the repos so quickly. |
@david-christiansen @ketzacoatl @goldfirere
I wanted to point the author of this reddit post to this repo to open an issue with their suggestions for improving error messages, but due to the recent activity I don't feel comfortable doing that any more.
While I appreciate the error index work a lot, I feel like all the new issues and activities have overwhelmed what this repo used to be. I have had to disable notifications and I think people will no longer feel like this is the right place to report issues with error messages and work on improving them.
I'd say reporting and improving error messages and building an index of all error messages with explanations are mostly unrelated projects. While I can imagine there are some interconnections, I don't think having these two projects in two separate repositories will cause many problems.
Would it be a good idea to try to salvage our old work by splitting this repo into two or has that ship sailed?
Or do you think the index and and our old more casual process can coexist in this repo? Does having both of these projects in the same repo still have enough advantages to be worth the extra noise?
Also, I see that the new contributing document only concerns the index. I think newcomers can be confused by that as to what the whole purpose of this repo is/was and I don't like that some newcomers might feel like they have to read a long document before they can submit their grievances or suggestions about error messages.
The text was updated successfully, but these errors were encountered: