4.5 KiB
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.
If it is a general question on how to use vis.js the issues should be closed immediately with a reference to stackoverflow.
Specific question or hard problems should stay open.
Questions should be closed within 3 months.
Problem
This issues points to a potential bug that needs to be confirmed.
If the problem most likely originates from the user's code it should be labeled as Question instead.
The support team should try to reproduce this issue and then close it or mark it as Confirmed Bug.
Confirmed Bug
This issue was reported as 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.
If an existing issue is documented wrongly this is a Problem in the component and not a docs issue.
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.
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.
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.
invalid
This is not a valid issue.
Someone just created an empty issue, picked the wrong project or something similar.
This can also be used for pull-request to a non-develop branch or something similar.
This issue or pull request should be closed immediately.
Issue Inactive
Issues marked as Question or Problem get marked as inactive when the author is not responsive or the topic is old.
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.
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.
Example Workflows
Bug
Problem ⟶ Confirmed Bug ⟶ Work In Progress ⟶ Fixed awaiting release