Skip to content
Bryan Call edited this page Mar 19, 2026 · 2 revisions

Contributing

All contributions to Apache Traffic Server are made via GitHub Pull Requests. This page explains the workflow for submitting code, filing issues, and working with the community.

Filing Issues

  • Bug reports and feature requests: File a GitHub Issue.
  • Describe the problem clearly, including platform, ATS version, and steps to reproduce.
  • If you already have code, you can skip the issue and go straight to a PR (see below).
  • An issue is not required to submit a PR, but if one exists, reference it.

Migrating from Jira

The project previously used Jira for issue tracking. If you encounter an old Jira ticket that's still relevant, create a GitHub Issue with the relevant information and request the Jira ticket be closed.

Pull Request Workflow

Branching

  1. Fork the repository on GitHub.
  2. Always branch from master unless you are submitting a backport.
  3. Keep your branch up to date with master before submitting.

Writing a Good PR Description

  • Make the subject line short (< 50 characters) but descriptive.
  • If there's no existing issue, explain the problem in the PR description.
  • Reference any related issues: "Fixes #1234" or "Related to #5678".

Formatting Your Code

Always format your code before submitting. CI will reject improperly formatted code.

cmake --build build --target format

See Coding Style for the full style guide.

Labels and Milestones

Set the appropriate metadata on your PR:

  • Milestone — the target release version
  • Labels — categorize the change (bug, enhancement, etc.)
  • Assignees — assign yourself
  • Reviewers — request specific reviewers if you know who should look at it

Work-in-Progress PRs

If your PR is not ready for review, add the WIP label. This signals to reviewers that the code is still in progress and shouldn't be merged.

Backport PRs

  • Add the Backport label.
  • Target the appropriate release branch (e.g., 9.2.x), not master.
  • Only the Release Manager should merge backport PRs to release branches.

Linking Issues to PRs

If your PR fixes an existing issue, include the closing keyword in the description:

Fixes #1234

GitHub will automatically close the issue when the PR is merged. If the PR is related but doesn't fully resolve the issue, use:

Related to #1234

After Your PR is Merged

  • Delete your feature branch from your fork (it's safe to do so after merge).
  • If there was an associated issue, verify it was closed.

Communication Channels

See Also

Clone this wiki locally