This repository was archived by the owner on Jul 29, 2019. It is now read-only.
added documentation on how labels are used #2873
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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` | ||
|
There was a problem hiding this comment. I'd like to be more specific about this. It doesn't matter how much vis.js code, it matters if it breaks user code. There was a problem hiding this comment. I don't like this label! Maybe we can get rid of it and replace it with something else? See also #2895 for more discussion. |
||
| 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 | ||
|
There was a problem hiding this comment. Love it! I'd like to see the following or similar here as well (where 'Close' is not a label): No responseFeature Request -> Issue Inactive -> Close There was a problem hiding this comment. FYI, I don't see this as required; I'm quite happy with the changes you made. |
||
|
|
||
| ### 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) | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we also want to make "wontfix" for cases where there was a potentially valid code change (feature request), but the outcome was to not change anything? Or is that handled by a "Feature-Request" that is closed without an associated code change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thinks this would be better handled with a "Feature-Request". The "Wontfix" lasbel is used at the moment to mark something like "management" issues that don't fall in any of the other categories.