Skip to content

CONTRIBUTING.adoc

Latest commit

 

History

History
120 lines (86 loc) · 3.56 KB

CONTRIBUTING.adoc

File metadata and controls

120 lines (86 loc) · 3.56 KB
Raw

Contributing to Trigger

Table of Contents

Introduction

Thank you for your interest in contributing to Trigger! This document outlines the guidelines for contributing to this project.

Code of Conduct

By participating in this project, you agree to abide by the Code of Conduct.

How to Contribute

Reporting Issues

  • Use the GitHub issue tracker to report bugs

  • Include detailed information about the issue

  • Provide steps to reproduce

  • Include relevant logs and configuration

Suggesting Features

  • Open a feature request issue on GitHub

  • Describe the use case and benefits

  • Discuss with maintainers before implementing

Submitting Changes

  1. Fork the repository

  2. Create a feature branch (git checkout -b feature/amazing-feature)

  3. Make your changes

  4. Add tests for new functionality

  5. Ensure all existing tests pass

  6. Commit your changes (git commit -m 'Add amazing feature')

  7. Push to the branch (git push origin feature/amazing-feature)

  8. Open a Pull Request

Code Review Process

  • All PRs require at least one approval from a maintainer

  • CI checks must pass

  • SPARK proofs must verify (for Ada/SPARK code)

  • Code must follow project standards

Development Standards

Ada/SPARK Code

  • Use SPARK for safety-critical components

  • Include preconditions and postconditions

  • Use strong typing

  • Handle all exceptions

  • Include comprehensive documentation

Zig Code

  • Follow Zig language conventions

  • Use allocators properly

  • Handle errors explicitly

  • Document all exported functions

Idris2 Code

  • Use dependent types where appropriate

  • Maintain purity where possible

  • Document all exported definitions

General

  • Follow existing code style

  • Use meaningful variable and function names

  • Include comments for complex logic

  • Keep commits atomic and well-described

Testing

  • All code must be tested

  • Include unit tests for new functionality

  • Test edge cases and error conditions

  • Maintain existing test coverage

License

By contributing to this project, you agree to license your contributions under the same licenses as the project:

  • Code: Mozilla Public License 2.0 (MPL-2.0)

  • Documentation: Creative Commons Attribution-ShareAlike 4.0 (CC-BY-SA-4.0)

See LICENSE and LICENSES for full license texts.

Acknowledgement

All contributors retain copyright to their contributions. By submitting code, you agree to license it under the project’s licenses as described above.

The original project concept and design is by 2nixx (T.me/NetworkCriminals).

Signed commits

Every commit that reaches the default branch must be signed; a ruleset refuses unsigned pushes. Estate policy: SIGNING-POLICY.

  • People and interactive agents sign with an SSH key registered on GitHub as a signing key (gpg.format=ssh, user.signingkey=<key>.pub, commit.gpgsign=true). The committer email must be verified on that account.

  • Apps, bots and workflows never git push local commits. They write through the API (createCommitOnBranch or the estate signed-push action) so that GitHub signs each commit.

  • Merge PRs with squash. The ruleset checks every commit on the PR branch, not just the result, so one unsigned commit blocks the merge. Re-create such a branch with signed commits (git cherry-pick -S) and open a new PR. Rebase-merge replays commits unsigned and is disabled.