Issue tracker label cleanup

[davisagli]

GitHub added a Type field, where we can currently select Bug, Feature, PLIP, or Task.

We also have older type labels: 01 type: bug, 02 type: regression, 03 type: feature (plip), 04 type: enhancement, 05 type: question, 06 type: plip task.

I propose that we should:

1. Convert the bug, PLIP, and enhancement labels into the Bug, PLIP, and Feature types, respectively.
2. Remove the other type labels.

Does that sound okay to you, @tisto?

[tisto]

This makes lots of sense. +1

I am currently trying to clean up and document the PLIP process and I run into similar issues. I know that @jensens wrote a script in the past to set labels consistently across Plone core packages. That could be helpful in our situation.

[jensens]

It comes with some spiderwebs and dust https://github.com/plone/plone.github

[jensens]

you want also to have an eye on this good old spreadsheet, which defines what we agreed on - once upon a time https://docs.google.com/spreadsheets/d/1IQ73bSQ10b0pwoUFn0u8SE4epDdvwjhTiYTDyPAhx7A/edit?gid=0#gid=0

[tisto]

@jensens thanks for sharing. This is useful. For the PLIP review process we need a way to differentiate between PLIPs that have been merged and released and the ones that are just closed (because they were rejected or abandoned).

We could use "Close as completed" and "Closed as not planned" to differentiate. However, I would like to add another label to be more explicit. This could either be "merged_and_released" or "rejected_or_abondoned" (or both).

[davisagli]

@tisto We should use the Status field on the PLIPs project for this, not labels. (It's like the difference between creating a custom field or using tags in Plone.) Here is where the options for that field can be managed: PLIPs (core)

[tisto]

@davisagli I get that. However, there is no way to properly filter for the status:

The PLIP process is our most important process in the Plone community and I think it is important that the process is transparent and can be understood by people. Using a hidden feature of GitHub does not sound like a good idea to me (at least not without some way to make this more obvious).

Maybe I am missing the point here. However, if I don't get it this would somehow prove my main point. :)

[davisagli]

@tisto Ok, I get your point that using fields from a specific project may be too hidden, and I didn't realize it has this limitation with the filtering.

FWIW, filtering by status does show the correct values for the project if I do the search starting inside the project instead of in the CMFPlone issue tracker:
PLIPs (core) (view)

I tend to think we should set up a PLIP project board that works well, and direct people to it. Ad hoc searches in the issue tracker are likely to accidentally miss some things. For example, the query in your screenshot is in the CMFPlone repository issue tracker so it didn't find PLIPs that were created in the volto issue tracker.