Refine and prune GitHub issue labels

[emprzy]

Label

enhancement, meta/workflow

Priority Label

low priority

Is your feature request related to a problem? Please describe.

I've noticed a lack of clarity and some degree of redundancy in the GitHub issue labels. There's a lot of different issue labels, not all are defined clearly, and a few of them are redundant/barely used. I think our workflow would benefit from a more standardized set of issue labels, where it is clear when one should be used.

Second thing: @TimothyWillard has qualms with how the issue templates auto-tag issues with labels based on the contents of the issue (e.g., if the issue contains the word "documentation", the labeler will automatically assign that issue the 'documentation' label). This can create issues if you use a word in your issue that isn't actually the sole focus of the problem (e.g., an issue receiving the 'meta/workflow' label because it contained the word "metadata"). This feature was originally created per request from @shauntruelove in an attempt to make sure people label their issues. I don't really have a dog in this fight, but if Shaun agrees with Tim I will remove the auto-tagging feature.

Is your feature request related to a new application, scenario round, pathogen? Please describe.

No response

Describe the solution you'd like

I've created a document here where I've gone through and refined each of the brief definitions for the issue labels, and also marked the ones that I think could be removed. Here is the synopsis of the labels that I think could be pruned:

• duplicate: This has no active issue tags and could just be communicated via comment on the issue.
• help wanted: This could be communicated by tagging the individuals that you would like help from on the issue.
• invalid: This is encompassed in issue label 'bug', in my opinion.
• performance: This has no active issue tags and is redundant with 'enhancement'.
• question: Again, just cite the question in your issue and tag the people that it pertains to.
• revisit ASAP: Redundant with the various priority labels (specifically, 'high priority')
• • config.writer: I think this could be renamed to just 'config' (or something), because 'config.writer' refers to the flepiconfig R package that is no longer used.

The removal of issue tags is the primary thing I want input on. Unfortunately I cannot make a PR with my proposed changes because GH issues are repo-wide, but when we come to a consensus within this thread I'll just implement the desired changes. Requesting input from @shauntruelove, @TimothyWillard , @jcblemai

[emprzy]

Okay actually I do have a dog in this fight now ...the absurd number of issue labels that the auto-tagger gave this issue is evidence that the auto-tagger is perhaps a bunk feature.

Granted, I did explicitly reference the different labels by name so maybe that's not fair but still...

[TimothyWillard]

Okay actually I do have a dog in this fight now ...the absurd number of issue labels that the auto-tagger gave this issue is evidence that the auto-tagger is perhaps a bunk feature.

Granted, I did explicitly reference the different labels by name so maybe that's not fair but still...

That's funny that this issue became a great example of my qualm with the auto-labeler.

But in response to the issue labels:

• duplicate: In larger projects I frequently find it helpful to filter out issues with this label, so I'm against getting rid of it, but if no one uses it then then there's not point of keeping it around.
• performance: I think there is some value in this label because the complexity of performance related issues (profiling, writing multiple implementations, creating good benchmarks, etc.). However, I don't think we've given it a lot of focus so far and it is challenging to do so with the project in its current state so I don't think this will receive many issues in the near future. I made this one when I first started working on flepiMoP, so I'm a bit biased here and maybe someone else should comment as well.

And I largely agree with the others.

[shauntruelove]

I agree with @TimothyWillard. Keep duplicate and performance, remove the others.

[shauntruelove]

and also agree with removing the auto-assign. seems problematic.

[TimothyWillard]

What are the thoughts on adding a "dependency" label or similar for issues with package dependencies. I'm hoping these issues will decrease with frequency as we continue to stabilize the project, but it seems like the these issues are pretty frequent now:

• GH-332
• GH-315
• GH-308

[jcblemai]

I agree (though this could be paired with the installation label). Performance and Duplicate would be/are really useful

[pearsonca]

would issue labels by language be useful? e.g. language-py, language-R (others as appropriate)

[TimothyWillard]

would issue labels by language be useful? e.g. language-py, language-R (others as appropriate)

I think having package specific labels would cover most of this use case? I guess not for scripts that live outside a package.

Also, what are the thoughts on a plotting or viz label? Thinking of:

• GH-359
• GH-349

And others: https://github.com/HopkinsIDD/flepiMoP/issues?q=is%3Aissue+is%3Aopen+%28plot+OR+viz%29.

[saraloo]

Yeah I wasn't quite sure labeling when I put that issue together. It might be worth a label for the part of the config it refers to (ie there's no current outcomes label afaik). Plotting/viz might be helpful to label if it's like a check, or post simulation thing? ie preprocessing or postprocessing?

[emprzy]

Okay I just want to summarize before I make these changes, @TimothyWillard @jcblemai @saraloo

• add dependency label
• add plotting label
• add labels for all packages?

Is this correct?

[emprzy]

Update: Just added the new labels and made the necessary changes in the issue templates. New labels are:

• flepicommon (there is already a flepiconfig and inference, so all R packages are covered)
• dependency
• plotting, to cover visualization-related matters (used in lieu of viz)