• ernest@kbin.social
      link
      fedilink
      arrow-up
      7
      ·
      10 months ago

      @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

        • unofficial_kbin_guide@kbin.socialOP
          link
          fedilink
          arrow-up
          1
          ·
          10 months ago

          @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.