69 lines
3.6 KiB
Markdown
69 lines
3.6 KiB
Markdown
# Contributing to detectron2
|
|
|
|
## Issues
|
|
We use GitHub issues to track public bugs and questions.
|
|
Please make sure to follow one of the
|
|
[issue templates](https://github.com/facebookresearch/detectron2/issues/new/choose)
|
|
when reporting any issues.
|
|
|
|
Facebook has a [bounty program](https://www.facebook.com/whitehat/) 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:
|
|
|
|
1. 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](https://github.com/facebookresearch/detectron2/tree/master/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.
|
|
2. 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 in `projects/README.md`.
|
|
3. 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.
|
|
4. Whether the proposed solution adds extra mental/practical overhead to users who don't
|
|
need such feature.
|
|
5. 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:
|
|
|
|
1. It does not involve modifying or potentially breaking existing code.
|
|
2. It does not add overhead to users who do not need the new feature.
|
|
3. 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:
|
|
|
|
1. If a PR contains multiple orthogonal changes, split it to several PRs.
|
|
2. If you've added code that should be tested, add tests.
|
|
3. 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.
|
|
4. If APIs are changed, update the documentation.
|
|
5. We use the [Google style docstrings](https://www.sphinx-doc.org/en/master/usage/extensions/napoleon.html) in python.
|
|
6. 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.
|