ADR-24: Define work flow and labels for issues

[cornelius]

Fixes #25 and fixes #68

[cornelius]

To be frank I do see little need for or value in this ADR. A note about labels should be used can be added to the contribution guidelines and the discussion can happen in a PR there or an issue (which we do have apparently).

Ok, seems my intention with this ADR didn't come across (and it seems we still haven't found a common way of how to discuss ideas/proposals/decisions 😉 ).

I see the purpose of this ADR to discuss and agree on how to handle issues. That won't be very different from what we do know but will hopefully eliminate some inconsistencies and confusion about what to do (e.g. if to track issues in one repo or the other). The ADR contains a lot of material as context for this decision, not as standard for the future. That's the only point of including the current label list.

I could have started with the pull request to the contributing guidelines or the developer notes or whatever. This would have been much smaller, but it would have missed the context. That's why I decided to go with the ADR format.

If it helps I can do the pull request for the documentation now but I thought it would be good to first agree on how we want to do it.

It duplicates a lot of stuff from somewhere which is going to be outdated.

This is just a one-time copy (and it's marked as such) as context.

Also, to be honest, it feels like it's introducing/overdoing/bureaucratizing (<- no idea how this should be spelled) a process which is working.

This is certainly not the intention. I hope we end up with some simple result. But we do have a lack of clarity about several aspects of the issues (unused labels, same label used in different ways or spelled in different ways, where to track issues, what does it mean to be assigned to an issue, etc.) which I think we do need to discuss and agree on how to proceed.

These are not big things so I hope we can solve them quickly and end up with something which does not introduce bureaucracy but makes things clear to everybody involved.

[mergeable[bot]]

There has not been any activity in the past 10 days. Is this still active?

[cornelius]

I have tried to address what was brought up in the comments and pushed a new version of the ADR. I also added a file which contains the documentation which would result from the ADR. Please have a look and let me know how this would work for you.

One thing I'm not so sure about is the naming convention to group labels which belong together (as sub labels). We have many labels so if labels which belong together show up in the UI next to each other it makes picking the right labels easier when assigning and filtering for labels. That's the rationale for having something like test: broken and test: floating. If the convention with using colons as separators between main and sub label works better than using slashes and dashes as suggested by @frolosofsky is better, I'm not sure.

Renaming labels is not difficult so maybe it doesn't matter much and we should just go with some way and see how it works.

[scravy]

up for grabs label?

[scravy]

ACK d5aaf17db9463aec30a6508e2618d42fb54a6daa

[cornelius]

I did some research and it seems to not be too difficult to manage labels via the API with some tools. There are several implementations of some labelling helpers which can write labels from some description. There also is a GitHub provider for Terraform which can manage labels.

Renaming labels via the API is a bit problematic because the API uses the name as key for the label so some extra care is required when renaming labels which are assigned to issues because deleting the label and creating is as a new one would remove it from the issue. But this also can be done by keeping track of the previous name. Simply having the list of labels in a YAML file is not enough in this case, though.

But this will allow us to put the definition of labels into git, so we can do and discuss label changes via pull requests. So I'll defer the open questions about how the exact naming of the labels should look like to this mechanism and not do it as part of this ADR.

I'll put in a note about this and then merge the ADR so we have settled the general decisions and can continue with the fine-grained management of the labels on an ongoing base.