Browse Source

added documentation on how labels are used (#2873)

* added documentation on how labels are used

* added documentation on how labels are used

* applied change requests

* change requests from @wimrijnders

* added documentation on how labels are used

* applied change requests

* change requests from @wimrijnders

* changes requested by @bradh
gemini
Alexander Wunschik 6 years ago
committed by yotamberk
parent
commit
6bffd4921a
1 changed files with 106 additions and 0 deletions
  1. +106
    -0
      misc/labels.md

+ 106
- 0
misc/labels.md View File

@ -0,0 +1,106 @@
# How we use Github labels
*Because only team members can add and change labels this document is mainly for maintainers, but also for users to understand how we use labels.*
*It is important to also label old and closed issues uniformly in order to export them later e.g. if the project gets separated into multiple components.*
## Issue Types
If an issue was created it MUST always be labeled as one of the following issue types:
### `Question`
The author has a general or very specific question.<br>
If it is a general question on how to use vis.js the issues should be closed immediately with a reference to [stackoverflow](https://stackoverflow.com/questions/tagged/vis.js).<br>
Specific question or hard problems should stay open.<br>
Questions should be closed within 3 months.
### `Problem`
This issues points to a potential bug that needs to be confirmed.<br>
If the problem most likely originates from the user's code it should be labeled as [`Question`](#question) instead.<br>
The support team should try to reproduce this issue and then close it or mark it as [`Confirmed Bug`](#confirmed-bug).
### `Confirmed Bug`
This issue was reported as [`Problem`](#problem), but the issue is reproducible and is now a confirmed bug.
### `Feature-Request`
This issue proposes a new feature or a change of existing functionality. Issues that are unlikely to get implemented should be closed.
### `wontfix`
This issues is e.g. for discussing a topic or for project management purposes, and is not handled in the usual issue process.
## Graph type
All issues MUST have one of the following type labels. These labels are usually mutually exclusive:
### `DataSet`
Concerns the DataSet implementation.
### `Graph2D`
Concerns the 2D-Graph implementation.
### `Graph3D`
Concerns the 3D-Graph implementation.
### `Network`
Concerns the Network-Graph implementation.
### `source/non-public API`
This issues is just for discussion or is concerning the build-process, the code-style or something similar.
### `Timeline`
Concerns the Timeline-Graph implementation.
## Additional labels
### `Docs`
This issue concerns only the documentation.<br>
If an existing issue is documented wrongly this is a [`Problem`](#problem) in the component and not a [`docs`](#docs) issue.<br>
This can be used for typos or requests for an improvement of the docs.
### `Duplicate`
This issues is a duplicate of an existing issue. The duplicate should be closed. In addition, add a reference to the original issue with a comment.
### `Fixed awaiting release`
This Issue is fixed or implemented in the "develop" branch but is not released yet and therefore should be still open.<br>
This issues should be closed after the changes are merged into the "master" branch.
### `For everyone!`
This is a good issue to start working on if you are new to vis.js and want to help.<br>
This label is also used for labels that may concern a lot of vis.js users.
### `IE / Edge`
These issues concern a problem with the Microsoft Internet Explorer or Edge browser.<br>
### `invalid`
This is not a valid issue.<br>
Someone just created an empty issue, picked the wrong project or something similar.<br>
This can also be used for pull-request to a non-develop branch or something similar.<br>
This issue or pull request should be closed immediately.
### `Issue Inactive`
Issues marked as [`Question`](#question) or [`Problem`](#problem) get marked as inactive when the author is not responsive or the topic is old.<br>
If an issue is marked as inactive for about 2 weeks it can be closed without any hesitation.
### `PRIORITY`
In general this is used for major bugs. There should only exist a few issues marked as PRIORITY at the same time.<br>
These issues need to be handled before all others.
### `Requires breaking change`
A lot of code needs to be changed to implement this. This is maybe something for a major release or something for someone with a lot of time on their hands :-)
### `waiting for answer/improvement`
This is mostly used for pull requests were a reviewer requested some changes and the owner has not responded yet.
### `Work In Progress`
Someone is working on this issue or a pull request already exists and needs to be reviewed.<br>
## Example Workflows
### Bug
[`Problem`](#Problem) ⟶ [`Confirmed Bug`](#confirmed-bug) ⟶ [`Work In Progress`](#work-in-progress) ⟶ [`Fixed awaiting release`](#fixed-awaiting-release)
### Feature-Request
[`Feature-Request`](#feature-request) ⟶ [`Work In Progress`](#work-in-progress) ⟶ [`Fixed awaiting release`](#fixed-awaiting-release)

Loading…
Cancel
Save