We've seen a healthy adoption of KEDA by the community over time and received various contributions for running KEDA, operating it, and providing more scalers.

In the next couple of weeks, we will open a proposal to graduate to a CNCF Incubation project as we believe that we are approaching this next level in our project timeline.

Graduation process: https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc#incubating-stage

What we will do before opening the proposal

• Provide branding guidelines for our logos (kedacore/keda#1090)
• Provide a thorough security policy (#3)
• Setting up full container & code scanning
  • Setup container scanning on-push (kedacore/keda#1040)
  • Setup container scanning for published images (#52)
  • Setup security scanning for Helm charts (kedacore/charts#64)
• Improve our coverage of CII Badge (#8)

How can the community help?

• If you are an existing KEDA user, please let us know and get listed on keda.sh. (docs)

Publish Alibaba reference case on how and why they use KEDA.

Image pull metrics on GitHub Container Registry are ambiguous because GitHub measures all the pulls for the image signatures, which is noise to our interest.

Document eligibility criteria for Maintainers

See:

• https://docs.google.com/document/d/11Qy7uWginP3gFQVpqnNM4CRp4kQKnEM6FTs2M6pm2o8/edit
• cncf/toc#925 (comment)
• Guidance

Setup WhiteSource Bolt for security scanning in conjunction with Snyk given not all vulnerabilities were caught as per kedacore/keda#2503.

Tasklist

• Setup WhiteSource Bolt
• Update Security Policy

Introduce "Contributors" group for frequent contributors so that we can assign the users/group to issues.

This should be documented in the repo when people are being considered to be added and what it means to become one.

Provide a Security Policy that helps customers and researchers to report security vulnerabilities.

We should provide:

• Introduce a Security Policy
• Issue template to report vulnerabilities

Provide automated deployment of Azure resources used in end-to-end tests with Bicep so that things are automated and I'm not the bottleneck (or at least less).

This is because our Azure subscription is not accessible to everyone and should be just a PR away.

Switch default branches from master to main to be more inclusive.

Things to keep in mind 💡

• Rename the branch instead of re-creating (docs)
• Verify branch policies are aligned
• Verify workflow triggers are aligned
• Verify external systems are updated (Snyk, Artifact Hub, etc)
• Verify scripts using the branch name

Impact on contributors

Members will have to update their local environments (or forks).

git branch -m master <BRANCH>
git fetch origin
git branch -u origin/<BRANCH> <BRANCH>
git remote set-head origin -a

Task List

• kedacore/keda#1092
• kedacore/charts#195
• kedacore/keda-docs#584
• kedacore/external-scalers#13
• GitHub template
• OLM Operator
• HTTP add-on
• External Scaler for Azure Cosmos DB
• kedacore/keda-external-scaler-azure-durable-functions#19
• kedacore/external-scaler-samples#2
• Samples
• Sample - RabbitMQ consumer and sender
• Sample - .NET Core worker processing Azure Service Bus Queue scaled by KEDA
• kedacore/sample-javascript-eventhub-azure-function#6
• kedacore/sample-python-kafka-azure-function#5
• kedacore/sample-go-storage-queue#1
• kedacore/sample-go-gcppubsub#4
• kedacore/sample-typescript-kafka-azure-function#7
• kedacore/sample-hello-world-azure-functions#17
• kedacore/sample-azure-functions-on-ocp4#3

Next to Azure credits (#31), it would be nice to have access to resources on other cloud providers.

Because of that, we should request to onboard to the CNCF Cloud Credits program.

https://www.cncf.io/credits/

Status

• AWS
• GCP

As an end-user it is easier if we would have a release schedule and ship every X period. This would allow them to more easily plan upgrades which would help maintainers to focus on more recent versions.

This issue is here for us to discuss if that makes sense for KEDA and what our cycles would look like.

For examples, see https://github.com/envoyproxy/envoy/blob/master/SECURITY.md etc

Introduce issue template to announce deprecations that follow our policy as per https://github.com/kedacore/governance/blob/main/DEPRECATIONS.md.

Follow-up for #68

We are having some growing pains & bugs for our documentation which are being tracked in this milestone:

https://github.com/kedacore/keda-docs/milestone/1

A request has been opened with CNCF to see if we can get some help on these.

Provide a policy around deprecations in KEDA to help end-users be aware of what to do, by when, what the impact is and how to migrate.

Also, it should set expectations on when KEDA is allowed to remove things and break end-users.

Tasklist

• Define policy
• Add link to keda.sh / Project
• Add check in PR template for Core
• Add check in PR template for Helm

As KEDA grows, so does its community and we should consider introducing a community ladder to give credit to those who keep on contributing day-in, day-out (regardless of contribution type).

There are a few options we can consider:

• Formal Community Membership (similar to Dapr's approach)
• Introduce KEDA badges (similar to Linkerd Hero thanks to CNCF service desk)

This idea was initiated due to #29 which is a valid question.

We should send a message like this, but more polished.

Our community call starts in ~20mins, looking forward to see you there :slightly_smiling_face: https://keda.sh/community/ 

https://slack.com/resources/using-slack/how-to-use-reminders-in-slack

The global CNCF calendar has out of date information for KEDA's community calls.

https://www.cncf.io/calendar/

It looks like the time on the calendar is an hour late, the meeting location has changed, the url still points to hackmd, and the hackmd link to find the meeting notes (via aka.ms) is broken.

Would be good to reach out and have the calendar event corrected.

Cheers!

Use a 3rd party to perform a security audit of KEDA.

CNCF provides this and can be requested.

What are the rules (or permissions required) in order to use the KEDA logo? For example to print on t-shirts, stickers or mugs and potentially selling said items with the KEDA logo on them? Where could explicit permission be obtained from?

CNCF is launching a Environmental Sustainability WG (https://github.com/cncf/wg-env-sustainability) to which we should see if we can help given we support scale-to-zero and ARM machines.

Setup Azure DevOps organization for automated tests of our scaler

Request Azure funds for open-source projects through new program:
https://cloudblogs.microsoft.com/opensource/2021/09/28/announcing-azure-credits-for-open-source-projects/

Introduce "Scaler Contributor" Credly badge for which scaler contributors can apply through an issue on this repo when they have met the requirements.

Relates to #30

Tasklist

• Create an issue template for people to apply for the badge
• Create a Credly badge
• Define the requirements
• Reach out to all previous scaler contributors that meet the criteria

ARM is becoming a major aspect for workloads such as edge and we've received requests to provide an ARM-based image (kedacore/keda#779).

GitHub Actions does not provide an ARM runner, but CNCF allows us to request a bare metal machine (link) on which we could run a self-hosted runner.

If we want to, we can request one but the following requirements apply:

• Code being run must be 100 percent open source and must not include any sensitive data.
• Testing should involve cloud native computing, meaning containerization, microservices, orchestration or some combination.
• You agree to write a blog post later about your experiences with the CIL.
• Priority is given first to CNCF projects, then to developers from CNCF member companies and then to any open source developer.
• Resources are limited so we may ask you to reduce your usage when there is high demand for the available credits from Equinix Metal ($1,000,000 per year).

What do you think?

I've recently opened a few issues for integration with other technologies:

Azure Service Operator: Azure/azure-service-operator#1377
Crossplane:

• ALibaba Cloud: https://github.com/crossplane/provider-alibaba/issues/57
• Rook: crossplane-contrib/provider-rook#94
• GCP: crossplane-contrib/provider-gcp#304
• AWS: crossplane-contrib/provider-aws#537
• Azure: crossplane-contrib/provider-azure#221

I was thinking, would it make sense to document in a page what the tools are that we integrate with and they can use KEDA with?

This could be in our docs, in this repo or in something like kedacore/integrations.

Provide automation to merge documentation PRs when the feature PR was merged so that we don't have to manually keep track of them.

Optionally this could be through slash commands.

Document criteria and process for removing Maintainers other than inactivity such as code of conduct violation.

See:

• https://docs.google.com/document/d/11Qy7uWginP3gFQVpqnNM4CRp4kQKnEM6FTs2M6pm2o8/edit
• cncf/toc#925 (comment)
• Guidance

The TOC has requested your annual review. This review has a deadline of two months of this notification, April 9, but we do have a review session coming up on March 9th if you'd like to complete this now.

How to complete your annual review:

• We’ll be looking for a PR titled: KEDA-2021-Annual Review
• The PR should include a file called 2021--annual.md
• Send an email to the TOC mailing list so that the community knows the PR is there and can comment on it

Your annual review should answer the following questions:

• Include a link to your project’s devstats page. We will be looking for signs of consistent or increasing contribution activity. Please feel free to add commentary to add colour to the numbers and graphs we will see on devstats.
• How many maintainers do you have, and which organisations are they from? (Feel free to link to an existing MAINTAINERS file if appropriate.)
• What do you know about adoption, and how has this changed since your last review / since you joined Sandbox? If you can list companies that are end users of your project, please do so. (Feel free to link to an existing ADOPTERS file if appropriate.)
• How has the project performed against its goals since the last review? (We won't penalize you if your goals changed for good reasons.)
• What are the current goals of the project? For example, are you working on major new features? Or are you concentrating on adoption or documentation?
• How can the CNCF help you achieve your upcoming goals?
• Do you think that your project meets the criteria for incubation?

Write proposal for KEDA to graduate to CNCF Graduated project

Proposal

Provide bot for managing issues so that we automatically close stale issues.

Use-Case

Clean up old issues

Anything else?

No response

CloMonitor is a new tool by the CNCF to show the health of projects and provide tips and guidance on how to improve.

There are a few things that we should improve to align with the traditional approach of OSS communities.

Current results: https://clomonitor.io/projects/keda/keda

Task list

• Add Artifact Hub badge
• Add FOSSA badge
• Add Adopters file with link to our overview and how to be added
• Add Roadmap file with link to our roadmap
  • Relates to #48
• Add Governance file with link to our governance repo
• Add CODE_OF_CONDUCT file
  • We already have it but needs to be pulled from our .github repo; see cncf/clomonitor#68

Example: kubernetes/kubernetes#108110

Improve FOSSA project setup given it was not running from the correct GitHub repo.

Hi!
I'm lover of KEDA because I think that it covers an existing gap in Kubernetes autoscaling and open the doors to a lot of several event-driven scenarios from nowadays.
If you could consider me as a KEDA maintainer, it'd be amazing

Thank you for your time!

Request keda-dev channel in Kubernetes Slack so people contributing can talk to each other and our current keda is mainly focussed on other chatter.

Opening this issue to request to step down from the role of a Maintainer from KEDA org. This is to reduce the number of maintainers from Microsoft (Currently they are 3 including me) and also not being able to give enough time.

Tasklist

• Access to 1Password (@tomkerkhove)
• Access to CNCF DLs (@amye)
• Access to GitHub groups (@tomkerkhove)
• Add to CODEOWNERS file in our repos

Follow-up for #38

Last week we've added the Azure Durable Functions Scaler to our org which is not shipped as part of KEDA core runtime but more of an add-on scaler.

Personally I'm a fan of this model given our core would become too big and not everybody needs this scaler.

We should define some governance around this and answer questions such as:

• What is part of KEDA core runtime and what are add-on scalers?
• When should a scaler be part of core and when is it an add-on scaler?
• How can one donate a scaler to KEDA as an add-on?
• How do we approach this in terms of docs?
• How do we manage access to our Docker Hub account?
  • We're transitioning the containers as we speak (PR)

Maybe this is something that should be in https://github.com/kedacore/governance or so to decouple it from here?

Tasklist

• Provide governance doc
• Change PR template to ensure new contributors acknowledge the requirements for new scalers
• Introduce CODEOWNERS per scaler

Code of Conduct is not discoverable as it is hidden in kedacore/.github to bring it to all GitHub repos automatically; but it is not referred to nor available explicitly in this repo.

See:

• https://docs.google.com/document/d/11Qy7uWginP3gFQVpqnNM4CRp4kQKnEM6FTs2M6pm2o8/edit
• cncf/toc#925 (comment)
• Guidance

We've discussed it in the past (see kedacore/keda#995) but I think it's time to migrate our Docker images to GitHub Container Registry which brings our artifacts closer to our GitHub repos and gives us more insights on the adoption (# of pulls per tag, instead of vague total pull count).

We are dry-running this for our HTTP add-on and it's fairly straightforward.

Here is how people can discover them:

Per Docker image, you can then see the pull count per tag:

I've used this on other projects as well and it gives you a lot more insights than Docker Hub, and would never move back.

⚠ If we do this, then we should move all Docker images to our new registry for sake of completeness, but keep the old ones on Docker Hub.

We require CNCF projects to go through this badging process:
https://bestpractices.coreinfrastructure.org/en

See https://grafana.com/blog/2022/10/20/how-to-autoscale-grafana-loki-queries-using-keda/?mdm=social
See kedacore/keda-docs#961 (comment)

Now that we are part of CNCF we should publish our standups to their YouTube account similar to other projects.

https://www.youtube.com/channel/UCvqbFHwN-nwalWPjPUKpvTA

Today, we use HackMD to take notes for our standup and @jeffhollan has setup a Zoom meeting that we are joining.

However, we are facing some issues:

• HackMD is not as straightforward as other tools and does not allow to make suggestions.
• Zoom is not automatically recording so people cannot watch standups afterwards. There is also a high bus-factor for @jeffhollan

Because of that, we have decided that we will:

• Migrate to Google Docs where everyone in the community can make suggestions for the agenda and people can collaborate on the standup notes
  • Good examples where this is already used are SMI and OpenTelemetry
• Request a Zoom Pro account with CNCF that offers it through the service desk
  • This allows all maintainers to have more permissions, automatically record and maybe even automatically publish to YouTube so that everyone can watch on-demand

Tasklist

• Request Zoom Pro account
  • Setup auto recording
  • Create YouTube channel
  • Add maintainers as co-hosts Added host key to 1Password
  • Setup auto publish to YouTube
• Migrate to Google Docs
  • Migrate content to new document
  • Provide link in HackMD
• Update our community
  • Update Google calendar
  • Post notification in Slack
  • Update "Community" page on keda.sh

Setup container scanning for published images in Docker Hub with Snyk.

• Setup Snyk
• kedacore/keda#2325
• Update security policy

Provide release plan governance that talks about when we ship, what our release cadence is, etc.

https://bestpractices.coreinfrastructure.org/en/projects/3791

We should compare our current DCO approach with easyCLA to see:

1. If we can use easyCLA (wrt CNCF)
2. What benefits it would give

Once we know that, we should decide which option is the easiest with ease-of-contribution in mind.

Provide more mature roadmap so we can better manage work and provide a better way of consuming the information for end-users to set expectations.

The new GitHub Projects will be used to bring our backlog to life.

Tasks

• Set up a new GitHub Project
• Automatically add new core issues to our roadmap
• Document how work needs to be added to iterations
• Document how end-users can consume our backlog
  • Update our GitHub repo
  • Update our docs