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 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.
The Directus Code of Conduct 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.
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.
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
The 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!
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 or GitHub Discussions is a great way to help the project.
Issues marked "Community" are ready to be implemented by anybody at any point! If you're looking to implement an issue that doesn't have that label, please make sure to ping the maintainers before getting started!
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
To properly generate changelogs and determine the right version number after a change is merged, we rely on changesets. Each PR should include a changeset that describes whether the change is a patch/minor/major version bump, and describe what the change is.
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.
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.
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'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 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.
If you believe you have discovered a security issue within a Directus product or service, please reach out to us directly over email: [email protected]. We will then open a GitHub Security Advisory 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