Contributing to detectron2
Issues
We use GitHub issues to track public bugs and questions. Please make sure to follow one of the issue templates when reporting any issues.
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.
Pull Requests
We actively welcome pull requests.
However, if you're adding any significant features (e.g. > 50 lines), please make sure to discuss with maintainers about your motivation and proposals in an issue before sending a PR. This is to save your time so you don't spend time on a PR that we'll not accept.
We do not always accept new features, and we take the following factors into consideration:
- Whether the same feature can be achieved without modifying detectron2.
Detectron2 is designed so that you can implement many extensions from the outside, e.g.
those in projects.
- If some part of detectron2 is not extensible enough, you can also bring up a more general issue to improve it. Such feature request may be useful to more users.
- Whether the feature is potentially useful to a large audience (e.g. an impactful detection paper, a popular dataset,
a significant speedup, a widely useful utility),
or only to a small portion of users (e.g., a less-known paper, an improvement not in the object
detection field, a trick that's not very popular in the community, code to handle a non-standard type of data)
- Adoption of additional models, datasets, new task are by default not added to detectron2 before they
receive significant popularity in the community.
We sometimes accept such features in
projects/, or as a link inprojects/README.md.
- Adoption of additional models, datasets, new task are by default not added to detectron2 before they
receive significant popularity in the community.
We sometimes accept such features in
- Whether the proposed solution has a good design / interface. This can be discussed in the issue prior to PRs, or in the form of a draft PR.
- Whether the proposed solution adds extra mental/practical overhead to users who don't need such feature.
- Whether the proposed solution breaks existing APIs.
To add a feature to an existing function/class Func, there are always two approaches:
(1) add new arguments to Func; (2) write a new Func_with_new_feature.
To meet the above criteria, we often prefer approach (2), because:
- It does not involve modifying or potentially breaking existing code.
- It does not add overhead to users who do not need the new feature.
- Adding new arguments to a function/class is not scalable w.r.t. all the possible new research ideas in the future.
When sending a PR, please do:
- If a PR contains multiple orthogonal changes, split it to several PRs.
- If you've added code that should be tested, add tests.
- For PRs that need experiments (e.g. adding a new model or new methods), you don't need to update model zoo, but do provide experiment results in the description of the PR.
- If APIs are changed, update the documentation.
- We use the Google style docstrings in python.
- Make sure your code lints with
./dev/linter.sh.
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
License
By contributing to detectron2, you agree that your contributions will be licensed under the LICENSE file in the root directory of this source tree.