Skip to content

Issue 7202 - Point development guide to contributing section #7280

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
May 31, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions changelog/7202.doc.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
The development guide now links to the contributing section of the docs and 'RELEASING.rst' on GitHub.
59 changes: 3 additions & 56 deletions doc/en/development_guide.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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 <https://www.python.org/dev/peps/pep-0008>`_
* `flake8 <https://pypi.org/project/flake8/>`_ for quality checks
* `invoke <http://www.pyinvoke.org/>`_ 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 <readthedocs.org>`_ 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 <https://github.com/hackebrot/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 <contributing>`.
The release procedure for pytest is documented on
`GitHub <https://github.com/pytest-dev/pytest/blob/master/RELEASING.rst>`_.