it’ll be there.

I mean in the poll

?? the idea is that the prefix itself is based on the tag..

ohhhhhhh I thought we were polling on "title v tag"

aaahhh… nooo just the “style”..

OK I missed that

yep, that’s not a bad idea in the absence of labels

Then it should be labeled as such, yeah?

or not.. if the change doesn’t have a user visible effect, besides being a PluginAPI change, for example, so would be labeled as “[Core]” or something like that..

To play devil's advocate, I have in-repo plugins that rely on the plugin API, but only for Python. It might be worth being able to glance and see if a plugin API change might or might not apply to me?

so isn’t the python plugin api in the python backend?

I think deducing it from path changes might require some very fine-grained path categorisation, and arguably still might need human insight. E.g. https://github.com/pantsbuild/pants/blob/main/src/python/pants/backend/python/util_rules/faas.py is within the python backend, but changes there almost certainly affect the

python.backend.awslambda.python

and

python.backend.google_cloud_function.python

backends, not

pants.backend.python

... and not necessarily both! (e.g. a change to improve something about AWS Lambda Layers might require changes to that file, but will only affect the first of those.) Thus, what do you think about: 1. a label per backend (including

core

) 2. automation that either: a. validates a PR includes at least one (similar to

category:

labels) b. if a PR includes none, does an estimate based on paths and applies one or more labels, but a human can override afterwards

yea, I like the path based approach to apply labels, because that is visible and you can adjust before it is applied.