this post was submitted on 07 Sep 2023
5 points (100.0% liked)
/kbin meta
4 readers
1 users here now
Magazine dedicated to discussions about the kbin itself. Provide feedback, ask questions, suggest improvements, and engage in conversations related to the platform organization, policies, features, and community dynamics. ---- * Roadmap 2023 * m/kbinDevlog * m/kbinDesign
founded 1 year ago
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
@unofficial_kbin_guide for the most part we can actually copy and paste this guide to the official wiki page we have. ๐
@melroy I am glad you like it!
@unofficial_kbin_guide That's amazing. Merloy is right, it would be great to have some of this in the official wiki. I would go a step further, I'm in the process of preparing a new project page. I would be very grateful if I could use your work there. If you don't mind and have an account on Codeberg, please send me your username in a private message, I'll add permissions to the repository, and we can work on this together.
@melroy
@ernest @unofficial_kbin_guide I think a dedicated website like this kbin guide is indeed the way to go. Codeberg wiki is limited in several ways. Making this guide somehow part of an official project / documentation would be great. @unofficial_kbin_guide You agree?
@melroy @ernest I do not have a codeberg account. I would have to get that set up and get back to you. As for the best place for the docs to live, I would say that you both are right (cop-out answer, I know). Here's why:
To be fully searchable, but only bring relevant guide results the docs should be their own package (I really did not see a way off hand to search the codeberg wiki). To engage the users the docs should be easy to navigate, easy to search, and easy to read. As for the wiki, I am not super familiar with codeberg, but the wiki does look limited. I am not sure if Codeberg comes with a "pages" option like github.
However, https://unofficial-kbin-guide.surge.sh/ is built in markdown using mkdocs material. So, the current repo https://codeberg.org/Kbin/kbin-docs could be repurposed to hold these files and set up to deploy on pr merge. Take a look at https://docs.codeberg.org/ and https://codeberg.org/Codeberg/Documentation for example. I would not tie doc updates with code releases so we do not have to wait on code releases to deploy doc updates.
I would advise to serve the published docs outside of codeberg since not all (maybe even most) of kbin users are not necessarily developers. So, I would serve the content somewhere like https://kbin.pub/en/docs or at https://kbin.social/docs. If choosing kbin.pub we will have to make a clear distinction between "user" docs and "developer/server" docs. Also, if using kbin.pub ... then the help column on kbin.social (as well as other kbins) must be updated to point to the new docs.
I am happy to help. Let me know your thoughts.