I think the proposal makes some good points regarding quality and discoverability of documentation. The proposal brings this up somewhat in the bit about searching for monad tutorials, but I wanted to emphasize this wrinkle with regards to discoverability/quality that might be worth putting some cycles into.
I've found it challenging to map the "lexicon" of an imperative programmer to that of a Haskell programmer. For example, a good, canonical C implementation of an algorithm may bear no resemblance to a good, canonical Haskell implementation (no surprise, right?). A programmer may think they should use a Vector for an algorithm because they used one in Java, but is that really what they need to do in Haskell? How can we help guide new programmers who may not be aware of the existence of critical language features that could make their lives easier (and implementations vastly better)? Additionally, helping newer Haskell programmers make use of "more advanced" features instead of reinventing the wheel would also be awesome. I don't know how many times I reinvented folds when I started writing Haskell. It's easy to get a solid kernel of Haskell figured out, and then ignore some other big, important parts.
It can really be challenging to motivate the learning of a feature to a person who's never been exposed to the concept. Monads aren't the only thing that are a sticking point like this. Functors, applicatives, folds, and traversals are all useful things that can seem really foreign to learn, and can be "naively avoided" by the novice programmer.
I don't feel like I have a good answers to these questions right now. Perhaps we could have "case studies" where we refactor Bad Haskell into Good Haskell? Something like "Hey, have you been writing code like this? Well, you need to be writing code like THIS instead." I'm sure I've missed some good work in this area. Would love to hear the thoughts of the community on this!