Built-in scaler Governance about scaler maintainer(s)

[rickbrouwer]

The SCALERS.md contains, among other things, the following:

A scaler maintainer(s) MUST be assigned (individual(s)/company) and will be tagged for bug reports. If this is not the case, then it will be considerd to be "community-maintained" and all issues will be tagged with "help-wanted".

A scaler MUST be supported, as per our support policy, by the scaler maintainer(s) and will be automatically assigned to PRs. This will be done by using GitHub's Codeowners.

However, based on governance, I would expect issues to be linked to individuals (or individuals within companies) designated as scaler maintainers. The same applies to PRs.

It's still unclear to me who the scaler maintainers are and how they are involved (and being tagged) in issues and/or PRs.

[rickbrouwer]

Proposal.

As outlined in MEMBERS.md, we must identify the maintainers for the built-in scalers (as described in the governance document via commit 91b3a3a).
We will first identify the current built-in-scaler-maintainers and contact them. If approved, we can record these in a new BUILT-IN-SCALER-MAINTAINERS.md document. These individuals can be tagged with issues and/or PRs for input if their scaler is affected.
For now, I think it's enough to first map out who the built-in scaler maintainers are (based on commits from the keda-docs). If there is no response , the community becomes a maintainer again.

The process will then continue with the governance described in SCALERS.md

[JorTurFer]

I think that this is an excellent idea to track the current people in charge of the scalers, but we should also add them to the codeowners file of the repos, otherwise, they won't be notified and we can forget to do it

[JorTurFer]

@zroubalik @wozniakjan ?

[zroubalik]

Apologies, I missed this.

Good idea, I like it. We should also figure out, how to notify them for the respective scaler issues. Maybe a bot?

[rickbrouwer]

We should also figure out, how to notify them for the respective scaler issues. Maybe a bot?

Yeah, good idea! Maybe we could also take a closer look at the existing labels (and clean them up if necessary). If we get a fresh label from each scaler, the bot might be able to look at that and do something with it.

[JorTurFer]

Good idea, I like it. We should also figure out, how to notify them for the respective scaler issues. Maybe a bot?

This should be covered with the new workflow that we have added, for example, this PR adds ara as datadog reviewer.
My concern here is that we can't enforce the approval requirement without codeowners, and codeowners requires write permissions, which is something that we don't want to assign to external people.
This requires the agreement of not merging anything without the reviewer approval (at least, giving a reasonable amount of time for the review), which is something that we have do by ourselves. Maybe there is any GH actions or so that can block the merge until it happens, but I haven't seen anything related

[rickbrouwer]

Good work @JorTurFer!

Do we also have a plan to properly identify the remaining scaler maintainers?
Would it be a good idea to create a separate issue for this and identify them from the keda-docs, where scaler maintainers are listed as company, mention them in the issue with a brief explanation of whether they still want to be scaler maintainers, and allow one release window (4 months) for this (till end this year)?
If there's no response, should we convert it to community?

To follow up on this piece:

Maybe we could also take a closer look at the existing labels (and clean them up if necessary).

This is getting a bit off-topic, but I don't have permission to create or edit labels. I think this could be cleaned up a bit so we can label things more and more quickly identify what PRs or any statuses are for.

[JorTurFer]

Yeah, probably we should start a round checking non-community maintained scalers to double check if they are still interested and adding them as reviewers

[JorTurFer]

This is getting a bit off-topic, but I don't have permission to create or edit labels. I think this could be cleaned up a bit so we can label things more and more quickly identify what PRs or any statuses are for.

Do you mean here on in keda repo? In keda repo you should, if not I'll have to take a look if it's a limtiation or so, because triage role (the most basic already has it)

and we created a custom role based on triage with some additions for security topics

[JorTurFer]

I've tested the GH workflow to assign people and it returns an error when we try to assign a reviewer which isn't a collaborator of the repo:

Error: Reviews may only be requested from collaborators. One or more of the users or teams you specified is not a collaborator of the kedacore/keda repository. - https://docs.github.com/rest/pulls/review-requests#request-reviewers-for-a-pull-request

https://github.com/kedacore/keda/actions/runs/17178560323/job/48737876429?pr=7009

At this point, I suggest inviting to the org to all those colleagues willing to review scalers and add them to different teams and then assign the teams as reviewers of the code. Do you agree?
Another option is to invite them just as collaborators to keda/keda-docs repos but in this case we would need to manage the people one by one on each repo and the teams options seems like better solution

[rickbrouwer]

This is getting a bit off-topic, but I don't have permission to create or edit labels. I think this could be cleaned up a bit so we can label things more and more quickly identify what PRs or any statuses are for.

Do you mean here on in keda repo? In keda repo you should, if not I'll have to take a look if it's a limtiation or so, because triage role (the most basic already has it)

and we created a custom role based on triage with some additions for security topics

Yeah, we can add and remove labels on issues and PR's. But what I mean is create, edit, delete existing labels. So I can create completely new labels. I think a lot of labels could use some cleaning up too (so deleted). But maybe something like that is only meant for the maintainers, idk.

[rickbrouwer]

At this point, I suggest inviting to the org to all those colleagues willing to review scalers and add them to different teams and then assign the teams as reviewers of the code. Do you agree?

Agreed. I think that's the only good solution. It does mean creating many teams for "scaler maintainers," but that's the cleanest approach.

Should I create a separate issue and make an inventory of who I think should be contacted? I can post the GitHub names in plain text first, or I can mention them directly.
If you, as maintainers, feel more comfortable with that you create a separate issue with a text, that's also fine. I could then also post a comment in that issue with an inventory of potential scaler maintainers from the initial commit history.

[JorTurFer]

At this point, I suggest inviting to the org to all those colleagues willing to review scalers and add them to different teams and then assign the teams as reviewers of the code. Do you agree?

@zroubalik @wozniakjan WDYT? If there is an agreement with this (required to notify external people BTW), we can list all the scaler maintainers and start the contact with them

[zroubalik]

Agree!

[zroubalik]

And we should probably start requiring this for new scalers that are about to be added to the new release.