Sandbox Naming Redux about toc

[monadic]

voting will be on the list

[caniszczyk]

I will send a vote out via CIVS (condorect style) later this week, I'd like to limit it to only the TOC and TOC Contributors as discussed above. The results will be public.

[jbeda]

The Kubernetes incubator is being deprecated and is generally seen to have not worked particularly well. There are multiple reasons -- the low bar is one. Another is an expectation that there is a formulaic path to graduation. The final reason is that folks were joining looking for an endorsement vs. a real connection to ongoing core work.

Things are moving in the direction of a 3 tiered project system. @brendandburns has been driving this:

• Official parts of Kubernetes core/nucleus
• SIG sponsored projects whereby the SIGs have authority to start them as they are relevant to the SIG charter.
• "Associated Repositories" whereby projects can use some of the Kubernetes plumbing (CLA, CoC, other tooling) but there are no voting requirements.

I'm not sure if this has any lessons for the CNCF ToC to be honest. My preference: either have sandbox/workshop/whatever have essentially no bar (and the implications of that) or embrace some level of endorsement and keep the voting. Lowering the bar seems to be a half measure that may not serve any requirement.

[leecalcote]

Vote here or await a mailing list invitation?

[yurishkuro]

"Launchpad" was another suggestion somewhere last week.

[jbeda]

Some comments as I won’t be eligible to vote. One question: Was there anything out of the ToC meeting around voting in these projects? There were concerns at the GB meeting around lowering the bar wrt 2 votes vs a full vote. Is that still the case? As far as naming — I’d prefer a name that says “early but promising” but not “experimental”. To attract the right projects you want projects that are serious. With that in mind, I’m not a fan of “Sandbox” or “Labs”. “Prototype” also implies that it is something that will be thrown away in favor of the “real” thing. I heavily favor “Workshop”. Joe

…

On Tue, Mar 6, 2018 at 8:43 AM Chris Aniszczyk ***@***.***> wrote: At today's @cncf/toc <https://github.com/orgs/cncf/teams/toc> call the TOC wants to hold a vote amongst itself and the TOC Contributors: - Sandbox - Workshop - Labs - Prototype Was there anything else I missed @monadic <https://github.com/monadic> ? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#95>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACRvt-4YlQWe6GOWIgrih3xWAg3JxPwks5tbryfgaJpZM4SfCc3> .

[josephjacks]

I’m also not a fan of “Sandbox”; it implies untested software. Exactly how low is this bar expected to be? As the criteria / definition materializes, I think the name will become pretty important. “Lighthouse” could work as it points to the future, promise and shedding light for incoming vessels. I like “Workshop”, too. JJ

…

On Mar 6, 2018, at 9:12 AM, Joe Beda ***@***.***> wrote: Some comments as I won’t be eligible to vote. One question: Was there anything out of the ToC meeting around voting in these projects? There were concerns at the GB meeting around lowering the bar wrt 2 votes vs a full vote. Is that still the case? As far as naming — I’d prefer a name that says “early but promising” but not “experimental”. To attract the right projects you want projects that are serious. With that in mind, I’m not a fan of “Sandbox” or “Labs”. “Prototype” also implies that it is something that will be thrown away in favor of the “real” thing. I heavily favor “Workshop”. Joe On Tue, Mar 6, 2018 at 8:43 AM Chris Aniszczyk ***@***.***> wrote: > At today's @cncf/toc <https://github.com/orgs/cncf/teams/toc> call the > TOC wants to hold a vote amongst itself and the TOC Contributors: > > - Sandbox > - Workshop > - Labs > - Prototype > > Was there anything else I missed @monadic <https://github.com/monadic> ? > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#95>, or mute the thread > <https://github.com/notifications/unsubscribe-auth/AACRvt-4YlQWe6GOWIgrih3xWAg3JxPwks5tbryfgaJpZM4SfCc3> > . > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[caniszczyk]

@yurishkuro I'll add it to the list, I will kick off the vote on Thursday to give some time for people to comment, the TOC will than take that as an input at the next TOC meeting to make their final decision, thanks

[bgrant0607]

@caniszczyk Did voting start on this yet?

[caniszczyk]

I will start the voting on Monday with the names suggested, close it the following Monday before the TOC meeting.

…

On Fri, Mar 9, 2018 at 11:03 AM, Brian Grant ***@***.***> wrote: @caniszczyk <https://github.com/caniszczyk> Did voting start on this yet? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#95 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD5IdxhJ0-oZu2YavrGHbPVOscGB_V6ks5tcrXhgaJpZM4SfCc3> .

-- Cheers, Chris Aniszczyk http://aniszczyk.org [phone]

[monadic]

@jbeda thanks for the comments.

One of (several) objectives for the entry level tier is to have a place for existing projects to initiate prospective extensions, as with this - https://github.com/kubernetes/community/blob/master/incubator.md ... which makes it very hard to have an objective quality bar. Notice that k8s incubator also has two sponsors. I do understand that this means two projects of differing quality can both be Entry level, but this has been OK for k8s-incubator and other non-CNCF models.

The reality is that Inception was being seen (spun?) as "will make it to Incubation and Graduation" and that really muddied the waters and upset a lot of people. That created a strong motivation to get away from too much "voting" and other trappings of Incubation/Graduation.

Personally, I feel we need to set a really clear bar at Incubation and use the entry level to help projects reach it as best we can, as a community and organisation. Without making out that those entry level projects are guaranteed to succeed. Some may not make it, and get pruned out.

LMK if this is helping.

[monadic]

Yes, I am aware that k8s incubator is being deprecated and why. This is one of the reasons we are tidying up the entry level tier. K8S and other major CNCF projects are big enough to need quite a lot of ramified machinery ranging from (as you say) core pieces to various associated pieces. So we need a flexible system that allows that, and keeps projects in control of their own governance. Also some projects don't quite fit into the model you set out above. cc @bgrant0607 for more thoughts on this.

Concerning "looking for an endorsement vs. a real connection to ongoing core work". That's a good statement of the Inception downside that we ran into last year. Whether a new project is attached to an existing CNCF project (eg K8S, Prom) or its own thing, or tied to a WG, we run into the same problem.

All this is caused by having a high bar for graduated work. Whether within K8S, or within the CNCF tent, we want Incubated/Graduated to mean something important, especially: quality and real use. But as soon as we accept this, we also accept that we have no way of helping "early" projects that have not unambiguously proven these things.

That means that we have to choose between 1. no entry level, which has multiple negative consequences, and 2. having a lower bar. We can live with a lower bar if we 3. really try to help projects, and 4. are honest about pruning out the projects that don't make it to the next stage.

Like you I think that lowering bar should not be a halfway solution. There was debate about this, and we landed where we are. I think it's OK. We'll have this model, PLUS things like Brendan's hierarchy for "intra project incubation". And we can iterate when we know more.

I hope this helps.

[bgrant0607]

Problems with K8s incubator as I saw them:

1. People wanted to move their existing projects under Kubernetes, for endorsement, attracting contributors, leveraging our community infrastructure (slack, meetings, etc.), and other reasons. However, the Kubernetes project wasn't really equipped to accept outside projects, process-wise, legally, etc. The CNCF is.
2. Projects shopped for their Sponsor. They'd contact each top-level owner privately until someone said yes, after others declined or objected. This is a danger for the 2 TOC Sponsors, but can be mitigated by discussing prospective projects among the whole TOC, so that concerns can be heard.
3. We didn't have processes in place to govern the projects. The connection to SIGs was loose. In CNCF, projects would be self-governing, and regularly project views and tools like devstats help with oversight.
4. Graduation criteria and process were underspecified. Basically it was up to the Sponsor to decide whether the criteria were met. CNCF has a process for accepting projects into the incubator, with documented criteria and diligence guidelines, and a vote of the whole TOC.

[caniszczyk]

We've decided on the initial v1.0 of the sandbox guidelines here:
https://github.com/cncf/toc/blob/master/process/sandbox.md

We can also update them over time, I actually encourage we look at our governance on an annual basis.