# Gitlab labels improvements

**URL:** https://discourse.paraview.org/t/gitlab-labels-improvements/4275
**Category:** Development
**Created:** [May 7, 2020, 6:25am UTC](https://discourse.paraview.org/t/gitlab-labels-improvements/4275 "2020-05-07T06:25:33Z")
**Posts on this page:** 13
**Page:** 1

<div class="post-metadata">

### Author: ![mwestphal](https://discourse.paraview.org/user_avatar/discourse.paraview.org/mwestphal/32/17_2.png) [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [May 7, 2020, 6:25am UTC](https://discourse.paraview.org/t/gitlab-labels-improvements/4275/1 "2020-05-07T06:25:33Z")

</div>

In the wake of the hackathon, I’ve been thinking of the labels (tags) we are using, and I think it can be improved.

Here is the current status :  
[https://gitlab.kitware.com/paraview/paraview/-/labels](https://gitlab.kitware.com/paraview/paraview/-/labels)

Here is what I think could be improved :

1. IO labels

We currently have a single IO related label, xdmf. I think we need more in order to simplify improvements to specific readers. it could be more area:X or even a new category like io:X.

What comes to mind :

- io:xdmf
- io:openfoam
- io:netcdf
- io:exodus
- io:export (a generic one seems enough)
- io:AMReX
- io:cgns
- io:Ensight
- io:csv
- io: other (any io not covered by the other labels)

These are only suggestions.

1. More area labels

I think we should add more area labels:

- area:htg
- area:servermanager
- area:selection
- aera:animation
- area:UI
- area:plugins
- ?

Once again, these are only suggestions.

3: Lang or Skills labels

In order to help new comes, external and different background people to contribute, adding a lang or skills category would be nice. Of course, it concerns the skills needed to fix the issue in the best knowledge of the reporter (or the dev that take a quick look at the issue.

What comes to mind :

- skills:python
- skills:opengl
- skills:qt
- skills:VTK
- skills:servermanager (duplicate of the area I know, open to suggestions)
- skills:cmake ?
- skills:?

Of course, in this context, A pass to improve the description of some labels would also be good.  
Also, if the robot could show a warning to add some labels to the issue on creation it would be great (althoug I’m not sure non-paraview-project-members can actually add labels).

What do you think ? Would you use these labels ?  
Do you think these labels would help Kitwarean to fix issues and non-kitwarean to contribute more ?  
Do you have any other ideas for different labels ?

@ben.boeckel @utkarsh.ayachit @cory.quammen @Joachim_Pouderoux @Michael @nicolas.vuaille @Charles_Gueunet @wascott @Andy_Bauer @Kenneth_Moreland

---

<div class="post-metadata">

### Author: ![Michael](https://discourse.paraview.org/user_avatar/discourse.paraview.org/michael/32/16_2.png) [@Michael](https://discourse.paraview.org/u/Michael)
#### Post date: [May 7, 2020, 6:40am UTC](https://discourse.paraview.org/t/gitlab-labels-improvements/4275/2 "2020-05-07T06:40:56Z")

</div>

I like the idea of `skills` labels. We all have different expertise and would help if we can filter issues based on this.

---

<div class="post-metadata">

### Author: ![cory.quammen](https://discourse.paraview.org/user_avatar/discourse.paraview.org/cory.quammen/32/11193_2.png) [@cory.quammen](https://discourse.paraview.org/u/cory.quammen)
#### Post date: [May 7, 2020, 3:28pm UTC](https://discourse.paraview.org/t/gitlab-labels-improvements/4275/3 "2020-05-07T15:28:48Z")

</div>

I’m personally not convinced additional labels will provide many advantages. The projects and priorities labels have been useful in my experience for communicating with customers which issues to tackle next.

What will likely happen is any additional labels will not be uniformly (or even correctly) applied to issues and their utility will be minimal. As for outside contributors, they will first have to learn what the labels mean, how to search by labels, etc., so I don’t think they’ll necessarily have any effect on contributions.

---

<div class="post-metadata">

### Author: ![wascott](https://discourse.paraview.org/letter_avatar_proxy/v4/letter/w/8e8cbc/32.png) [@wascott](https://discourse.paraview.org/u/wascott)
#### Post date: [May 7, 2020, 4:16pm UTC](https://discourse.paraview.org/t/gitlab-labels-improvements/4275/4 "2020-05-07T16:16:22Z")

</div>

My first thought mirrors Cory’s. ParaView has an outside vendor that has taken years to start effectively using the bug tracker and the labels that exist. Additional complexity may not add much.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.paraview.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [May 7, 2020, 5:19pm UTC](https://discourse.paraview.org/t/gitlab-labels-improvements/4275/5 "2020-05-07T17:19:03Z")

</div>

Labels have been added as needed. If there aren’t enough issues to warrant a tag, it has been skipped. Making `area:io:xdmf` might be useful if there are as many as mentioned elsewhere (50+). I haven’t seen enough other issues to warrant the other mentioned labels myself.

I’d also like to keep them all lowercase, but that’s me.

The skills labels seem more useful on Discourse than GitLab to me.

---

<div class="post-metadata">

### Author: ![mwestphal](https://discourse.paraview.org/user_avatar/discourse.paraview.org/mwestphal/32/17_2.png) [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [May 13, 2020, 5:14am UTC](https://discourse.paraview.org/t/gitlab-labels-improvements/4275/6 "2020-05-13T05:14:18Z")

</div>

Regarding the aera labels, I agree it may not be very useful.

Regarding the IO labels :

- io:xdmf : already exist (55 issues)
- io:openfoam : 17 issues
- io:netcdf : 11 issues
- io:exodus : 57 issues (!)
- io:export : ~30 issues
- io:AMReX : 5 issues
- io:cgns : 14 issues
- io:Ensight : 32 issues
- io:csv : ~20 issues

I’m afraid relying on organic creation for IO labels may not be very effective and it may help developers trying to tackle multiple issues at once.

Regarding the skills labels, I still think it may help Kitwarean and externals when trying to find issue to tackle.

I agree about the lowercase usage.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.paraview.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [May 13, 2020, 2:45pm UTC](https://discourse.paraview.org/t/gitlab-labels-improvements/4275/7 "2020-05-13T14:45:26Z")

</div>

> [@mwestphal](#):
>
> I’m afraid relying on organic creation for IO labels may not be very effective and it may help developers trying to tackle multiple issues at once.

How much better are the labels than just searching for the relevant keyword?

> [@mwestphal](#):
>
> Regarding the skills labels, I still think it may help Kitwarean and externals when trying to find issue to tackle.

This assumes that one has already triaged and figured out where the actual problem is. How many that aren’t `triage:easy` do we actually have that doesn’t fit into an existing label? Most of your labels already have `area` labels (lang:python, area:rendering, area:build). `area:servermanager` may be useful as a new label though.

---

<div class="post-metadata">

### Author: ![wascott](https://discourse.paraview.org/letter_avatar_proxy/v4/letter/w/8e8cbc/32.png) [@wascott](https://discourse.paraview.org/u/wascott)
#### Post date: [May 13, 2020, 4:05pm UTC](https://discourse.paraview.org/t/gitlab-labels-improvements/4275/8 "2020-05-13T16:05:58Z")

</div>

Note that, as of a few years ago, searches did the search in the BODY of the bug, but NOT the SUBJECT. It was quite a surprise.

---

<div class="post-metadata">

### Author: ![wascott](https://discourse.paraview.org/letter_avatar_proxy/v4/letter/w/8e8cbc/32.png) [@wascott](https://discourse.paraview.org/u/wascott)
#### Post date: [May 13, 2020, 4:07pm UTC](https://discourse.paraview.org/t/gitlab-labels-improvements/4275/9 "2020-05-13T16:07:06Z")

</div>

With regards to labels, what Cory and Ben said…

---

<div class="post-metadata">

### Author: ![mwestphal](https://discourse.paraview.org/user_avatar/discourse.paraview.org/mwestphal/32/17_2.png) [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [May 14, 2020, 3:27am UTC](https://discourse.paraview.org/t/gitlab-labels-improvements/4275/10 "2020-05-14T03:27:14Z")

</div>

> > [@mwestphal](#):
> >
> > I’m afraid relying on organic creation for IO labels may not be very effective and it may help developers trying to tackle multiple issues at once.
> 
> How much better are the labels than just searching for the relevant keyword?

With that like of thinking, label could just not be used.

> > [@mwestphal](#):
> >
> > Regarding the skills labels, I still think it may help Kitwarean and externals when trying to find issue to tackle.
> 
> This assumes that one has already triaged and figured out where the actual problem is.

Absolutely, sometime I take a look at an issue that seems interesting, I investigate, figure out the fix but realize that I can’t do it now or without funding. Using label in that case would be a neat way to formalize that this investigation has been done.  
Of course, a comment in the body of the issue works as well.

> How many that aren’t `triage:easy` do we actually have that doesn’t fit into an existing label? Most of your labels already have `area` labels (lang:python, area:rendering, area:build). `area:servermanager` may be useful as a new label though.

Not sure what is your point here, having multiple labels on a single is not a bad thing in itself.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.paraview.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [May 14, 2020, 12:48pm UTC](https://discourse.paraview.org/t/gitlab-labels-improvements/4275/11 "2020-05-14T12:48:10Z")

</div>

> [@mwestphal](#):
>
> With that like of thinking, label could just not be used.

Labels are there to facilitate the workflow. If a simple keyword search works well enough for what it stands for, then I question its immediate utility. The ones that exist now are not so easily searchable (docs could be a determination from a bug rather than a fix, build problems come in dozens of shades and flavors, rendering might crop of from anywhere, `triage:easy` doesn’t have a keyword obviously associated with it, etc.).

> [@mwestphal](#):
>
> Absolutely, sometime I take a look at an issue that seems interesting, I investigate, figure out the fix but realize that I can’t do it now or without funding. Using label in that case would be a neat way to formalize that this investigation has been done.

These are `triage:X` or `workflow:` labels. What new state fits in there that doesn’t exist now?

> [@mwestphal](#):
>
> Not sure what is your point here, having multiple labels on a single is not a bad thing in itself.

No, but keeping a dozen labels up-to-date accurately is nowhere near as trivial either. Labels may be missed at initial triage hiding them from future searches if they’re trusted. Unless we’re committing to actually keep these things accurate and triage every new issue within a reasonable timeframe, it’s just not worth the effort.

---

<div class="post-metadata">

### Author: ![wascott](https://discourse.paraview.org/letter_avatar_proxy/v4/letter/w/8e8cbc/32.png) [@wascott](https://discourse.paraview.org/u/wascott)
#### Post date: [May 21, 2020, 1:07am UTC](https://discourse.paraview.org/t/gitlab-labels-improvements/4275/12 "2020-05-21T01:07:58Z")

</div>

There is one flag I wish we had. It is either a priority:crash or triage:crash.

---

<div class="post-metadata">

### Author: ![mwestphal](https://discourse.paraview.org/user_avatar/discourse.paraview.org/mwestphal/32/17_2.png) [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [May 21, 2020, 2:22am UTC](https://discourse.paraview.org/t/gitlab-labels-improvements/4275/13 "2020-05-21T02:22:07Z")

</div>

triage:crash would make sense imo.
