Gitbook seats aren’t free, ZenonOrg paid for them until this point. Self-hosted solutions still give the control to the infra admin re: database. The forum is an example.
I guess that this vote then applies to whoever wants to contribute to a ZenonOrg hosted technical documentation. I’m fine with whichever option, whether it’s ReadMe or Gitbook, though I’m unsure how to fork Gitbook documentation.
I think regardless of the Pillar opting to provide such a service to the community, the problem of control will exist. The only solution I thought for a future was fragmented ownership of domains (which will require a brand new service/system), or like you mention forks/mirrors.
The ZenonOrg brand believes in a streamlined experience for onboarding newcomers/participants, and hence it proposes ideas which unifies services from a domain, ux, design, branding, flow perspective – with visions to progressively decentralize the trust the community puts into the brand.
If Gitbook can’t be forked, then the other alternative would be a Github repo for content, but that’s not as friendly UX-wise. Can look for other reliable alternatives.
Another platform is Docusaurus, which is a static site generator designed for building documentation websites. It’s typically integrated with version control systems like GitHub, so you could fork the GitHub repository where the Docusaurus site’s files are hosted.
Given that @mehowbrainz is driving the majority of this effort coupled with his experience/track record to show for it, I’m happy to defer to what tools he feels most comfortable executing on even if a bit different from poll outcomes.
I understand your vision and I know you have good intentions.
I’m not even against any of the solutions you’re proposing, but I think we should initially strive for one that benefits the entire community and minimizes the risk of data loss/gating.
The path of least resistance is forking znn-wiki and maintaining versions that are synced/hosted by multiple community members.
Anyone could take that information, transform it however they wish, and present it in a nicer way.
developers.zenon.org repo has been created and the domain has been assigned using Github Pages. Anyone who wants write/maintain permissions DM me your GitHub handle.
The alternative option is to install Docusaurus in this repo. Though we’ll have to wait for admins to review PRs. It depends if we want to go through them, or manage docs ourselves via a new portal like developers.zenon.org ourselves.
If you fork a repository on GitHub, the standard way to get your contributions incorporated back into the parent repository is through a pull request. Here are the general steps:
Fork the repository: Click the ‘Fork’ button at the top right of the parent repository’s main page. This will create a copy of the repository under your own GitHub account.
Clone the forked repository to your local machine: Open your terminal, navigate to the directory where you want the repository, and use the git clone command with the URL of your forked repository.
Create a new branch: It’s generally a good practice to create a new branch for each set of changes you want to make. You can do this with the command git checkout -b branch-name.
Make changes: Make the changes to the code on your local machine.
Commit the changes: Once you’re satisfied with the changes, commit them using git add . to stage all changes, then git commit -m "Commit message" to commit the changes. Be sure to write a descriptive commit message.
Push the changes: Push the changes to your remote forked repository with the command git push origin branch-name.
Open a pull request: Go to your forked repository on GitHub and click on ‘Pull request’. Choose the branch you just pushed from the ‘compare’ dropdown. Review the changes, then click ‘Create pull request’. Write a descriptive title and comments to help the maintainers of the parent repository understand your changes.
At this point, the maintainers of the parent repository will be able to see your proposed changes. They can review them, discuss potential modifications, and ultimately decide whether to merge your changes into the parent repository.
If the parent repo’s maintainer wants to merge some specific contributions from a forked repo, they can do this manually by checking out the changes in the forked repo, applying them to their own codebase, and then committing that as their own changes. However, this method does not recognize the original contributor in the commit history. Thus, pull requests are a more favorable method as they maintain a clear history of contributions and contributors.