From b32f4de891e217a24f02bb66a63750a36d7effac Mon Sep 17 00:00:00 2001 From: Maximilian Cosmo Sitter <48606431+mcsitter@users.noreply.github.com> Date: Sun, 31 May 2020 08:37:26 +0200 Subject: [PATCH] Issue 7202 - Point development guide to contributing section (#7280) --- changelog/7202.doc.rst | 1 + doc/en/development_guide.rst | 59 ++---------------------------------- 2 files changed, 4 insertions(+), 56 deletions(-) create mode 100644 changelog/7202.doc.rst diff --git a/changelog/7202.doc.rst b/changelog/7202.doc.rst new file mode 100644 index 000000000..143f28d40 --- /dev/null +++ b/changelog/7202.doc.rst @@ -0,0 +1 @@ +The development guide now links to the contributing section of the docs and 'RELEASING.rst' on GitHub. diff --git a/doc/en/development_guide.rst b/doc/en/development_guide.rst index 2f9762f2a..77076d483 100644 --- a/doc/en/development_guide.rst +++ b/doc/en/development_guide.rst @@ -2,59 +2,6 @@ Development Guide ================= -Some general guidelines regarding development in pytest for maintainers and contributors. Nothing here -is set in stone and can't be changed, feel free to suggest improvements or changes in the workflow. - - -Code Style ----------- - -* `PEP-8 `_ -* `flake8 `_ for quality checks -* `invoke `_ to automate development tasks - - -Branches --------- - -We have two long term branches: - -* ``master``: contains the code for the next bug-fix release. -* ``features``: contains the code with new features for the next minor release. - -The official repository usually does not contain topic branches, developers and contributors should create topic -branches in their own forks. - -Exceptions can be made for cases where more than one contributor is working on the same -topic or where it makes sense to use some automatic capability of the main repository, such as automatic docs from -`readthedocs `_ for a branch dealing with documentation refactoring. - -Issues ------- - -Any question, feature, bug or proposal is welcome as an issue. Users are encouraged to use them whenever they need. - -GitHub issues should use labels to categorize them. Labels should be created sporadically, to fill a niche; we should -avoid creating labels just for the sake of creating them. - -Each label should include a description in the GitHub's interface stating its purpose. - -Labels are managed using `labels `_. All the labels in the repository -are kept in ``.github/labels.toml``, so any changes should be via PRs to that file. -After a PR is accepted and merged, one of the maintainers must manually synchronize the labels file with the -GitHub repository. - -Temporary labels -~~~~~~~~~~~~~~~~ - -To classify issues for a special event it is encouraged to create a temporary label. This helps those involved to find -the relevant issues to work on. Examples of that are sprints in Python events or global hacking events. - -* ``temporary: EP2017 sprint``: candidate issues or PRs tackled during the EuroPython 2017 - -Issues created at those events should have other relevant labels added as well. - -Those labels should be removed after they are no longer relevant. - - -.. include:: ../../RELEASING.rst +The contributing guidelines are to be found :ref:`here `. +The release procedure for pytest is documented on +`GitHub `_.