Today the Crossplane documentation uses Jekyll, a Ruby based static site generator.
For local development the process requires installing NPM, Docker and then running the build, which takes multiple minutes (at least on my M1 Mac).
The overhead and time required for building locally is a barrier to contributing to Crossplane community documentation.
How could Crossplane help solve your problem?
I propose that Crossplane documentation moves to the Hugo static site generator.
Hugo is a single binary that builds larger sites in sub-second times, making the local development of content much easier.
Kubernetes uses Hugo for their documentation, allowing Crossplane to align on a tool that the community is already familiar with.
Hugo is Go based and uses Go Templating for their template engine instead of Jekyll's Ruby based Liquid language. Aligning with a Go-based tool makes sense given the Crossplane Go code codebase.
I volunteer to make the required changes for porting the existing site to Hugo.
What problem are you facing?
Today the Crossplane documentation uses Jekyll, a Ruby based static site generator.
For local development the process requires installing NPM, Docker and then running the build, which takes multiple minutes (at least on my M1 Mac).
The overhead and time required for building locally is a barrier to contributing to Crossplane community documentation.
How could Crossplane help solve your problem?
I propose that Crossplane documentation moves to the Hugo static site generator.
Hugo is a single binary that builds larger sites in sub-second times, making the local development of content much easier.
Kubernetes uses Hugo for their documentation, allowing Crossplane to align on a tool that the community is already familiar with.
Hugo is Go based and uses Go Templating for their template engine instead of Jekyll's Ruby based Liquid language. Aligning with a Go-based tool makes sense given the Crossplane Go code codebase.
I volunteer to make the required changes for porting the existing site to Hugo.