If you're excited about the ideas here, this page will be kept up to date with ways to get involved.

  1. Build stuff using trillium. Open source if possible, but even if not, feedback from actual deployed applications will be given higher priority than issues that aren't driven by real use cases.
  2. Build new handlers for trillium. The intent of trillium's design is that as many components as possible should be replaceable. It would make me very happy to deprecate one of the components I built in preference to a more robust alternative. All trillium-compatible crates will be linked in a section of the documentation.
  3. Contribute to the documentation and tests
  4. File issues for bugs

ā¯—Please don't file a Pull Request, regardless of how small, without prior discussion on an Issue. All PRs without an associated issue will be immediately closed. I value your time and want to make sure that any code you write is in an aligned direction.