Don't remove labels added manually
See for example https://github.com/NixOS/nixpkgs/pull/36189
This is pretty tough to do. For the near term I could stop adding the python topic tag if you'd prefer.
The reason it is tough is because there are cases where labels should be removed automatically, like when a branch changes to staging and has suddenly a huge diff. ofborg adds tons of labels, then the author rebases against staging and their commits become much smaller. Ofborg then correctly removes all the labels that are not appropriate.
So, the reason this is tough is I think the feature is really: don't remove labels when a person added the label... and that is tough because GitHub's API makes it hard to see this information.
Of course, maybe the right thing is to do is drop topic tagging altogether until I can do that? What do you think?
cc @FRidh
So, the reason this is tough is I think the feature is really: don't remove labels when a person added the label... and that is tough because GitHub's API makes it hard to see this information.
Well, if you turn this around — «the bot can remove only the labels set by the same bot» — the same specification sounds a bit more feasible. Borg could have a log of labels it has added (per PR/issue), and only remove the labels found in this log.
Or ofborg labels can have their own namespace
No, please don't drop topic tagging :)
I think you should be able to find out the author by looking at the LabeledEvents in the PR's timeline: https://developer.github.com/v4/object/labeledevent/
Not relabeling labels that were removed manually should be possible using https://developer.github.com/v4/object/unlabeledevent/
@shlevy if multiple people start searching by borg:topic:python, there is a tempatation to just set the label manually instead of reminding everyone to search for topic:python, too.
True, @dotlambda! I forgot about that! Unfortunately the library I'm using to talk to GitHub (https://github.com/softprops/hubcaps) doesn't support it, so I'd have to first start by implementing that. I don't mind that, but it isn't something I'll be able to do straight away. If you don't mind waiting, I'd be happy to go this route.
Sure, no need to hurry. Thanks for all your work, @grahamc!