---
title: "Code Submission"
url: https://develop.sentry.dev/sdk/getting-started/standards/code-submission/
---

# Code Submission

This document uses key words such as "MUST", "SHOULD", and "MAY" as defined in

<!-- -->

[RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) to indicate requirement levels.

Statusstable

Version`1.2.0`[(changelog)](https://develop.sentry.dev/sdk/getting-started/standards/code-submission.md#changelog)

These standards cover how code gets into SDK repositories — from branch names and commit messages through to PR descriptions and changelogs. The goal is consistency across SDKs so that contributors and reviewers can move between repos without friction.

## [Commit messages](https://develop.sentry.dev/sdk/getting-started/standards/code-submission.md#commit-messages)

Stablespecified since

<!-- -->

1.0.0

Follow the [conventional commit](https://www.conventionalcommits.org/) format:

```bash
<type>(<scope>): <subject>

<body>

<footer>
```

**Header** (max 100 chars total):

* **Type**: one of `feat`, `fix`, `ref`, `perf`, `style`, `docs`, `test`, `ci`, `build`, `chore`, `meta`, `license`
* **Scope**: optional, SDK-specific
* **Subject**: imperative mood ("Add feature" not "Added feature"), capitalize first letter, no trailing period, max 70 chars

The **body** should explain what changed and why — not how. The code shows how.

The **footer** is for issue references (`Fixes SENTRY-1234`, `Refs LINEAR-ABC-123`), breaking change notices (`BREAKING CHANGE:`), and [AI attribution](https://develop.sentry.dev/sdk/getting-started/standards/code-submission.md#ai-attribution).

See [Commit Messages](https://develop.sentry.dev/engineering-practices/commit-messages.md) for more examples and guidance.

***

## [Branch naming](https://develop.sentry.dev/sdk/getting-started/standards/code-submission.md#branch-naming)

Stablespecified since

<!-- -->

1.0.0

Use the format `<type>/<short-description>`:

* **type**: same types as commit messages (`feat`, `fix`, `ref`, etc.)
* **short-description**: what the change is about, in kebab-case

For example: `feat/add-client-reports` or `fix/rate-limit-parsing`.

***

## [Pull requests](https://develop.sentry.dev/sdk/getting-started/standards/code-submission.md#pull-requests)

Stablespecified since

<!-- -->

1.0.0

### [Start as a draft](https://develop.sentry.dev/sdk/getting-started/standards/code-submission.md#start-as-a-draft)

Create PRs as drafts. Mark them ready for review once CI passes and the description is complete.

### [Write a useful description](https://develop.sentry.dev/sdk/getting-started/standards/code-submission.md#write-a-useful-description)

Every PR needs a description that tells reviewers:

* What the PR does and why
* Links to relevant issues or tickets (required except for typo fixes and one-line doc changes)
* Alternative approaches considered, if any
* Additional context reviewers need

Skip boilerplate, checkbox lists, and template filler. Don't include customer data or sensitive information. The tests in the diff are the test plan — no need to restate them in the description.

### [Keep PRs focused](https://develop.sentry.dev/sdk/getting-started/standards/code-submission.md#keep-prs-focused)

A PR should do one thing well. Don't mix functional changes with unrelated refactors or cleanup. If the work naturally splits into distinct categories, make separate PRs. Smaller, focused PRs are easier to review, reason about, and revert if needed.

***

## [Changelog entries](https://develop.sentry.dev/sdk/getting-started/standards/code-submission.md#changelog-entries)

Stablespecified since

<!-- -->

1.0.0

User-facing changes (`feat`, `fix`, `perf`, breaking changes) need a changelog entry. Internal changes are exempt. If a user-facing change truly doesn't warrant a changelog entry, use the `skip-changelog` label to opt out.

The format and location of changelog entries varies by SDK, but the requirement itself is universal.

***

## [AI attribution](https://develop.sentry.dev/sdk/getting-started/standards/code-submission.md#ai-attribution)

Stablespecified since

<!-- -->

1.0.0

AI models improve over time, and future models will understand the shortcomings of earlier versions. Tagging commits with the model that produced them gives useful signal when debugging — if you know a commit was generated by an older model, you can focus on the kinds of mistakes that model was prone to.

When AI generates or substantially contributes to a commit, add a `Co-Authored-By` line in the commit footer:

```bash
Co-Authored-By: Claude <noreply@anthropic.com>
```

This is the only indicator of AI involvement. Don't add "Generated by AI", "Written with Claude", or similar markers anywhere else in the commit.

***

## [Changelog](https://develop.sentry.dev/sdk/getting-started/standards/code-submission.md#changelog)

| Version | Date       | Summary                                                    |
| ------- | ---------- | ---------------------------------------------------------- |
| `1.2.0` | 2026-03-18 | Remove username prefix from branch naming convention       |
| `1.1.0` | 2026-03-04 | Add username prefix and type descriptions to branch naming |
| `1.0.0` | 2026-02-18 | Initial Code Submission standard                           |
