# Pull Requests

> Our process for contributing pull requests to Directus.

Pull Requests (PRs) are a fantastic way to contribute back to the project. It's one of the fastest ways to see a bug fix or new feature you care about land in the platform.

## Choosing What to Implement

We welcome PRs for any open [Issue](https://github.com/directus/directus/issues). Issues labeled
["Good First Issue"](https://github.com/directus/directus/issues?q=is:open+is:issue+label:%22%E2%AD%90%EF%B8%8F+Good+First+Issue%22) are typically easier to resolve for those who haven't contributed to the codebase before, and are therefore a great starting point.

If you're planning on implementing a bigger feature that doesn't have an issue attached yet, please reach out to our core team ahead of time to discuss.

## Copyright License Agreement (CLA)

All code contributors are required to sign the Contributor License Agreement (CLA). When you start a pull request, a GitHub Action will prompt you to review the CLA and sign it by adding your name to
[contributors.yml](https://github.com/directus/directus/blob/main/contributors.yml). To clarify the intellectual property rights in the project and any Contributions, Directus requires that You accept the
[Contributor License Agreement](https://github.com/directus/directus/blob/main/cla.md). This license is for your protection as a contributor as well as the protection of Directus, recipients of software distributed or made available by Directus, and other contributors; it does not change your rights to use your own Contributions for any other purpose.

## Changesets

To properly generate changelogs and determine the right version number after a change is merged, we rely on [changesets](https://github.com/changesets/changesets). Each pull request should include a changeset that describes whether the change is a patch/minor/major version bump, and describe what the change is. Changesets should be written in past tense.

A changeset can be generated via the following command:

```shell
pnpm changeset
```

### Changeset Bump Definitions

The following are the types of version bumps that can be specified in a changeset:

- Major (x.0.0) - A change has been made that is incompatible with previous versions.
- Minor (0.x.0) - A feature has been added that is backwards compatible with previous versions.
- Patch (0.0.x) - A bug has been fixed that is backwards compatible with previous versions.

### Notices

Use a notice for changes that deserve extra visibility in the release notes, such as deprecations, required migrations, or behavior changes that users upgrading and/or extension authors should be aware of.

Add a `::: notice` block at the end of the changeset body:

```markdown
---
"@directus/app": minor
---

Deprecated the `VResizeable` component

::: notice

- Deprecation for extensions: The globally registered `VResizeable` component has been deprecated. Extension authors should migrate to `@directus/vue-split-panel` or provide their own implementation.

:::
```

The notice is extracted and displayed in the **Potential Breaking Changes** section at the top of the release notes. The rest of the changeset remains in its normal category.

Notices always appear under **Potential Breaking Changes**, regardless of whether the changeset is a major, minor, or patch release. Adding a notice does not affect the version bump. Choose the bump type based on the impact of the change, and add a notice whenever the change warrants additional attention.

**Notice detection is strict.** If the syntax does not match exactly, the notice will not be extracted.

To ensure your notice is recognized:

- Start the block with exactly `::: notice`: all lowercase, with a single space between `:::` and `notice`.
- End the block with `:::` on its own line.
- Do not indent the opening or closing markers, or include trailing whitespace.
- Include some content between the markers. An empty block is not detected.
- Include exactly one notice block per changeset. Multiple notce blocks will result in a malformed output