vis.js is a dynamic, browser-based visualization library
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

106 lines
4.5 KiB

  1. # How we use Github labels
  2. *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.*
  3. *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.*
  4. ## Issue Types
  5. If an issue was created it MUST always be labeled as one of the following issue types:
  6. ### `Question`
  7. The author has a general or very specific question.<br>
  8. 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>
  9. Specific question or hard problems should stay open.<br>
  10. Questions should be closed within 3 months.
  11. ### `Problem`
  12. This issues points to a potential bug that needs to be confirmed.<br>
  13. If the problem most likely originates from the user's code it should be labeled as [`Question`](#question) instead.<br>
  14. The support team should try to reproduce this issue and then close it or mark it as [`Confirmed Bug`](#confirmed-bug).
  15. ### `Confirmed Bug`
  16. This issue was reported as [`Problem`](#problem), but the issue is reproducible and is now a confirmed bug.
  17. ### `Feature-Request`
  18. This issue proposes a new feature or a change of existing functionality. Issues that are unlikely to get implemented should be closed.
  19. ### `wontfix`
  20. This issues is e.g. for discussing a topic or for project management purposes, and is not handled in the usual issue process.
  21. ## Graph type
  22. All issues MUST have one of the following type labels. These labels are usually mutually exclusive:
  23. ### `DataSet`
  24. Concerns the DataSet implementation.
  25. ### `Graph2D`
  26. Concerns the 2D-Graph implementation.
  27. ### `Graph3D`
  28. Concerns the 3D-Graph implementation.
  29. ### `Network`
  30. Concerns the Network-Graph implementation.
  31. ### `source/non-public API`
  32. This issues is just for discussion or is concerning the build-process, the code-style or something similar.
  33. ### `Timeline`
  34. Concerns the Timeline-Graph implementation.
  35. ## Additional labels
  36. ### `Docs`
  37. This issue concerns only the documentation.<br>
  38. If an existing issue is documented wrongly this is a [`Problem`](#problem) in the component and not a [`docs`](#docs) issue.<br>
  39. This can be used for typos or requests for an improvement of the docs.
  40. ### `Duplicate`
  41. 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.
  42. ### `Fixed awaiting release`
  43. This Issue is fixed or implemented in the "develop" branch but is not released yet and therefore should be still open.<br>
  44. This issues should be closed after the changes are merged into the "master" branch.
  45. ### `For everyone!`
  46. This is a good issue to start working on if you are new to vis.js and want to help.<br>
  47. This label is also used for labels that may concern a lot of vis.js users.
  48. ### `IE / Edge`
  49. These issues concern a problem with the Microsoft Internet Explorer or Edge browser.<br>
  50. ### `invalid`
  51. This is not a valid issue.<br>
  52. Someone just created an empty issue, picked the wrong project or something similar.<br>
  53. This can also be used for pull-request to a non-develop branch or something similar.<br>
  54. This issue or pull request should be closed immediately.
  55. ### `Issue Inactive`
  56. Issues marked as [`Question`](#question) or [`Problem`](#problem) get marked as inactive when the author is not responsive or the topic is old.<br>
  57. If an issue is marked as inactive for about 2 weeks it can be closed without any hesitation.
  58. ### `PRIORITY`
  59. In general this is used for major bugs. There should only exist a few issues marked as PRIORITY at the same time.<br>
  60. These issues need to be handled before all others.
  61. ### `Requires breaking change`
  62. 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 :-)
  63. ### `waiting for answer/improvement`
  64. This is mostly used for pull requests were a reviewer requested some changes and the owner has not responded yet.
  65. ### `Work In Progress`
  66. Someone is working on this issue or a pull request already exists and needs to be reviewed.<br>
  67. ## Example Workflows
  68. ### Bug
  69. [`Problem`](#Problem) ⟶ [`Confirmed Bug`](#confirmed-bug) ⟶ [`Work In Progress`](#work-in-progress) ⟶ [`Fixed awaiting release`](#fixed-awaiting-release)
  70. ### Feature-Request
  71. [`Feature-Request`](#feature-request) ⟶ [`Work In Progress`](#work-in-progress) ⟶ [`Fixed awaiting release`](#fixed-awaiting-release)