Contributing

We welcome feature requests, bug reports and contributions for code and documentation.

Reporting Issues

Reporting bugs can be done in the GitHub issue tracker. Please search for existing issues first to help prevent duplicates.

Please include the version (goalert version) with new bug reports.

Code Contribution

GoAlert is already used in production environments, so any new changes/features/functionality must, where possible:

  • Not alter existing behavior without an explicit config change
  • Co-exist with older versions without disruption
  • Must have a safe way to disable/roll-back

It should always be safe to roll out a new version of GoAlert into an existing environment/deployment without downtime.

As an example, things like DB changes/migrations should preserve behavior across revisions.

Pull Requests

Patches are welcome, but we ask that any significant change start as an issue in the tracker, prefereably before work is started.

Be sure to run make check and tests before opening a PR to catch common errors.

UI Change Guidelines

  • Complex logic should be broken out with corresponding unit tests (we use Jest) into the same directory. For example: util.js and util.test.js.
  • New functionality should have an integration test (we use Cypress for these) testing the happy-path at a minimum. Examples here, and more information here.
  • React components should follow React idioms, using common prop names, and having prop-types defined.

Backend Change Guidelines

  • Use unit tests as a tool to validate complex logic. For example.
  • New functionality should have a behavioral smoketest at a minimum. For example. Documentation on our smoketest framework can be found here.
  • Go code should follow best practices, exported functions/methods should be commented, etc..