Skip to content
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

Migrate contributor docs into actual docs #779

Closed
obestwalter opened this issue Mar 24, 2018 · 2 comments
Closed

Migrate contributor docs into actual docs #779

obestwalter opened this issue Mar 24, 2018 · 2 comments
Labels
area:documentation help:wanted Issues that have been acknowledged, a solution determined and a PR might likely be accepted.
Milestone

Comments

@obestwalter
Copy link
Member

obestwalter commented Mar 24, 2018

There is a lot of valuable contributor documentation in https://github.com/tox-dev/tox/blob/master/CONTRIBUTING.rst - I feel most of this should rather live in the actual docs and only be references in that file to improve visibility.

@obestwalter obestwalter added area:documentation level:easy rought estimate that this might be quite easy to implement labels Mar 24, 2018
@obestwalter
Copy link
Member Author

Also as @The-Compiler pointed out, GH added a feature recently to set label descriptions, so those should go there:

Team members can review code and merge PRs. They can also label issues and change their status.

Issue labels
^^^^^^^^^^^^

Short overview about how labels should be used:

bugs:

  • bug:minor -> does not affect many people or has no big impact
  • bug:normal -> affects many people or has quite an impact
  • bug:critical -> bad, bad thing (e.g. security or can cause data loss). Should be fixed as soon as possible
  • bug:upstream -> something does not behave as it should, but can't or shouldn't be fixed in tox, but in a project tox depends on (e.g. pluggy, virtualenv, pip). Will be left open until the upstream bug is fixed for better visibility. Ideally we have an xfailing reproducer so we noticed automatically noticed if the bug is fixed (e.g. see Add regression test for upstream virtualenv bug #553)

features:

  • feature:new -> something does not exist yet, but should
  • feature:change -> something exists already but should behave differently
  • feature:deprecate -> something already exists, but shouldn't really :)

types:

  • type:internal -> should have no impact on the user (refactoring, infrastructure, tools, etc.)
  • type:organization -> has to do with the organization of the project (process)
  • type:invalid -> not applicable - e.g. a misunderstanging about how tox works or a "bug" that is actually a feature. This could cleared up right in the issue.
  • type:question -> not a bug or feature request, more of a question about how things work or if something is a bug or a feature

levels:

easy, medium and hard

A completely from the hip gut feeling estimation of how hard something is to fix or implement, basing on size of necessary changes and necessary knowledge of the tox code base and its surrounding ecosystem.

@gaborbernat gaborbernat added this to the 3.5 milestone Sep 18, 2018
@gaborbernat gaborbernat modified the milestones: 3.5, 3.6 Oct 8, 2018
@gaborbernat gaborbernat modified the milestones: 3.6, 3.7 Dec 16, 2018
@gaborbernat gaborbernat added help:wanted Issues that have been acknowledged, a solution determined and a PR might likely be accepted. and removed level:easy rought estimate that this might be quite easy to implement labels May 3, 2019
@gaborbernat
Copy link
Member

This has been done with tox 4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:documentation help:wanted Issues that have been acknowledged, a solution determined and a PR might likely be accepted.
Projects
None yet
Development

No branches or pull requests

2 participants