vendor/detectron2/.github/CONTRIBUTING.md

# 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.