Proposal: Create a knative-workgroups organization for early-days projects

[rgregg]

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.

[maximilien]

Love ❤️ it. Few minor suggestions and comments.

What about naming it knative-community as a more welcoming and broader name that implies workgroups and others outside the WGs (eventually) as we get to v1.0?

By the same spirit we should also create knative-attic or knative-archive (as you suggested) for retired projects. Might as well have that now.

I also like the guidelines. I would have liked to see up front a simple process for how projects can be proposed, voted on, accepted to the community and how they are retired. However, we can add details later.

---

Anyhow, overall I like it and above comments are suggestions, and should not stop moving this forward. Good topic for the next TOC. Cheers 🍻

[vaikas]

Great idea. Is the plan then to create this organization and then there define what the process is for saying, hey our project XYZ should be included?
re: knative/eventing-contrib just curious about moving it there in the first place as in just concerned about seemingly unnecessary churn in the codebase.

[rgregg]

The requirements for "should XYZ be included" are defined in Knative community. i.e. I'd expect that the process for creating a new repo is the same as it is today, either a repo donation, or a community proposal posted here. Steering and/or TOC would make the decision about where to put it.

The repos listed at the end are more about evaluating what we have now and recommending which would have been created in knative-workgroups if it existed. If there's a significant impact to moving them we wouldn't need to make that decision.

[evankanderson]

I'm substantially in favor of this proposal; I'm fine with either -workgroups or -community and don't want to bikeshed it too much. Thanks for writing this up!

…

On Thu, Jul 25, 2019 at 3:51 PM Ryan Gregg ***@***.***> wrote: The requirements for should XYZ be included are still defined here. I'd expect that the process for creating a new repo is the same as it is today, either a repo donation, or a community proposal posted here. Steering and/or TOC would make the decision about where to put it. The repos listed at the end are more about evaluating what we have now and recommending which would have been created in knative-workgroups if it existed. If there's a significant impact to moving them we wouldn't need to make that decision. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#23?email_source=notifications&email_token=AB4XENYBSKZTOADLY2WNKLLQBIU7TA5CNFSM4IG44TNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD227XUY#issuecomment-515242963>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB4XEN4ZRJN6JDCVWFNLS4LQBIU7TANCNFSM4IG44TNA> .

-- Evan Anderson <[email protected]>

[josephburnett]

I would like to also propose Skenario for knative-workgroups: #18

[jchesterpivotal]

re: knative/eventing-contrib just curious about moving it there in the first place as in just concerned about seemingly unnecessary churn in the codebase.

One of the arguments I gave for a vanity URL is that you can avoid this churn: knative.dev/foo can first redirect to github.com/knative-workgroups/foo and then, if it graduates, to github.com/knative/foo.

We did this for Cloud Foundry's various orgs and it is a godsend.

[mikehelmick]

I am also in favor of this.

[dprotaso]

(Not sure if it warrants a separate issue)

For projects that are going to be archived (ie. knative/build) should we shunt them to another GitHub organization in order declutter the knative org?

CF has an attic for this purpose https://github.com/cloudfoundry-attic/

And as @jchesterpivotal pointed out the vanity url facade could handle redirecting to the appropriate org

[rgregg]

I'd suggest we handle that as a separate issue. I would also wait until there's a problem that we're trying to solve (e.g. too many archived repos cluttering up GitHub) before we add additional organizations, since the 'cost' of adding an org is non-zero for the EngProd team.

[mchmarny]

The proposal sounds reasonable to me. Also +1 on -community

[rgregg]

This proposal was voted on by the Steering Committee and has been approved.

[rgregg]

https://github.com/orgs/knative-community has been created.

[coryrc]

I know this is already done, but because of knative/community, it's hard to web search for knative-community (as opposed to knative-workgroups, the only hit being this issue itself).

[rgregg]

Cory, do you want to open an issue to rename knative-community to knative-workgroups?