I think the number one thing could be to lower friction in finding related information. Sure there is google, but some topics they take a long time to investigate and then there is no place to write about the findings (for example which library to choose A, B or C). You can put it on a personal blog sure. That would be one more place on scattered resources over the internet. Would be cool to start thinking of a platform (= website) that make it easier to discuss / add information. The way realworld haskell does it with inline comments is really cool. But also just general wikipedia style is useful.
Some concrete ideas how this could materialize:
Try to unify user accounts to become one “haskell” account. gitlab, wiki, hackage, discourse … as much as possible. Also helps moderating of content.
Open up new (forum) threads in the documentation on hackage.org on a: package, module, function etc … This would show as a not annoying button (again: like realworld haskell does it: “17 comments”).
Would be nice if comments can get likes (upvote). And then just show the comment by default when it gets enough upvotes (deemed to be important enough).
Also nice if packages, modules and functions can get likes, in a subtle way like reddit marks upvotes next to posts. The we can sort these things by likes so people know what others are using.
Allow people to open up guides (the kind of guide that they would put on a personal blog post). Does not need to relate to a single package or so. (either write protected or as wiki page, configurable). This could be as easy as having an official git repository where people can PR new markdown files which then will be generated on html page.
Have a way to link things together. Thing is if you just paste an http link in a comment to some other function it doesn’t link back automatically. Would be nice to have something like github “this function has been mentioned in …”. This would likely require some analysis (of code as well) + database (possibly graph structure).
I think this idea is worthy of haskell foundation because it spans over multiple concerns and working groups, which will be too difficult to carry out for a single person or company even. It’s technically a bit boring to implement, but very feasible. I like it because it will compound value over time as people are more discussing and contributing. Maybe this is not obvious to GHC maintainers or library authors … but the barrier to change some documentation is very high. Which is good in principle (to keep up quality), but next to that there is no low friction way available (or it’s in a corner of the internet where it is hard to find).
Second thing it would be nice to have a way to stay backwards compatible but not to be stuck with legacy decisions that are hard to change. For example the situation with prelude. There are alternative preludes sure, but no sight in community concensus or a way to move this forward. What rust did with the 2018 edition of the compiler was very interesting, it allowed users a choice to stay backwards compatible or flick the switch deprecating old functionality. I’m not sure how to solve this though. Having some people inventing yet another alternative prelude does not seem the way to go as this has been tried before many times. I guess the best way to start would be to have a good comparison between existing preludes, and possible even on a fine grained level (like a function), so things could reach concensus one stone at a time. The concensus thing people have been doing among each other in discussion threads on github. But it would need a bigger support with both moderation of the discussion and also a technical solution how to choose prelude out of the ghc box.
Personally i find these issues more interesting than improving a tool or getting % of compiler performance. People can (and did) take it onto themselves to make a tool or fix a performance bug. I also like a faster GHC, but there is something to be said for starting with things that can not be solved without haskell foundation.