Replies: 4 comments 7 replies
-
Here is a good philosophy about organizing docs https://documentation.divio.com/ If documentation doesn't clearly fit into one of those categories, it likely needs to be edited/refactored. |
Beta Was this translation helpful? Give feedback.
-
How can we extend https://github.com/Raku/doc#vision ? |
Beta Was this translation helpful? Give feedback.
-
META remark: I'm now receiving spam as if there has been a response here. Yet I don't see the spam here. Did someone remove that spam already? Or was it removed automatically? If it was removed automatically, I wonder why I'm getting the spam :-( |
Beta Was this translation helpful? Give feedback.
-
Right now, I agree that the docs have a bit of a split personality – or, at least, they're trying to be both a reference and a guide, which is pretty tricky. Unfortunately, I don't see a short-term way out of this; the Raku docs are the only thing close to a comprehensive online reference or tutorial for Raku, so they're stuck trying to play both roles. For now, that is. Longer term, I'm really hoping that @ash's Complete Course in Raku will become the go-to Raku tutorial and thereby free the docs to be more of a reference. (I know that there are some print books that offer similar tutorial-like content, but it's way easier to link a free resource than to tell someone to buy a book – which, even when well-intentioned, can come across as saying RTFM). But that's all in the future |
Beta Was this translation helpful? Give feedback.
-
From what I can see, there is no simple, non-technical (or only remotely technical), broad principle or goal for the Raku documentation.
The reason I think this could be useful is that personal opinions can differ about certain aspects and topics of the documentation - there might be situations where we cannot make a consensual choice. There is only one content so it cannot equally please everyone. It would be good to have something to evaluate content and decision by. A goal we can easier agree what exact choice takes closer to.
I'm thinking of something similar to how
-Ofun
is kind of a motto regarding community guidelines. Perhaps it has to be more technical than that because sometimes we need to simply decide about the topics that belong to the documentation in the first place (e.g NQP opcodes probably not) - but anyway, something that is rather broadly applicable than precise.Beta Was this translation helpful? Give feedback.
All reactions