The important issue that becomes obvious reading this thread is the culture mismatch. There's different approaches to working on an open and community-driven project, there's different approaches to collaborating with other developers in such projects. Some prefer diving in and exploring things of their interests/needs, others need to be directed to the hot-spots where they will fill their future contributions will have the most net value, some need to feel their own work falls in line with some generally accepted roadmap.
Every community needs to do its best to try to accommodate all of the above and more, so while communicating with others one should be aware the other part can function on completely different suppositions. As we all know here, snark, bluntness and even arrogance are some of the words that repeatedly get mentioned when talking about the Nim community elsewhere. In most cases, this is just the aforementioned mismatch (except the rare cases when it isn't). I personally don't care, but IMO it's better to fail on the side of politeness and generous interpretations. I think, the original post here, as well as my [old thread](https://forum.nim-lang.org/t/8091) about docs just go against the default "Nim" way of development. I believe it would be wise to think what alternatives to "Stop complaining and go make some PRs" responses could be offered to the obviously well-intentioned attempts of the newcomers with the different default modus operandi to orient themselves in an established community. * * * Regarding concrete examples. Have you seen the docs for strscans? It's a complete mess, no structure, a couple of examples, no directions on how to approach different tasks where the module can be useful, all while documenting 2 different syntaxes additional to the language. Speaking of "just write some": One of my [first attempts](https://github.com/nim-lang/Nim/pull/19689) of expanding a tiny bit of docs unsupervised, where I expected no issues or conflicts with any work of others by providing a runnableExample, bumped into a compilation error on Windows (1), the API of the function possibly in need of a small fix (2) and, later, the possibility of the whole module being [removed](https://github.com/nim-lang/RFCs/issues/503) (3). The PR hangs there unnoticed since April, which doesn't really help. Now imagine how some other person, who's able to write some actual good code and who's used to the other way of collaborating (see above) would feel in this situation.
