Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
113 lines (81 loc) · 5.02 KB

CONTRIBUTING.md

File metadata and controls

113 lines (81 loc) · 5.02 KB

Contributing to Thunderdome

We want to make contributing to this project as easy and transparent as possible, whether it's:

Reporting a bug Discussing the current state of the code Submitting a fix Proposing new features Becoming a maintainer

Table of Contents

  1. Code of Conduct
  2. We Develop with GitHub
  1. Versioning
  2. Coding Conventions
  1. Authors
  2. License

Code of Conduct

Please read the Code of Conduct document.

We Develop with GitHub

We use GitHub to host code, to track issues and feature requests, as well as accept pull requests.

Report bugs using GitHub's issues

We use GitHub issues to track public bugs. Report a bug by opening a new issue; it's that easy!

We Use Github Flow

Pull requests are the best way to propose changes to the codebase we use GitHub Flow. We actively welcome your pull requests:

  1. Fork the repo and create your branch from main.
  2. If you've added code that should be tested, add tests.
  3. If you've changed/added APIs, update the documentation.
  4. Ensure the test suite passes.
  5. Make sure your code lints.
  6. Issue that pull request!

Versioning

We use SemVer for versioning. For the versions available, see the tags on this repository.

We prefer frequent, smaller releases to reduce the scope and risk of individual deployments. Major version bumps are reserved for significant changes such as breaking changes to the public REST API or drastic changes to dependencies that affect deployments.

Coding Conventions

  • Thunderdome's priorities in architectural design are SaaS first, self-hosted second, always open-source.
    • Avoid vendor lock-in, use open standards such as open telemetry.
    • Keep the infrastructure requirements minimal, e.g. only requires Postgres, no cloud specific features.
    • Everything should be able to be bundled in the compiled Go binary
      • This includes the UI assets and content

Use of AI Agents

AI agents and code generation tools may be used thoughtfully to produce quality contributions. However:

  • Generated code must adhere to the established codebase standards and conventions outlined in this guide.
  • Pull requests must not include unnecessary artifacts, verbose comments, or boilerplate that is typical byproducts of AI generation processes.
  • Do not use AI to "vibe code" entire features without careful understanding and review of the generated implementation.
  • All code, whether AI-assisted or manually written, must be reviewed carefully for correctness, maintainability, and alignment with the project's architectural principles.
  • Contributors are responsible for ensuring the quality and appropriateness of any AI-generated code they submit.

Go code conventions

  • Follow Effective Go and Code Review Comments Guide from the Go project as much as possible within reason.
  • Go is not an Object-Oriented Programming language, we favor simplicity.
  • Use standard library packages as much as possible, new dependencies should come with a valid reason for adding another dependency.
  • All Go code is linted with golangci-lint on every commit.

UI code conventions

  • The Javascript framework is Svelte transpiled with Typescript
  • CSS framework is Tailwind
  • All UI code is linted with npm run prettier on every commit.
  • All UI unit tests must pass on every PR before merging.

End-to-End tests

End-to-End testing utilizes Playwright and aid in validating that Thunderdome's primary features continue to work with every code change.

  • End-to-End tests run on every pull-request commit.
  • Write end-to-end tests that can be run in parallel.

Authors

See also the list of contributors who participated in this project.

License

When you submit code changes, your submissions are understood to be under the same Apache 2.0 License that covers the project. Feel free to contact the maintainers if that's a concern.