From b7c5cbc71b25cfaa8413a99cdc77bb21ab7ae96e Mon Sep 17 00:00:00 2001 From: Julien Danjou Date: Thu, 4 Apr 2019 19:03:15 -0400 Subject: [PATCH] Add contributing guidelines --- README.md | 3 ++ docs/contributing.rst | 87 +++++++++++++++++++++++++++++++++++++++++++ docs/index.rst | 1 + 3 files changed, 91 insertions(+) create mode 100644 docs/contributing.rst diff --git a/README.md b/README.md index 5b1b88c9ad8..190a7971fd6 100644 --- a/README.md +++ b/README.md @@ -27,6 +27,9 @@ documentation][visualization docs]. ## Development +### Contributing + +See [docs/contributing.rst](docs/contributing.rst). ### Testing diff --git a/docs/contributing.rst b/docs/contributing.rst new file mode 100644 index 00000000000..d7e8af6121a --- /dev/null +++ b/docs/contributing.rst @@ -0,0 +1,87 @@ +============== + Contributing +============== + +When contributing to this repository, we advise you to discuss the change you +wish to make via an `issue `_. + +Branches +======== + +Developement happens in the `master` branch. When all the features for the next +milestone are merged, the next version is released and tagged on the `master` +branch as `vVERSION`. + +Your pull request should targets the `master` branch. + +Once a new version is released, a `release/VERSION` branch might be created to +support micro releases to `VERSION`. Patches should be cherry-picking from the +`master` branch where possible — or otherwise created from scratch. + + +Pull Request Process +==================== + +In order to be merged, a pull request needs to meet the following +conditions: + +1. The test suite must pass. +2. One of the repository Members must approve the pull request. +3. Proper unit and integration testing must be implemented. +4. Proper documentation must be written. + +Splitting Pull Requests +======================= + +If you discussed your feature within an issue (as advised), there's a great +chance that the implementation appears doable in several steps. In order to +facilite the review process, we strongly advise to split your feature +implementation in small pull requests (if that is possible) so they contain a +very small number of commits (a single commit per pull request being optimal). + +That ensures that: + +1. Each commit passes the test suite. +2. The code reviewing process done by humans is easier as there is less code to + understand at a glance. + +Internal API +============ + +The `ddtrace.internal` module contains code that must only be used inside +`ddtrace` itself. Relying on the API of this module is dangerous and can break +at anytime. Don't do it. + +Python Versions and Implementations Support +=========================================== + +The following Python implementations are supported: + +- CPython + +Versions of those implementations that are supported are the Python versions +that are currently supported by the community. + +Libraries Support +================= + +External libraries support is implemented in submodules of the `ddtest.contrib` +module. + +Our goal is to support: + +- The latest version of a library. +- All versions of a library that have been released less than 1 year ago. + +Support for older versions of a library will be kept as long as possible as +long as it can be done without too much pain and backward compatibility — on a +best effort basis. Therefore, support for old versions of a library might be +dropped from the testing pipeline at anytime. + +Code Style +========== + +The code style is enforced by `flake8 `_, its +configuration, and possibly extensions. No code style review should be done by +a human. All code style enforcement must be automatized to avoid bikeshedding +and losing time. diff --git a/docs/index.rst b/docs/index.rst index 19ba83b02ba..8ce7ae26097 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -141,3 +141,4 @@ Indices and tables other_integrations basic_usage advanced_usage + contributing