---
description: An introduction to the process, rules and guidelines that for all code contributions to Directus.
readTime: 6 min read
---

# Contributing

Heya! Welcome to Directus, and thank you for taking the time to contribute back to Open Source Software! ❤️ We want
everybody to be able to contribute to Directus, no matter your background or expertise. In order to facilitate that,
we've put together a couple tips and tricks below. Our team truly appreciates every single contributor, community
member, GitHub star, pull-request, bug report, and feature request. Keeping Directus completely free and open-source is
our way of saying: **Thank you!**

> We're here to help!
>
> If you have _any_ questions along your contributor journey, please feel free to come chat with us on
> [our Discord server](https://directus.chat).

## Code of Conduct

**The Directus [Code of Conduct](https://github.com/directus/directus/blob/main/code_of_conduct.md) is one of the ways
we put our values into practice. We expect all of our staff, contractors and contributors to know and follow this
code.**

**Our contributors and maintainers work extremely hard to build Directus as premium open-source software. Please be
respectful of those efforts throughout our ecosystem. Trolling, harassing, insulting, or other unacceptable behavior by
participants will not be tolerated.**

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making
participation in our project and community a harassment-free experience for everyone, regardless of age, body size,
disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education,
socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.

Examples of behavior that contributes to creating a positive environment include:

- Using welcoming and inclusive language
- Being respectful of differing viewpoints and experiences
- Gracefully accepting constructive criticism
- Focusing on what is best for the community
- Showing empathy towards other community members

**Before continuing, please take a moment to read our full
[Code of Conduct](https://github.com/directus/directus/blob/main/code_of_conduct.md).**

## Ways to Contribute

### Reporting Bugs

If you happen to run into a bug, please post an Issue on our main GitHub Issue board:
https://github.com/directus/directus/issues

Please be as explicit and detailed as you can in the bug report. The more information available, the easier it is for
other contributors to help you find the solution or fix. Consider adding a schema snapshot file, or a database dump.

### Leaving Feedback

If you have a great idea for an improvement of the platform, or any other feedback, please make sure to open a new
Discussion on our GitHub Discussions board: https://github.com/directus/directus/discussions

### Document the Project

The [Directus Docs](https://github.com/directus/docs) are living documents that can always be improved on. Notice any
parts of the docs in dire need of some tender love and care? Feel free to open a Pull Request!

### Helping Others

The Directus community is growing quickly, which also means there's more and more people that have questions. Helping
out your fellow developers by answering questions on [Discord](https://directus.chat) or
[GitHub Discussions](https://github.com/directus/directus/discussions/categories/q-a) is a great way to help the
project.

### Pull Requests

#### Bug Fixes

We treat Issues on the main repo as actionable items we want to get done. This also means that we welcome PRs for any
Issue that has been labeled either "Bug", "Improvement", or "New Feature". Labeled issues are bugs or new features that
have been triaged, accepted, and are ready to be implemented.

#### Implementing Features

With the continuous growth of Directus, more and more people are relying on Directus for (critical) data workloads in
various use cases. This means we need to be careful with any changes that might affect the stability, security,
performance, or scalability of Directus. For this reason, it's important that any new feature is properly thought
through and discussed before being implemented.

Before you start writing code to implement your new feature idea, please read through and understand our triaging
process for new features before diving in. While we encourage and appreciate every code contribution, please understand
that we can't merge every suggested code change.

##### Triaging Process

Feature Request Discussions that are deemed ready to be implemented with the discussed implementation details are marked
"Accepted" and converted into an Issue, at which point the feature is ready to be implemented.

New feature ideas reported directly to issues might be converted into a Discussion for further triaging at
[the core team](https://github.com/orgs/directus/people)'s discretion first. This is often due to a lack of detail, or
lack of proven interest.

Each Pull Request that comes in is required to resolve [an open Issue](https://github.com/directus/directus/issues) that
is labeled "Bug", "Improvement", or "New Feature". This ensures that any code change made implements a known actionable
item, be it a feature or otherwise.

### Reporting Security Vulnerabilities

If you believe you have discovered a security issue within a Directus product or service, please reach out to us
directly over email: [security@directus.io](mailto:security@directus.io). We will then open a
[GitHub Security Advisory](https://github.com/directus/directus/security/advisories) for tracking the fix.

We value the members of the independent security research community who find security vulnerabilities and work with our
team so that proper fixes can be issued to users. Our policy is to credit all researchers in the fix's release notes. In
order to receive credit, security researchers must follow responsible disclosure practices, including:

- They do not publish the vulnerability prior to the Directus team releasing a fix for it
- They do not divulge exact details of the issue, e.g., through exploits or proof-of-concepts
