Snitch is not able to assign labels to the snitched issues

[rexim]

[mfocko]

So, based on APIs:

• GitHub: labels in JSON - array of strings
• GitLab: labels as URL parameter - comma-separated string

For now there is formatting for:

• unreported issues: PrefixKeyword:
• reported issues: PrefixKeyword(Issueid):

What about adding the labels after the keyword in brackets [] or {}? That would mean:

• unreported: PrefixKeyword[Label1,Label2]:
• reported: PrefixKeyword[Label1,Label2](Issueid):

Since the presence of the labels is optional it shouldn't break parsing of already reported issues in the code.

EDIT: Thinking about it, it basically means that we can use it right away for GitLab and for Github just split it by commas.

[rexim]

@mfocko I don't really like it:

1. This design adds complexity to the syntax of the TODOs and I'm not sure if the value we get out of it is justified.
2. It implies that the contributor (the one who adds the TODOs) now has the power to prioritize the issues by assigning labels to them while in most of the cases it is the responsibility of the main developer of the project.

When I created this issue I had the following use case in my mind:

1. Configure a label in .snitch.yaml.
2. snitch report looks at .snitch.yaml and always assigns that label to the newly reported TODOs.
3. The main developer than later filters all of the reported issues by that specific label and prioritizes them accordingly.

What do you think?

[mfocko]

Maybe --label CLI option? that could be used multiple times? or would take directly the comma-separated string...

Or both .yaml and CLI

or [] at the beginning of the title, but that's up to you

[mfocko]

I just got an idea related to this issue... What do you think about switch that would automatically assign label to issue based on the keyword?

[rexim]

@mfocko so you suggest to introduce already 2 entities to solve a problem of just assigning a label: keyword and switch. Too complicated, don't like even more.