Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
128 lines (94 loc) · 5.28 KB

CONTRIBUTING.md

File metadata and controls

128 lines (94 loc) · 5.28 KB
Raw

Contributing to BatchGen

Thank you for considering contributing to BatchGen! We welcome contributions of all kinds from the community. Whether you're introducing new features, enhancing the infrastructure, fixing bugs, or writing documentation, we appreciate your enthusiasm and value your efforts.

To help make your contributions as smooth as possible, we've put together this guide with helpful tips and best practices for contributing to the project.

Table of Contents

How to Contribute

Before your pull request can be merged, it must pass the formatting, linting, and testing checks (see Development Environment) and satisfy the PR Merge Policy Contract.

Merge Policy

The binding rules for what a PR's file changes must look like before merge — file hygiene, diff scope, commit rules, the author checklist, the reviewer gate, CI enforcement, and override authority — are in PR_MERGE_POLICY.md. It applies identically to every contributor, agent or human. The summary below is the governance part; the contract is authoritative.

To keep the main branch coherent and reviewed, only the project owner presses the Merge button on pull requests. Contributors with Write access — including members of the batchgen-core team — should:

  • Open pull requests targeting main.
  • Push commits to feature branches and PR branches as needed.
  • Review pull requests, leave comments, formally Approve / Request changes.
  • Not press the Merge button on any PR, including their own. Wait for the owner to merge after approval.

The owner is the only person whose merge lands on main. Pull requests must have at least one approving review (from a Code Owner where applicable, per .github/CODEOWNERS) and a green CI status before the owner merges. Direct pushes to main are reserved for the owner only.

This policy is currently enforced socially. When the repository becomes public it will be enforced by GitHub branch protection.

If you fix a bug:

  • Add a relevant unit test when possible. These can be found in the test directory. If you make an improvement:
  • Update any affected example console scripts in the examples directory and documentation in the docs directory.
  • Update unit tests when relevant. If you add a feature:
  • Include unit tests in the test directory.
  • Add a demo script in the examples directory.

Roadmap and Tasks

For beginners, we recommend starting with issues labeled good first issue or help wanted in the issue tracker. Feel free to discuss any ideas before getting started!

Development Environment

Ensure your development environment is set up with the following tools:

  • Format your code with pre-commit hooks:
pip install -r requirements-lint.txt

# add lint hooks to git commit
pre-commit install --install-hooks

This will automatically format your code before committing. However, you can also run the following commands manually:

# format code
pre-commit run -a
  • (Recommended) Sign off your commits:
git commit -s -m "feat: add new feature"

Commit Message Guidelines

We follow the commit format rule based on the Angular Commit Format. This format improves readability and helps generate changelogs automatically.

Commit Message Structure

Each commit message should consist of a header and a body:

<type>: <summary>
<BLANK LINE>
<body>(optional)
<BLANK LINE>
  • Type: Choose from build, ci, docs, feat, fix, perf, refactor, test, chore.
  • Summary: A brief description of the change.
  • Body: Mandatory for all commits except those of type "docs". Must be at least 20 characters long.

Examples:

feat: add logging in sllm worker

docs: add new example for serving vision model

Vision mode: xxx
Implemented xxx in `xxx.py`

For more details, read the Angular Commit Format.