<td>If true, items with titles will display a tooltip. If false, item tooltips are prevented from showing.</td>
</tr>
<tr>
<tr>
<td>stack</td>
<td>stack</td>
<td>boolean</td>
<td>boolean</td>
@ -1044,7 +1053,7 @@ function (option, path) {
<td>function</td>
<td>function</td>
<td>When moving items on the Timeline, they will be snapped to nice dates like full hours or days, depending on the current scale. The <code>snap</code> function can be replaced with a custom function, or can be set to <code>null</code> to disable snapping. The signature of the snap function is:
<td>When moving items on the Timeline, they will be snapped to nice dates like full hours or days, depending on the current scale. The <code>snap</code> function can be replaced with a custom function, or can be set to <code>null</code> to disable snapping. The signature of the snap function is:
<preclass="prettyprint lang-js">function snap(date: Date, scale: string, step: number) : Date or number</pre>
<preclass="prettyprint lang-js">function snap(date: Date, scale: string, step: number) : Date or number</pre>
The parameter <code>scale</code> can be can be 'millisecond', 'second', 'minute', 'hour', 'weekday, 'day, 'month, or 'year'. The parameter <code>step</code> is a number like 1, 2, 4, 5.
The parameter <code>scale</code> can be can be 'millisecond', 'second', 'minute', 'hour', 'weekday, 'week', 'day, 'month, or 'year'. The parameter <code>step</code> is a number like 1, 2, 4, 5.
</td>
</td>
</tr>
</tr>
@ -1088,10 +1097,11 @@ function (option, path) {
<tdclass="indent">timeAxis.scale</td>
<tdclass="indent">timeAxis.scale</td>
<td>String</td>
<td>String</td>
<td>none</td>
<td>none</td>
<td>Set a fixed scale for the time axis of the Timeline. Choose from <code>'millisecond'</code>, <code>'second'</code>, <code>'minute'</code>, <code>'hour'</code>, <code>'weekday'</code>, <code>'day'</code>, <code>'month'</code>, <code>'year'</code>. Example usage:
<td>Set a fixed scale for the time axis of the Timeline. Choose from <code>'millisecond'</code>, <code>'second'</code>, <code>'minute'</code>, <code>'hour'</code>, <code>'weekday'</code>, <code>'week'</code>, <code>'day'</code>, <code>'month'</code>, <code>'year'</code>. Example usage:
<preclass="prettyprint lang-js">var options = {
<preclass="prettyprint lang-js">var options = {
timeAxis: {scale: 'minute', step: 5}
timeAxis: {scale: 'minute', step: 5}
}</pre>
}</pre>
<p>Note: The 'week' scale only works properly when <ahref="#Localization">locales</a> are enabled.</p>
Note: the 'week' scale is not included in the automatic zoom levels as its scale is not a direct logical successor of 'days' nor a logical predecessor of 'months'
*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>