Contributing Guidelines

First impressions — introducing yourself and your use-case

One of the best ways to participate within a new open source community is to introduce yourself and your use-case. This builds goodwill, but also means the community can start to understand your needs and how best to help you.

Given that the community is made up of volunteers, making a good first impression is important to getting their ear and attention. Here is a simple introduction you could try:

"We at Company Y have an issue with X, and would like some help. What we're trying to achieve is Z"

The more context you can give the community, the more the community can be of help to you.

The primary ways to engage with the community are via GitHub Issues and Enterprise Support.

• GitHub Issues — for suspected bugs and feature requests, fill out the whole template.
• Enterprise Support — you will have an agreed way to contact Axiom Eye Ltd for direct support and help.

How can I get involved?

There are a number of areas where contributions can be accepted:

• Write code for the CLI, API, or other integrations
• Write features for the front-end UI
• Write sample analyses or templates in any language
• Review pull requests
• Test out new features or work-in-progress
• Get involved in design reviews and technical proof-of-concepts (PoCs)
• Manage, triage and research Issues and Pull Requests
• Engage with the growing community by providing technical support on GitHub
• Create docs, guides and write blogs
• Speak at meet-ups, conferences or by asking where you can be of help

This is just a short list of ideas — if you have other ideas for contributing please make a suggestion.

I want to contribute on GitHub

I've found a security issue. Please follow responsible disclosure practices and send an email to decoder@axiomeye.com. Bear in mind that instructions on how to reproduce the issue are key to proving an issue exists, and getting it resolved.

I've found a typo. A Pull Request is not necessary. Raise an Issue and we'll fix it as soon as we can.

I have a (great) idea. We'd like to make Decoder the best it can be and welcome new contributions that align with the project's goals. Our time is limited so we'd like to make sure we agree on the proposed work before you spend time doing it. You need to raise a proposal first.

What makes a good proposal?

• Brief summary including motivation/context
• Any design changes
• Pros + cons
• Effort required up front, and for ongoing maintenance
• Migration strategy / backwards-compatibility
• Mock-up screenshots or examples of how the change would work

Once your proposal receives a design/approved label you may go ahead and start work on your Pull Request.

Paperwork for Pull Requests

• Sign off your commits (git commit --signoff or -s)
• Complete the whole template for issues and pull requests
• Reference addressed issues in the PR description and commit messages — use "Fixes #IssueNo"
• Always give instructions for testing
• Provide CLI commands and output or screenshots where you can

The commit subject-line should start with an uppercase letter, not exceed 72 characters, and not end with punctuation. Leave a blank line after the subject-line before any commit body.

I need to add a dependency

Components must be licensed with an MIT, BSD, or Apache 2.0 license. We may ask you to write your own code when dependencies are trivial, or unmaintained by their authors.

Governance

Decoder is hosted by Axiom Eye Ltd (registered number 16571532), a company which also offers commercial services and support. The project is maintained and developed by a number of regular volunteers and a wider community of open-source developers.

License

All third-party contributions are licensed under the MIT license, all Axiom Eye Ltd contributions are licensed under the Decoder CE EULA.

Copyright notice

It is important to state that you retain copyright for your contributions, but agree to license them for usage by the project and author(s) under the MIT license. Please add a copyright notice to new files you add where this is not already present:

// Copyright (c) Axiom Eye Ltd 2026. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.

Sign your work

Every commit in your PR or patch must be signed off. The sign-off certifies that you wrote the patch or otherwise have the right to pass it on as an open-source patch, per the Developer Certificate of Origin. Add a line to every git commit message:

Signed-off-by: Joe Smith <joe.smith@email.com>

If you set your user.name and user.email git configs, you can sign your commit automatically with git commit -s.