We want to make contributing to this project as easy and transparent as possible.
Facebook has adopted a Code of Conduct that we expect project participants to adhere to. Please read the full text so that you can understand what actions will and will not be tolerated.
We use GitHub to sync code to and from our internal repository. We'll use GitHub to track issues and feature requests, as well as accept pull requests.
We actively welcome your pull requests.
- Fork the repo and create your branch from
master
. - If you've added code that should be tested, add tests.
- If you've changed APIs, update the documentation.
- Ensure the test suite passes.
- Make sure your code lints.
- If you haven't already, complete the Contributor License Agreement ("CLA").
In order to accept your pull request, we need you to submit a CLA. You only need to do this once to work on any of Facebook's open source projects.
Complete your CLA here: https://code.facebook.com/cla
- 2 spaces for indentation rather than tabs
- 80 character line length
- Run
npm run lint
to conform to our lint rules
We use GitHub issues to track public bugs. Please ensure your description is clear and has sufficient instructions to be able to reproduce the issue. If possible please provide a minimal demo of the problem. You can use this jsfiddle to get started: https://jsfiddle.net/stopachka/m6z0xn4r/.
Facebook has a bounty program for the safe disclosure of security bugs. In those cases, please go through the process outlined on that page and do not file a public issue.
Here are some tags that we're using to better organize issues in this repo:
good first issue
- Good candidates for someone new to the project to contribute.help wanted
- Issues that should be addressed and which we would welcome a PR for but may need significant investigation or worksupport
- Request for help with a concept or piece of code but this isn't an issue with the project.needs more info
- Missing repro steps or context for both project issues & support questions.discussion
- Issues where folks are discussing various approaches & ideas.question
- Something that is a question specifically for the maintainers such as this issue about the license.documentation
- Relating to improving documentation for the project.
- Browser & OS-specific tags for anything that is specific to a particular
environment (e.g.
chrome
,firefox
,macos
,android
and so forth).
Our philosophy regarding API changes is as follows:
- We will avoid changing APIs and core behaviors in general
- In order to avoid stagnation we will allow for API changes in cases where there is no other way to achieve a high priority bug fix or improvement.
- When there is an API change:
- Changes will have a clearly documented reason and migration path
- When deprecating a pattern, these steps will be followed:
- We will test the change internally first at FB
- A version will be released that supports both, with deprecation warnings
- The following version will fully remove the deprecated pattern
By contributing to Draft.js, you agree that your contributions will be licensed under its MIT license.