added documentation on how labels are used #2873

mojoaxel · 2017-03-18T12:31:11Z

This is meant as a basis for discussion and improvement.

Tooa

Just typo issues.

Tooa · 2017-03-18T17:48:42Z

misc/labels.md

@@ -0,0 +1,99 @@
+# How we use github labels


Tooa · 2017-03-18T17:49:17Z

misc/labels.md

@@ -0,0 +1,99 @@
+# How we use github labels
+
+*Because only team-mermbers can add and change labels this document is mainly for maintainers, but also for users to understand how we use labels.*


team-members -> team members

Tooa · 2017-03-18T17:49:35Z

misc/labels.md

+
+*Because only team-mermbers 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 to be able to export them later r.g. if the project gets separated into multiple components.*


to be able to -> in order to export

Tooa · 2017-03-18T17:51:09Z

misc/labels.md

+
+
+## Issue Types
+If an issue was created it always MUST be labeled as one of the following issue types:


always must -> must always

Tooa · 2017-03-18T17:55:47Z

misc/labels.md

+
+### `Question`
+The author has a general or very specific question.<br>
+If it is a general question how to use vis.js the issues should be closed immediately with a reference to [stackoverflow](https://stackoverflow.com/questions/tagged/vis.js).<br>


question about how (?)

I would change sentence order:

The issue should be closed immediately with a reference to [stackoverflow] when it is a general question [...]

Tooa · 2017-03-18T18:15:26Z

misc/labels.md

+
+### `PRIORITY`
+Normally this is used for major Bugs. There should only exist one or two issues marked as PRIORITY at the same time.<br>
+This issues need to be handled before all others.


This -> These

Tooa · 2017-03-18T18:16:26Z

misc/labels.md

+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 :-)
+
+### `invalid`
+This is a non-issue.<br>


This is not an issue?

What is a non-issue ?

Tooa · 2017-03-18T18:16:55Z

misc/labels.md

+
+### `invalid`
+This is a non-issue.<br>
+Maybe somebody just created an empty issue, picked the wrong project or something like this.<br>


Remove Maybe

something like this -> or something similar

somebody -> someone

(more formally)

Tooa · 2017-03-18T18:19:47Z

misc/labels.md

+This is a non-issue.<br>
+Maybe somebody just created an empty issue, picked the wrong project or something like this.<br>
+This can also be used for pull-request to a non-develop branch oder something similar.<br>
+This issue or PR should be closed immediately.


Either pull-request or pull request. Or pull request (PR) in the first place and then PR.

Tooa · 2017-03-18T18:20:46Z

misc/labels.md

+This issue or PR should be closed immediately.
+
+### `waiting for answer/improvement`
+This is mostly used for pull-requests were a review requested some change and the owner is not answering.


were a reviewer requested some changes

mojoaxel · 2017-03-18T21:56:58Z

@Tooa Thx! English is not my strong suit

mojoaxel · 2017-03-21T10:32:42Z

@Tooa Thanks again!

wimrijnders · 2017-03-22T16:05:27Z

misc/labels.md


 ### `Feature-Request`
-This issue proposes a new feature or a change of existing functionality. Issues that are very very unlikely to get implemented should be closed.<br>
+This issue proposes a new feature or a change of existing functionality. Issues that are unlikely to get implemented should be closed.<br>


Closed when? I would expect an expiration period here, just like with Question.

No. This depends very much on the topic and the state of the discussion.

wimrijnders · 2017-03-22T16:08:10Z

misc/labels.md

-Issues marked as `question` or `problem` get marked as inactive if the author is not responsive or the topic is old.<br>
-If an issues is marked as inactive for about 2 weeks it can be closed without any hesitation.
+Issues marked as `question` or `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.


Expiration period again; how long should be wait to mark an issue as Inactive?

it depends... 😉

wimrijnders · 2017-03-22T16:15:50Z

misc/labels.md

+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 :-)


My definition of 'breaking change' is: 'requires users to change something in their own code to use this'. Hence, something in the outer API has changed.

The given description implies that it's 'a lot of work', i.e. in general internal stuff. I don't agree this is the good description.

I would rather see distinct labels for these. If you want to keep 'Requires breaking change' as is, I would suggest e.g. 'Breaking change in API' for the former description.

My definition of 'breaking change' is: 'requires users to change something in their own code to use this'. Hence, something in the outer API has changed.

Yes! This is also my opinion.

I would rather see distinct labels for these. If you want to keep 'Requires breaking change' as is, I would suggest e.g. 'Breaking change in API' for the former description.

Very good point. Lets's discuss this, further!

Maybe we can merge this and discuss in an seperate issue if we want to introduce 'Major', 'Minor', 'Patch' labels for Pull-Requests. (Instead of the old "Breaking change label).

@wimrijnders Can you open a new issue for that discussion please.

wimrijnders · 2017-03-22T16:16:44Z

misc/labels.md

-Maybe somebody just created an empty issue, picked the wrong project or something like this.<br>
+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 oder something similar.<br>


'oder' -> 'or'

wimrijnders · 2017-03-22T16:32:07Z

misc/labels.md

-The support-Team should try to reproduce this issue and than close it or mark it as `Confirmed Bug`:<br>
+If the problem most likely originates from the user's code it should be better labeled as `Question`.<br>
+The support team should try to reproduce this issue and then close or mark it as `Confirmed Bug`:<br>
 `Problem` -> `Confirmed Bug` --> `Work In Progress` --> `Fixed awaiting release`


I really like these label 'graphs'; they clarify the workflow.

Only, I would prefer to have these bundled together in their own section, also because they mention several labels, not just one. Perhaps a section at the top of the document with title 'Overview' or at the bottom with title 'Workflow'.

Ideally, the labels would be clickable, so that you can just jump to the label description.

wimrijnders · 2017-03-22T16:35:33Z

misc/labels.md


 ### `waiting for answer/improvement`
-This is mostly used for pull-requests were a review requested some change and the owner is not answering.
+This is mostly used for pull requests were a reviewer requested some changes and the owner has not responded yet.


Again, how long to wait before it becomes Inactive?

At the moment we just leave these PRs open. Maybe somebody will pick them up at some point!?

wimrijnders · 2017-03-22T16:42:52Z

misc/labels.md


 ## Graph type
-All issues MUST have one of the following type-labels. This labels usually are usually mutually exclusive:
+All issues MUST have one of the following type labels. These labels are usually mutually exclusive:


Nitpicking: Could the labels be sorted alphabetically, please?

I see what I can do...

You did all lists and and you added links everywhere to labels! 👍

wimrijnders · 2017-03-22T16:44:16Z

misc/labels.md

@@ -1,39 +1,39 @@
-# How we use github labels
+# How we use Github labels


Nitpicking: the proper name is GitHub.

GitHub?

But never mind; it's not really important.

wimrijnders · 2017-03-22T16:46:24Z

misc/labels.md

-If the problem is probably in the users code it should be better labeled as `Question`.<br>
-The support-Team should try to reproduce this issue and than close it or mark it as `Confirmed Bug`:<br>
+If the problem most likely originates from the user's code it should be better labeled as `Question`.<br>
+The support team should try to reproduce this issue and then close or mark it as `Confirmed Bug`:<br>


'then close it or...'

wimrijnders · 2017-03-22T16:53:02Z

misc/labels.md

 ### `PRIORITY`
-Normally this is used for major Bugs. There should only exist one or two issues marked as PRIORITY at the same time.<br>
-This issues need to be handled before all others.
+In general this is used for major bugs. There should only exist one or two issues marked as PRIORITY at the same time.<br>


There should only exist one or two issues marked as PRIORITY at the same time.

How can you control this? I would think it is possible that there are more PRIORITY issues pending than just two.
This text implies a bit that a maximum of 2 PRIORITY labels will be assigned.

I would suggest a rewording: 'The directive is to have at most one or .....'.

mojoaxel · 2017-03-22T21:39:09Z

@wimrijnders @Tooa done!

wimrijnders · 2017-03-23T17:09:16Z

misc/labels.md

+### `Work In Progress`
+Someone is working on this issue or a pull request already exists and needs to be reviewed.<br>
+
+## Example Workflows


Love it!

I'd like to see the following or similar here as well (where 'Close' is not a label):

No response

Feature Request -> Issue Inactive -> Close

FYI, I don't see this as required; I'm quite happy with the changes you made.

wimrijnders · 2017-03-23T17:10:14Z

misc/labels.md


 ### `Feature-Request`
-This issue proposes a new feature or a change of existing functionality. Issues that are very very unlikely to get implemented should be closed.<br>
+This issue proposes a new feature or a change of existing functionality. Issues that are unlikely to get implemented should be closed.<br>


bradh · 2017-03-25T23:38:47Z

misc/labels.md

+
+### `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 better labeled as [`Question`](#question).<br>


Instead of "better", just put "instead" on the end of the sentence.

bradh · 2017-03-25T23:41:33Z

misc/labels.md

+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.


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?

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.

bradh · 2017-03-25T23:42:41Z

misc/labels.md

+### `DataSet`
+Concerns the DataSet implementation.
+
+### `Docs`


I don't think Docs is mutually exclusive with the other areas, and should be described somewhere else.

I'll move it to "Additional Labels"

bradh · 2017-03-25T23:43:56Z

misc/labels.md

+
+### `Fixed awaiting release`
+This Issues 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 if after the changes are merged into the "master" branch.


"issues" should be singular ("issue").
Remove "if".

bradh · 2017-03-25T23:46:02Z

misc/labels.md

+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`


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.

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.

mojoaxel · 2017-04-11T20:20:59Z

@bradh @Tooa I think this is ready to be merged for now. It still can be improved later, if necessary.

17 days no answer; propably busy.

added documentation on how labels are used

fb07158

mojoaxel requested review from Tooa, bradh, eymiha and yotamberk March 18, 2017 12:31

mojoaxel added Docs Feature-Request labels Mar 18, 2017

mojoaxel added this to the Minor Release v4.20 milestone Mar 18, 2017

Tooa previously requested changes Mar 18, 2017

View reviewed changes

yotamberk and others added 4 commits March 19, 2017 00:05

Merge branch 'develop' into labels

4771926

added documentation on how labels are used

4c10314

Merge branch 'labels' of github.com:almende/vis into labels

6330ab2

applied change requests

25dc017

mojoaxel requested a review from wimrijnders March 21, 2017 15:27

wimrijnders suggested changes Mar 22, 2017

View reviewed changes

mojoaxel and others added 2 commits March 22, 2017 22:10

Merge branch 'develop' into labels

fb92ac2

change requests from @wimrijnders

3e93b37

wimrijnders reviewed Mar 23, 2017

View reviewed changes

Merge branch 'develop' into labels

5179f0f

yotamberk approved these changes Mar 24, 2017

View reviewed changes

wimrijnders approved these changes Mar 24, 2017

View reviewed changes

bradh reviewed Mar 25, 2017

View reviewed changes

yotamberk and others added 5 commits April 1, 2017 23:34

Merge branch 'develop' into labels

b41b80d

added documentation on how labels are used

01e807b

applied change requests

43ddda6

change requests from @wimrijnders

31c71c1

Merge branch 'labels' of github.com:almende/vis into labels

4ca6776

mojoaxel and others added 3 commits April 11, 2017 22:08

changes requested by @bradh

599d6cc

Merge branch 'develop' into labels

d19b816

Merge branch 'develop' into labels

f187261

mojoaxel and others added 2 commits April 15, 2017 17:00

Merge branch 'develop' into labels

30c0d3c

Merge branch 'develop' into labels

c9e2070

mojoaxel and others added 2 commits April 28, 2017 10:50

Merge branch 'develop' into labels

26522f5

Merge branch 'develop' into labels

2420ca4

yotamberk merged commit 6bffd49 into develop Apr 30, 2017

mojoaxel deleted the labels branch January 30, 2019 19:06

		@@ -0,0 +1,99 @@
		# How we use github labels

		Because only team-mermbers can add and change labels this document is mainly for maintainers, but also for users to understand how we use labels.


		Because only team-mermbers 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 to be able to export them later r.g. if the project gets separated into multiple components.



		## Issue Types
		If an issue was created it always MUST be labeled as one of the following issue types:

		@@ -1,39 +1,39 @@
		# How we use github labels
		# How we use Github labels

added documentation on how labels are used #2873

added documentation on how labels are used #2873

Uh oh!

Conversation

mojoaxel commented Mar 18, 2017

Uh oh!

Tooa left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mojoaxel commented Mar 18, 2017

Uh oh!

mojoaxel commented Mar 21, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wimrijnders Mar 22, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

wimrijnders Mar 22, 2017 •

edited

Loading