What we need right now is a good technical documentation explaining how the network works, how to create embedded contracts, how to setup nodes and what developer tools are readily available.
I think this is mandatory for onboarding more developers to come and build on NoM.
Yes, was discussing this with @mehowbrainz the other day and he mentioned some plans that leverage Intercom with ZenonOrg materials but we also do have a Docs page already that just needs a lot of TLC.
Avalanche one looks great. Despite their downfall, I always thought Terra was really professional with product and docs (Station | Terra Docs)
Unfortunately I do not have docs experience but I would very gladly support an A-Z proposal for anyone who has docs experience that wants to take the lead here.
Technical documentation: I originally thought we could use Intercom to unify Marketing/Sales/Developer support under one platform while onboarding, but I think the ReadMe platform is more robust for developers, so I’m okay to branch it out from Intercom. Intercom themselves even use it for their developer / technical documentation. I like how they have a good UX for API versioning too. Feels more organized compared to Gitbook IMO.
Support documentation: Intercom’s Help Centre product. We got access to a startup program as mentioned here.
We intend to use Intercom in all of the zenon.org funnels and landing pages, with automation/bots/human support by community. Will primarily use Intercom by Marketing, Sales and Support.
If developers.zenon.org replaces the current docs.zenon.org, I will likely create marketing.zenon.org under some platform/tooling (maybe Intercom). The idea will be to organize and host the variety of assets marketing/sales teams could use for campaigning. Or the whole marketing docs could get organized under the attribute.zenon.org family since all marketing tools will be built on that brand.
I’m concerned about ownership and control of the documentation, as well as cost.
I don’t particularly like the idea of subscribing to and relying on a third-party service to maintain our documentation. Please correct me if I’m wrong about what you’re suggesting, @mehowbrainz.
At this time, I would prefer to keep costs low, decentralize hosting (multiple mirrors), and allow anyone to contribute. Worst case, anyone can fork the repo and maintain their own documentation.
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.