Get involved

docuconf is at the stage where a single good comment can change the design. The most useful things you can do right now:

• Review the specification. Read SPEC.md and open an issue on anything unclear, wrong or missing. Its open questions section lists what is still undecided.
• Bring your edge cases. If your platform has bitten you with environment config in a way not yet in EDGE_CASES.md, tell us.
• Try an SDK in a real app. Each of the 16 SDKs is a v0.1 alpha. Start from Get started and open an issue on that SDK's repository wherever it does not fit how your ecosystem works.
• Help an SDK. Each SDK should be shaped by people who live in its ecosystem. If you know its host library well, review its README and example, and tell us where it fights the library instead of extending it.
• Bring a new language. The SDK requirements say what an SDK must do, and the shared conformance suite checks it.
• Try the schema. spec/cue/test.sh runs the CUE meta-schema against valid and invalid examples. Add a case that should fail and does not.

Where things live

Everything is under the docuconf GitHub organization. This website has its own repository, docuconf.dev. Each SDK has its own repository:

• docuconf-go: Go
• docuconf-js: TypeScript (T3 Env) and TypeScript (NestJS)
• docuconf-dotnet: .NET
• docuconf-python: Python
• docuconf-ruby: Ruby
• docuconf-java: Java (Spring Boot)
• docuconf-kotlin: Kotlin
• docuconf-rust: Rust
• docuconf-swift: Swift
• docuconf-elixir: Elixir
• docuconf-gleam: Gleam
• docuconf-cpp: C++
• docuconf-php: PHP (Laravel) and PHP (Symfony)
• docuconf-cobol: COBOL

The specification, its conformance suite and the platform tooling (the docuconf CLI and the Helm chart) live with the Go SDK in docuconf-go. They may move to repositories of their own as the project grows.

Licence

Every docuconf repository, including the specification, the SDKs and this website, is released under the MIT licence.