As to the problems I see with docs, please note I [already took some effort to try and explain them](https://forum.nim-lang.org/t/4523#28911), but it feels to me like it was dismissed or ignored. So I find it hard to muster more energy to try and explain it again, maybe in different words, if it looks like no one's really interested in hearing. I know it's not a very glamorous area to contribute, so I'm trying to avoid moaning with critique while not contributing actual code for this myself. But trying to analyze the essence of what problems I see is also an effort for me, so if someone really wants it, I'd like to at least feel heard and understood. In other words, in UX, a solution to "I have a problem" is not in saying "because you're doing it wrong", a.k.a. blaming the victim, but rather it should be assumed the UX has a problem, which needs to be actively understood, identified, and attempted to be fixed.
As to the index... first of all, I didn't even realize it's there and I should use it, until I was told about it. Secondly, personally I still haven't really found a good way to make it useful to me. The most painful problem I see with both the index and the grouped docs is that of discoverability, that is, browsing for something I need, I know what it's related to, but don't know how it's named. For example, for string-related functions, I must check strutils, but if not found there, then also search for all occurrences of `: string` in the "system" package. In the index, it's even worse. Whereas in Go, at least for more complex types, methods are grouped by the type they operate on. Also, the index in godoc is very useful for taking a quick glance at what's available in a package. I hunger to see better grouping in Nim docs. And less of the meaningless, noisy repetition (i.e. tons of the repeated `==` operators making the "side panel" index in "system" library useless -- I mean not The Index, but the per-package index on left side, as shown in the image in the thread I linked to above). As to the APIs, I can't quickly invoke much specifics now, I'd have to browse through the docs to try and list what I mean. Though as to braindead, yes, I'm afraid I feel so about the part of the API of the sha1 package, where AFAIK I can't easily get the actual bytes of the SHA sum, in non-serialized format (i.e., not converted to hex). I cannot understand why I [seem to have to go through parseHexStr($secureHash(s))](https://github.com/akavel/dali/blob/d79cec81293abc5f3a87f4d879a225991395b62b/src/dali.nim#L333-L334), or how could I avoid it. If it's possible to do it easier, I would love to see this documented explicitly, as I wasn't able to grasp it. I considered asking about this in an issue, but, somehow, didn't collect enough courage to do it yet.
