Issue assignment to wrong project

[yaronkaikov]

It seems that scylladb/scylladb#15255 was assigned to The CoreFront team although none of the assignees are part of this team

[yaronkaikov]

@ptrsmrn Can you have a look please ?

[yaronkaikov]

/cc @kostja

[ptrsmrn]

@yaronkaikov this is because I created a view with "CI-Stability" label in corefront project, and so every issue marked with this label was sucked into the project... I didn't remove these issues yet from the coreftont project, because I thought it's not a big problem, but since you brought this up, I will.

[kostja]

Can we begin with a README file for this github project please? I would admire anyone coming up with an algorithm for automation of issue assignment.

I guess one way we could eventually get there is that team leads define combinations of tags to which they want to be subscribed. However, someone needs to assign out the tags themselves. this usually happens during issue triage, which is a manual process.

I don't see how we can replace a human with a machine here.

[ptrsmrn]

Can we begin with a README file for this github project please?

I will do it. This repo gains more and more attention, so it's about time for a proper README.md

I would admire anyone coming up with an algorithm for automation of issue assignment.

We already have an algorithm, and whenever a new issue is either assigned to a github team member [1] or is labeled with a label used in any of github projects [2], this github bot pins proper team to the issue. Of course the algo is far from perfect.

[1] team names are defined here - https://github.com/scylladb/github-automation/blob/main/.github/workflows/auto-assign-per-team.yml#L15 - and they reference regular github teams, which can be found here - https://github.com/orgs/scylladb/teams

[2] labels defined for each github project are scraped from project's views - if you visit any project, you'll see a couple of views (tabs). Each tab defines a filter by label, we just save these labels. On the below picture you'll see what labels we saved for Eliran's Team.

I guess one way we could eventually get there is that team leads define combinations of tags to which they want to be subscribed.

OK, so we have this part covered, because anyone creating a github project should also define some views with filters by labels. But this needs to be refined a bit, as I pointed out in #11 (comment)

However, someone needs to assign out the tags themselves. this usually happens during issue triage, which is a manual process.
I don't see how we can replace a human with a machine here.

Yeah, this part is hard to automate, unless we involve ChatGPT :)

[kostja]

* Piotr Smaron ***@***.***> [23/10/25 00:07]: 1. Let's begin with defining all the teams, and updating the existing team to reflect the reorg state - I have no access to this. 2. I don't see Benny or Botond's team. 3. Issues get reassigned. Does the bot follow up on this? CI stability is one label where issues frequently get reassigned, for example. 4. I prefer all issues assigned to any of the teams I manage to be also assigned to me (co-assigned). 5. Main point, what is the value of invoking the bot after an issue has already been triaged? We need a proper triage procedure for an unassigned new issue first, and follow up automation second.

…

> Can we begin with a README file for this github project please? I will do it. This repo gains more and more attention, so it's about time for a proper README.md > I would admire anyone coming up with an algorithm for automation of issue assignment. We already have an algorithm, and whenever a new issue is either assigned to a github team member [1] or is labeled with a label used in any of github projects [2], this github bot pins proper team to the issue. Of course the algo is far from perfect. [1] team names are defined here - https://github.com/scylladb/github-automation/blob/main/.github/workflows/auto-assign-per-team.yml#L15 - and they reference regular github teams, which can be found here - https://github.com/orgs/scylladb/teams [2] labels defined for each github project are scraped from project's views - if you visit any project, you'll see a couple of views (tabs). Each tab defines a filter by label, we just save these labels. On the below picture you'll see what labels we saved for Eliran's Team.  > I guess one way we could eventually get there is that team leads define _combinations_ of tags to which they want to be subscribed. OK, so we have this part covered, because anyone creating a github project should also define some views with filters by labels. But this needs to be refined a bit, as I pointed out in #11 (comment) > However, someone needs to assign out the tags themselves. this usually happens during issue triage, which is a manual process. > I don't see how we can replace a human with a machine here. Yeah, this part is hard to automate, unless we involve ChatGPT :) -- Reply to this email directly or view it on GitHub: #11 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

-- Konstantin Osipov, Moscow, Russia

[ptrsmrn]

1. Let's begin with defining all the teams, and updating the
   existing team to reflect the reorg state - I have no access to
   this.

It's easy, tho who's gonna do it? I mean, I can, but will the team leads even know about it/use it? I'd think it's up to team leads to do it (after I provide the documenation), assuming they wish to use this bot - maybe they don't.

2. I don't see Benny or Botond's team.

Whoever knew about this bot and wanted to use it, defined a team, so it's either 1st or 2nd case for them.

3. Issues get reassigned. Does the bot follow up on this? CI
   stability is one label where issues frequently get reassigned,
   for example.

Bot runs on a daily basis and assigns issues to project based on (1) assignees and (2) labels, so yes, if the label/assignee is changed, bot will move the issue to the other team (but I won't remove the old team, as far as I recollect - again, it's not a perfect tool, and it's also because github doesn't provide all of the functionality in the new graphQL API).

4. I prefer all issues assigned to any of the teams I manage to be
   also assigned to me (co-assigned).

Doable.

5. Main point, what is the value of invoking the bot after an
   issue has already been triaged? We need a proper triage
   procedure for an unassigned new issue first, and follow up
   automation second.

The sole purpose of this bot is to assign an issue to a team, and that's it. (The 2nd thing is it creates status reports, which only a few people look at).
Proper triaging process is always a good thing, though a person performing the triage doesn't necessarily know the correct team to assign the issue to, even if this person knows correct labels, so this is where this bot may be helpful.

[kostja]

* Piotr Smaron ***@***.***> [23/10/25 14:01]:

> 1. Let's begin with defining all the teams, and updating the > existing team to reflect the reorg state - I have no access to > this. It's easy, tho who's gonna do it? I mean, I can, but will the team leads even know about it/use it? I'd think it's up to team leads to do it (after I provide the documenation), assuming they wish to use this bot - maybe they don't.

I don't think you can - you have no admin permissions. I will take it up with Yaniv.

> 2. I don't see Benny or Botond's team. Whoever knows about this both and wants to use it, defined a team, so it's either 1st or 2nd case for them.

Ditto.

…

-- Konstantin Osipov, Moscow, Russia

[kostja]

* Piotr Smaron ***@***.***> [23/10/25 14:01]:

> 5. Main point, what is the value of invoking the bot after an > issue has already been triaged? We need a proper triage > procedure for an unassigned new issue first, and follow up > automation second. The sole purpose of this bot is to assign an issue to a team, and that's it. (The 2nd thing is it creates status reports, which only a few people look at).

My point is that there is an intellectual process of triaging a bug which involves a human. today it is not systematic at all, this is why bugs bounce from person to person before they find their home (if at all). We can't solve this with a bot. What we need to be doing is looking at issue on a regular basis (e..g today Yaniv is looking at them), adding relevant tags, releases, priority labels (less so) and assigning them to a team.

…

-- Konstantin Osipov, Moscow, Russia

[kostja]

Actually the results of this bot work are appalling.
Here's the search for CoreFront team in the enterprise repository: https://github.com/scylladb/scylla-enterprise/issues?q=is%3Aopen%20is%3Aissue%20project%3Ascylladb%2F69

Obviously there are issues assigned at different developers, from different problem areas, and most of them have nothing to with corefront.

[ptrsmrn]

Actually the results of this bot work are appalling. Here's the search for CoreFront team in the enterprise repository: https://github.com/scylladb/scylla-enterprise/issues?q=is%3Aopen%20is%3Aissue%20project%3Ascylladb%2F69

Obviously there are issues assigned at different developers, from different problem areas, and most of them have nothing to with corefront.

There were additional issues labeled CI-Stability accidentally added to the core-frontend project, as explained here, which I removed from the project (for both the OSS and enterprise repositories), and core-frontend's backlog of items is clean(er) now.