Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
rgregg opened this issue Jul 25, 2019 · 14 comments
Closed

Comments

@rgregg
Copy link
Contributor

rgregg commented Jul 25, 2019

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
Copy link
Contributor

maximilien commented Jul 25, 2019

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
Copy link
Contributor

vaikas commented Jul 25, 2019

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
Copy link
Contributor Author

rgregg commented Jul 25, 2019

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
Copy link
Member

evankanderson commented Jul 26, 2019 via email

@josephburnett
Copy link

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

@jchesterpivotal
Copy link
Contributor

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
Copy link
Contributor

I am also in favor of this.

@dprotaso
Copy link
Member

(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
Copy link
Contributor Author

rgregg commented Aug 1, 2019

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
Copy link
Member

mchmarny commented Aug 1, 2019

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

@rgregg
Copy link
Contributor Author

rgregg commented Aug 13, 2019

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

@rgregg
Copy link
Contributor Author

rgregg commented Aug 13, 2019

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

@rgregg rgregg closed this as completed Aug 13, 2019
@coryrc
Copy link

coryrc commented Jan 27, 2020

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
Copy link
Contributor Author

rgregg commented Jan 28, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants