Checking our charter I do not see a provision that describes how and when to update the SC representation by companies.

Right now IBM and RH are a single company and Pivotal has been acquired by VMware.

At a minimum we should update the knative stats and re-check the contributions of companies.

Objective

Google proposes to donate Kf to the Knative project.

Background

We’ve been working with a number of customers on their journey to adopt Knative, and have consistently heard strong feedback from CF developers who want to leverage their existing understanding and “developer interface” with Knative.

While the Kn tool provides a great experience for deploying containers, many developers are looking for a source-to-URL experience without needing to think about containers at all.

Kf is a migration tool which helps developers transition from a Cloud Foundry (CF) environment to a Knative and Kubernetes-based environment. Kf enables a migration story for CF apps to transition to Knative while teams build in-house operational expertise to manage Knative and Kubernetes components directly.

Kf builds on the experiences provided by the Kn CLI, which is already a part of Knative, to provide an experience familiar to CF developers. Kf is designed to help teams transition into using Knative and Kn, and should not be considered a replacement/alternative CLI to the native Kn tooling.

Current Status

Kf currently supports the cf push developer experience via Buildpacks or Docker images. It also supports CF marketplace and services via the Kubernetes Service Catalog. Kf has the following dependencies:

1. Knative Serving 0.6
2. Knative Build 0.6 (migration to Tekton in progress)
3. Istio 1.1.3
4. Kubernetes Service Catalog 0.2.1

Knative Project Fit

Kf has a strong alignment as a client of the Knative resources. It has and will continue to drive additional requirements into the Knative project, and continue to drive the usage of Knative and the set of use-cases Knative can enable. Many of the customers we’ve worked with are excited about the idea of using Knative through the lens of a cf push style experience and would like to see that a part of the overall Knative story.

Kf does have dependencies beyond Knative, e.g. Service Catalog and Tekton, and requires additional custom CRDs and controllers. Over time we will work to understand the common blocks for Knative and Kf and separate them from Kf client.

We see few main goals aligning with Knative:

1. Provide a CF-to-Knative migration path by building a tool that gives a CF-like developer experience on top of Knative.
2. Create a tight feedback loop between customers and Knative developers to help identify pain-points and prioritize work on the Knative/serving roadmap.
3. Engage with the Knative community (Red Hat, Pivotal, IBM, SAP) to enhance the project and shape the roadmap for Kf.

Future Directions

Kf at the moment is an experimental project creating an opinionated client experience for Knative. It does not and will not replace Kn, nor should it prevent other opinionated experiences from being introduced into the Knative project. We expect to rapidly and continuously improve Kf as we work with more customers and perform more real-world migrations.

We will continue to work with a set of target customers who are migrating from CF to Knative and Kubernetes, to drive the roadmap and requirements for Kf and additional work into the rest of the Knative project as appropriate.

Initial Roadmap

• Support for Buildpacks
• Deploy apps
• Binding services (eg: MySQL)
• Controls such as namespaces, users, quotas
• Service Catalog

Process of donation and adoption

We propose that Kf be spun up as a new workgroup that works closely with the Client WG. The Kf workgroup will focus on delivering the opinionated client experience while driving requirements and roadmap ideas into the Client, Serving, and Observability workgroups.

An initial OWNERS file would list Google, but we expect other names will be added as contributions are accepted.

Donation Checklist

• Original authors/owners decide a donation is appropriate
• Notification of proposal
  • Submit proposal to knative/community repo
  • Email notification of proposal sent to knative-users and knative-dev
• Approval of adoption by Knative committees
  • Steering Committee approval on fit for the Knative project
  • Technical Oversight Committee approval to adopt the repo/code (as per its charter).
• Update code licenses
  • Apache License 2.0 applied to code
  • Creative Commons License 4.0 applied to documentation
• Relocate the repository
  • Create OWNERS file
  • Create AUTHORS file
  • Update copyright header to Copyright (C) 2019 The Knative Authors.
  • Verify that all contributors are Google CLA signatories
  • Adopt Google CLA bot

During the Steering Committee AMA on Jan 13th it was suggested that we create a space for users of Knative to show how they are using the project.

We are looking for a volunteer to organize this. Responsibilities include:

• Solicit demos from the community
• Set up meetings, publish recordings
• Review and merge demo's into a shared demo repository

Is Knative subject to US EAR？Can an enterprise in Entity list obtain and use Knative，eg. Huawei？

How do we feel about using an enhancement proposal process similar to KEP (https://github.com/kubernetes/enhancements/tree/master/keps)? We don't have to use all components of the KEP process. Here are the elements we can adopt easily:

• Using a repo (as opposed to google docs) for design docs organized by working groups. This makes these documents more easily findable, and users can cross reference these docs more easily.
• Define approvers and reviewers for design docs under each working groups. This will help us to have more discoverable records about the decisions we make.

@mattmoor WDYT?
FYI @maximilien

The steering committee should publish clear guidelines for which efforts are considered within scope for Knative and the Knative org.

Follow-up of #23
Because of knative/community, searching for knative-community comes up with only hits for the former and not the latter. I think a unique naming would be better and since it is so-far unused, now is the time if people agree.

Kubernetes has:

• kubernetes-sigs
• kubernetes-incubator (deprecated in favor of sigs)
• "associated repos" which are any repo that follows the guidelines and use the CLA bot

Given we don't have SIGs, closest is working groups, I think one of the following would be a better naming and all have no or sufficiently-low hits on search:

• knative-workinggroups
• knative-workgroups
• knative-wgs
• knative-adjacent
• knative-annex
• knative-supplement
• knative-incubator (does imply things will "grow-up" though)
• knative-sandbox

(Rejected -extension, -unofficial, & -contrib because of other search hits)

People who mentioned the name in the last issue:
@rgregg
@maximilien
@evankanderson
@mchmarny

https://github.com/knative/community/blob/762911a8659a1b91b7b23cfc8cf432d19b496a00/working-groups/WORKING-GROUPS.md
and
https://github.com/knative/community/blob/466425c8fddcc69d5d1dbb471099ed346ec793a6/WORKING-GROUPS.md

are near-duplicates. The Client WG meeting schedule appears to be fresher in the former though, and there may be other differences.

At a very minimum, those duplicates should be eliminated. I'd recommend, though, eliminating one of the pages, perhaps leaving behind a redirection to the other, and looking for references to the eliminated one to update them.

It would be great to have retention history for our Slack organization.

Some relevant issues here:

• kubernetes/community#372
• istio/istio#191

See #109 for details.

I believe the move to a sub-folder broke the links to mechanics/

Current

Only two folks in steering have access to the KnativeProject Twitter account. I'm also unsure if we have any other social media accounts.

Proposed

@rgregg suggested using TweetDeck so we can all have access to the KnativeProject Twitter account.

Current

Telemetry for the Knative website isn't viewable for folks outside of Google at the moment

Proposed

Move telemetry (I believe it's Google Analytics) to a Knative shared account

I couldn't find any docs that describe how/when people can use the Knative name and logo. We should probably say something about this.

For inspiration, see:
https://github.com/kubernetes/kubernetes/blob/master/logo/usage_guidelines.md
and
https://www.linuxfoundation.org/trademark-usage/

/cc @rgregg

I created this team to hold Akash, who lost privileges: https://github.com/orgs/knative/teams/tbd-group-for-triage-and-planning

His words on what he needs:

I need permission to maintain the hygiene our issues and milestones - triage issues, fix labels, fix milestones, create new milestones etc

Currently Eric and Paul are members of Knative Admin, but don't hold an official role on the Project.

We are trying to align levels of access with project roles, and this is an instance where we've likely uncovered folks implicitly performing important functions: https://docs.google.com/document/d/1pCLzTfNP5-_Z9taNK0W5hntyKbP4E5DI4-6n16GpyeU/edit#

https://github.com/knative/community/blob/master/mechanics/WORKING-GROUP-PROCESSES.md#running-a-working-group

Raised by @coryrc on the Jan 30th TOC meeting, there is currently not a documented process to have new repos considered for creation, and there should be.

And archive eventing-operator and serving-operator.

Ref: https://github.com/kubernetes/test-infra/tree/master/prow/cmd/peribolos

Peribolos allows the org settings, teams and memberships to be declared in a yaml file. GitHub is then updated to match the declared configuration.

/assign @evankanderson

Currently the SC is populated based on:

Seats on the steering committee are allocated based upon contribution to the project by an organization. No final decision has been made on the exact formula.

I think it is time to clarify this formula. Until the formula is clearly spelled out this does not feel like an open governance to me and with Google's majority of 4 seats, this feels too much like a Google project. This is starting to cause a perception issue in the large k8s/cloud-native community which I strongly believe needs to be addressed.

I would recommend to look at the way kubernetes setup the bootstrap committee and subsequently held elections.

The @googlebot CLA handling is broken for multi-authors and github suggestion acceptance.

We should make a Knative CLA that does not use the Google CLA so we can allow for correct handling of multi-contributors.

see knative/pkg#1066 for the typical broken interactions with @googlebot CLA.

As Knative approaches 1.0, I believe we need to separate the “core” stable repositories from rapidly iterating growth projects. The status quo is all the code is together in a single GitHub organization. At times, this makes it difficult to understand which repos are at a given level of stability and does enforce a very high bar for what can be donated into Knative.

This proposal is to create a new organization for our early days projects, which are not yet a core part of Knative, but experiments or growth projects taken on by a Knative workgroup. The goal is that most new repos are initially created in this organization instead of being created in the Knative official organization.

For the purposes of this proposal, I’m naming the new organization knative-workgroups although we may decide there is a better name for this collection of repos.

Contribution guidelines to knative-workgroups

When a new Knative project is spun up, or code is adopted into the project, the following guidelines should always apply:

• Clear ownership for the project exists within the community, ideally sponsored by one or more of the organizational entities backing the Knative project.
• An existing (preferred) or new workgroup takes responsibility for the project.
• A mission and vision for the project is reviewed by the Knative Steering Committee and approved as in-scope for the Knative project.
• For code donations, the project donation requirements are met.
• Regular project updates are provided on at least a quarterly basis to the TOC through the regular workgroup updates process.
• Project adopts the Knative Repository Guidelines, including the Knative Code of Conduct, the Apache License 2.0, the Google CLA bot, and the Knative Prow bot.

Many projects will not be accepted into either the knative or knative-workgroups organization. It is normal and expected that not all projects will meet the bar for inclusion in the broader Knative effort.

Community projects can and should adopt the Knative Code of Conduct even if they are not located under a Knative organization. These projects can be linked to from documentation or samples that are included in the organization. If a request to add a project to the knative-workgroups organization is rejected, this may be the recommended alternative.

Maintenance and support of projects

Projects in the knative-workgroups organization must maintain active engagement and support throughout their life span. The life cycle for a project is more tightly managed than the core repositories to prevent it from becoming a collection of unsupported code.

A project will be deprecated and archived when any of the following conditions are met:

• There is no clear ownership for the project and no one takes ownership within a 4 week grace period. When an owner abdicates ownership, they should formally share this change with the TOC and KSC.
• No activity has occurred within the project (commits, issues, PRs) or the communication channels (email, slack) within 3 months.
• Project owners agree that the project is no longer relevant, necessary, or has been made obsolete by another project.

Before a project is deprecated, a formal notice of intent to deprecate the project will be shared via the knative-dev mailing list. This is the last opportunity for an interested party to take ownership and keep the project alive.

When a project has been deprecated, the repo is marked as deprecated and archived-in-place.

Graduation

Projects in the knative-workgroups organization may be graduated into the Knative organization, at the discretion of the steering committee or its delegates. It should not be the expectation that this is the path for all projects in knative-workgroups. While there are no formal rules defined for when this occurs, it is implied that projects in the Knative organization have a level of maturity, stability, and usage comparable with the other projects located there. Decisions will be handled on a case-by-case basis.

Proposed projects

The following existing knative projects are proposed to be moved into the knative-workgroups organization, once it has been established.

• knative/eventing-contrib - Space for eventing team to have contributed code for eventing importers/sources
• knative/sample-controller - An example / template project for building knative-style controllers
• knative/serving-operator - This may have been developed enough at this point that it can stay in the knative org, but provides an example of something that would fit into the knative-workgroups org.

This issue is a takeaway from a steering F2F; issue is to clarify what the criteria / rules etc around TOC membership are.

I created this temporary team with elevated access to be resolved by steering: https://github.com/orgs/knative/teams/tbd-google-tech-writers/members

cc @rgregg

A question has come up a few times about the role that knative-sandbox plays. I know it's been discussed but seems like we never produced a more comprehensive description for it's role, what goes there and why instead of knative org, what is the process for moving things from sandbox to knative, etc.. Or, I just missed it, in which case we should just make the document easier to discover.
https://github.com/knative-sandbox

There should be vendor-neutral training materials for use by people learning Knative.

This is important for the growth of our community and has been a request to steering / TOC.

Please add the following meetings added to the Knative calendar (https://calendar.google.com/calendar/embed?src=google.com_18un4fuh6rokqf8hmfftm5oqq4%40group.calendar.google.com):

Knative tech talk @ Monthly from 1pm to 2pm on the fourth Wednesday (PDT)
Knative tech talk @ Monthly from 10am to 11am on the first Thursday (PDT)

Also, are the associated Hangouts for each meeting recorded? If so, are recordings posted to a central place or retroactively added as an attachment to the meeting invite?

Ryan got us a GSuite org. We need to do the following:

• Add new TOC / Steering members to the org
• Get calendar sharing working
• Get team drive working
• Document setup
• Update documentation

With the recent updates moving Knative to require k8s 1.15, we've made it difficult for many users to adopt Knative in their cloud platform of choice.

While our general principals for a minimum version of k8s are based on k8s supported versions (e.g. N-2 releases), the major cloud players are all lagging behind. With the requirement of 1.15 as the minimum version, we've effectively made it harder to use Knative with Amazon, Google, Azure, and others.

• Amazon's highest supported version of k8s is 1.14.0.
• Google has 1.16 in the Rapid channel, but the regular channel is still 1.14, and the default if not using channels is 1.13.
• Azure's default version is also incompatible, since they default to N-1, and choose 1.14 right now.
• OpenShift Container Platform's latest release is also using 1.14.

This means the current release of Knative is not compatible with any of the 3 major public cloud provider's default managed k8s versions. Out of the major contributors to the project, only IBM Cloud has a default that works with Knative.

This seems like the wrong place for a project that is pushing for customer adoption to be. I realize there is functionality in k8s 1.15 that made it easier to support Knative -- but as a general policy, it seems like sticking too close to k8s head is going to cause us considerable adoption challenges.

We should update the docs to make the path clear for new members who meet the requirements listed here: https://knative.dev/contributing/roles/#member

If a contributor meets the member requirements, what are the next steps?

Do sponsors simply email the steering committee ([email protected]) and what information is needed in that request?

As part of knative/pkg#883, we use a very simple wrapper to redirect uses of klog or glog into our Zap logger. Because of the dep tool, these wrappers must be in their own repo (otherwise they'd simply be a directory of knative/pkg).

I have forked the repos and attempted to upstream into the Istio project repositories, but it isn't something they seem keen on supporting. I'd like to open these repos in our knative-community project.

These are very small shims and I don't anticipate more than one change every six months. The glog project is abandoned and klog's goal is to remain compatible with it, so we should not be seeing any changes.

Current State

Only Googlers have the "Workspace Owner" role in the Knative Slack group. All the other steering members and TOC members have the "Workspace Admin" role.

Proposed State

All steering members should be "Workspace Owners" of the Knative Slack.
TOC members should remain as Knative Workspace Admins.

Currently, WG leads/approvers can self remove themselves but it's unclear what the process is for the community to remove a WG lead/approver.

Let's:

• Document that we expect folks to self remove themselves as the default process
• Document what process community members should follow to remove a WG lead/approver

To remove Sam.

The release artifacts for github.com/google/knative-gcp are published into gs://knative-{releases,nightly} and gcr.io/knative-{nightly,releases}.

Either Google should stop doing this, or access should be opened up for other vendors to publish integrations here. My preference would be to limit what's published here to what lives in the upstream organization(s).

See also: https://github.com/knative/docs/pull/2220/files#r379840405

Objective

Pivotal proposes to donate Skenario to the Knative project.

Our motivations are:

• To increase community awareness of Skenario,
• To broaden Skenario's contributor base, and
• To apply Skenario to more development problems.

Background

Skenario is a simulator harness developed to provide feedback on the Knative Pod Autoscaler (KPA). It was inspired by experiences of developing a simulator for the original Project riff autoscaler (before Knative Serving was adopted as a foundation layer). Skenario provides a general purpose simulator engine for executing scenarios and collecting results, plus a model built on that engine which drives the KPA.

It provides a CLI trace interface for debugging and a web GUI which shows graphical displays of autoscaler behaviour. The web GUI enables rapid exploratory examination of hypotheses about autoscaler behaviour.

Further history and motivation can be found in the original issue in the Knative Serving repo. Also available is a detailed discussion of the simulation concepts underlying Skenario.

Currently

Skenario is able to drive the 0.5 release of the KPA. Driving 0.6 and up is blocked pending further investigations of changes needed in the KPA to ease integration.

Skenario is worked on by a single Pivotal engineer (@jchesterpivotal) on a best-effort basis, ramped down from a fulltime effort.

There are seven open issues.

Future directions

Use in "headless" usecases

While currently oriented towards interactive, exploratory use by developers, Skenario could be adapted for automated use as well. It could be used in test suites to predict performance regressions before testing. It could also be used as the evaluation function for optimisation tools searching an increasingly large parameter space.

Application to other problems

As noted above, Skenario's design separates the simulator engine from the simulation model. This design means it could be applied to other simulation problems of interest. We currently foresee two additional applications for Skenario.

Development of other autoscalers

We believe that a model can be developed to drive the Kubernetes Horizontal Pod Autoscaler. It's likely that parts of this model could be shared with the KPA model, especially as simulation elements for nodes and image placement are added.

Development of systems using Knative Eventing

Skenarios central concepts of Stocks and Movements appears to be suited to simulating the behaviour of Eventing systems under various conditions. This application was held in mind when designing Skenario. It would require additional engineering so that constructing models does not require much, if any, custom code to be written.

The goal of such a use would be to enable application developers to understand the dynamic behaviour of Eventing systems in general; and to identify potential bad behaviour or optimisation opportunities in particular.

Process of donation and adoption

Skenario would fall under the scope of the Scaling WG. An initial OWNERS file would list Pivotal, but I expect other names will be added (eg. Google) as contributions are accepted.

Checklist

1. Approval of donation
   1. Relevant stakeholders at Pivotal have agreed to donation.
2. Notification of proposal
   1. Submit proposal to knative/docs repo
   2. Email notification of proposal sent to knative-users and knative-dev
   3. Discussion of proposal in Autoscaling WG
3. Approval of adoption
   1. Technical Oversight Committee approval to adopt Skenario as a sub-project (as per its charter).
4. Repository relocation
   1. Apache License 2.0 applied to code
   2. Creative Commons License 4.0 applied to documentation
   3. Remove Pivotal-standard CONTRIBUTING.md file
   4. Relocate the repository from pivotal/skenario to knative/skenario
   5. Create OWNERS file
   6. Create AUTHORS file
   7. Update copyright header from Copyright (C) 2019-Present Pivotal Software, Inc. to Copyright (C) 2019 The Knative Authors.
   8. Verify that all contributors are Google CLA signatories
   9. Verify that all contributors are CNCF CLA signatories
   10. Adopt Google CLA bot

Current

All the infrastructure used by the Productivity WG is currently inaccessible to people outside of Google

Proposed

TBD.

Notes

• We've previously discussed sharing the cost of infrastructure at the steering level. Let's revisit this conversation to see how we might want to approach this.
• I believe folks outside of Google also cannot submit performance metrics to mako.dev

Objective

Scott Nichols proposes to donate discovery to the Knative project.

Background

As part of trying to solve the Sources WG mission for understanding:

1. What sources are installed in my cluster?
2. What instances of those sources are running in my cluster?
   • and what is their current state?

I wrote a PoC that adds a new API Group to Kubernetes called discovery.knative.dev and first pass implemented a new Resource called DuckType. This resource in combination with another tool like kubectl duck allows me to answer the above questions.

Current Status

The code is written to Knative standards, though needs more overall testing (more than you would do for a PoC). discovery was presented to the Knative Client working group mid January, 2020 and the reception was overwhelmingly positive and the client WG would like to use it as a base for understanding some of the ducktypes we have been implementing in Knative (Addressable, Subscribabe, Source, etc).

Future Directions

This is a PoC focused around the DuckType concept, but there are other things that we would like a hook into a cluster for api-based discovery. Such as add-on locations: I know I want an addon that provides a feature, "how do I find it to install?"

Discovery might also grow to include some UI component that allows for cluster understanding, such as an evolved form of graph which is heavly DuckType based.

Initial Roadmap

• Develop out and release DuckType
• Work with Client WG on integration with DuckType
• Pitch discovery as a general solution for cluster resource understanding (bring your own ducktypes).

Process of donation and adoption

I propose that discovery be led by the Sources WG at the start in a new repo: knative/discovery. We will focus on bringing DuckType to market and enabling complex client interactions scoped to eventing for now.

An initial OWNERS file would list the Sources WG Leads, but we expect other names will be added as contributions are accepted.

Donation Checklist

• Original authors/owners decide a donation is appropriate

• Notification of proposal

  • Submit proposal to knative/community repo
  • Email notification of proposal sent to knative-users and knative-dev

• Approval of adoption by Knative committees

  • Steering Committee approval on fit for the Knative project
  • Technical Oversight Committee approval to adopt the repo/code (as per its charter).

• Update code licenses

  • Apache License 2.0 applied to code
  • Creative Commons License 4.0 applied to documentation

• Relocate the repository

  • Create OWNERS file
  • Create AUTHORS file
  • Update copyright header to Copyright (C) 2019 The Knative Authors.
  • Verify that all contributors are Google CLA signatories
  • Adopt Google CLA bot

There's a nice donation checklist that a few people have used in their Issues to donate code to the Knative project. However, this template and the actions required by it are not spelled out anywhere in the repo guidelines.

We should clean that up into a documented process, instead of a shared knowledge thing.

Relative peer links are now broken after the move to knative/community.

Examples:

• ../docs (ie. [knative/docs](../docs)) must now be fully qualified and point to the docs repo -> "https://github.com/knative/docs"
• similarly, any links to the community samples are broken too: [Community Samples](../community/samples/README.md) -> "https://github.com/knative/community/samples/README.md"

https://github.com/knative/community/search?q=build&unscoped_q=build

It would be great to have official icons for each Knative CRD (Service, Revision, Channels, Brokers, etc.) so that they can be used in service architecture diagrams and UIs to represent Knative resources.

Creating this issue in community as:

1. Icons seem like "community material"
2. Likely needs Steering Committee support as it relates to the Knative brand

cc @bbrowning @mattmoor

Currently the Knative Milestone Maintainers group is used by Prow to gate access to /milestone commands. I'd like guidance on how this aligns with our project roles, but it is also plausible that we should simply be more open and allow org members use this until it becomes a problem.

From the TSC md file:

The Knative Steering Committee (KSC) is the ultimate authority for the Knative project, and governs all aspects of the project.

We need to update this sentence to more accurately reflect reality, then people can decide if they want to join, or continue to work, on a project with that governance model. Regardless of whether people agree or disagree with the model, we should at least be honest about what it is.

/assign @lindydonna

The Knative GitHub permissions are in dire need of some cleaning and rethinking. @mattmoor has offered to help clean this up :)

Proposal here.

Current State

The Knative GSuite tools use the google.com domain at the moment. This affects:

• Google Drive
  • Folks outside of Google can't control the ownership of the community drive itself
• Knative Community Calendar
  • Folks outside of Google have read/write access but don't have admin privileges
• Hangouts
  • We still use Hangouts for a lot of WG meetings which require someone from Google to let folks into the meeting
• Google Groups
  • I believe all the knative-* google groups are tied to the google.com GSuite org as well

Proposal

Create a knative.dev GSuite org for the community and shift all the community owned artifacts to this org.

Steps

• Add new TOC / Steering members to the org
• Get calendar sharing working
• Get team drive working
• Document setup
• Update documentation