Date   

Re: [VOTE] Rook Graduation

Jeff Billimek
 

+1 NB


Re: [VOTE] TiKV Graduation

Wink Yao
 

+1 non-binding


Re: Proposal for a new "Steering Committee Charter"

Derek Collison <derek@...>
 

I think as the CNCF was formed its vision was to guide an end user ecosystem and to assist projects to navigate and gain acceptance with the end users.

For the end users, they look to the CNCF for guidance around which projects and technologies they should consider. In my opinion these projects should add value and solve a specific problem, be production proven, be security minded, and should minimize risk to the end user who is adopting. I believe our area of concern on graduating status and this email thread is specific to reducing risk to the end user who is adopting a technology or project. I also believe that the list I presented is in priority order, at least for me, meaning that minimizing risk is important but behind the others.

Even within the risk category, I believe looking at this from an end user perspective the things they probably care about are as follows. 
Note this assumes basic market forces are at play and that a project is popular or applicable to a large enough audience, meaning users are voting with their feet.

End user concerns around risk

1. Can I continue to use the software as I see fit (no license changes).
2. Is the software supported such that issues and/or bugs are addressed by the project.
3. If the project is missing features will the project ecosystem move forward in a way that aligns with my needs as an end user.

We have #1 covered, so I believe the debate is around #2 and #3 and how the CNCF sees projects that it moves to a graduated status. 

This is the main issue of debate. How does the CNCF suggest end users look at #2 and #3. 

Right now the guidance is around a fairly specific project profile that does not take into consideration ISV led projects, and more importantly mature ISV led projects. I believe the CNCF should promote a diverse set of projects, including ones that are led by ISVs.

For certain projects diverse maintainers and multi-vendor participation can help with #2 and #3, but it's not black and white by any stretch, even when the project profile aligns well. The idea of a steering committee was to see if we could help with guidance to the end user community on de-risking #2, but mostly #3 around ISV led projects.

The CNCF should be seen as a good steward of the ecosystem and the things end users and project maintainers should be aware of and prioritize, but it should be careful not to be a gatekeeper.

Speaking from my personal experience with NATS, I would like to see more conversation and debate on ways to support ISV projects and companies trying to make a viable business from OSS as something the CNCF wants to support. This in addition to the large multi-vendor projects like k8s. NATS is older than any other project in the CNCF, it has been downloaded over 120M times, so it has been around and even prospered as an ISV led project (although by 3 different companies now). I believe the project and ecosystem have done a good job at minimizing risk on #2 and #3 over the last decade. 

For #3 we have been engaging with the ecosystem and providing early access to new features through design docs and early tech previews to gain an understanding of what the end user ecosystem is interested in. That ecosystem can include other large vendors and actually does. We feel the steering committee idea could be a path forward to help formalize that part of the governance of the project and be beneficial to the end user ecosystem.

For the NATS project, and for all projects, I think as issues and bugs and new features want to be added, you always want the best folks working on those problems and care should be taken to not have incentives that go against that outcome. Our end users do not want to fix bugs and code new features, they want the maintainers to do so. Note that many times this is the best use of time and financial resources for the end user. If it is not, that usually suggests a project is not being properly maintained. NATS is not open core, and we have a diverse set of contributors across the board, especially for the nearly 40 different client implementations. But we do lead development and new features for the server, but I do not think this is a bad thing and I do not believe anyone wants to game the current system to progress through the CNCF. I think a steering committee can help formalize a process for #3 to make sure that it's aligned with the ecosystem and that end users (including other vendors) are represented.  In the end users will vote with their feet regardless.

My hope is that ISV led projects are an important diversification for the projects that make up the CNCF and that the discussion around how best to support them through the CNCF journey continues.


On Thu, Jul 9, 2020 at 11:04 AM alexis richardson <alexis@...> wrote:
Folks

The issue we are facing here is how to make projects, and hence the cncf, sustainable.  As Quinton pointed out this requires incentives.  Marketing buzz is short lived and sponsors will move on to the next thing, if there isn't an economic system to help the ecosystem. 

We have seen this before in various forms, including asf, esf, and openstack.  Ultimately these foundations need to make it possible for enough actors to make money or it is really hard to keep going.   Openstack made it too hard to differentiate.  Eclipse got bogged down in tools.  Apache is overrun by bureaucracy and placepeople, and is overprotective of its marks in the name of "open source".  

When we formed cncf we wanted something better that learned from all the prior art.  CFF was quite interesting and had created terrific end user interest, but lacked diverse projects. It was basically CF plus libs and addons. 

CNCF is not Kubernetes plus addons.  Yes k8s is our sun.  But many use cases don't use or need it, and this also helps users.  In addition ISVs like Hashicorp can see value for integration of their suite with multiple points in CNCF. 

If you look away from the bright light of k8s, you see a diverse range of projects.  Many come from ISVs, and some from end users.  

Can i suggest that we listen to these ISVs about what works *for them* and without assuming that they want to game the system or corrupt the ideals of this foundation. 

Please. 

Alexis 







On Thu, 9 Jul 2020, 18:48 Jaice Singer DuMars, <jdumars@...> wrote:
As an observer, I think this is a very solid analysis and recommendation. The risk of a "rubber stamp" steering committee is a serious concern, and clearly doesn't resolve the underlying challenge of meaningful corporate diversity among maintainers. 

That said, I do believe a standardized steering committee template has value though, especially for projects reaching the natural governance evolution where one makes sense. It's easy to forget that the Kubernetes steering committee was a response to community distress as documented in the contributor survey at the time. Having a vetted and well thought-out charter to start from can limit the time needed to resolve governance friction.

Is this working group going to suggest an alternative? 

On Thu, Jul 9, 2020 at 9:59 AM Josh Berkus <jberkus@...> wrote:
As promised, we had an in-depth discussion of the Steering Committee
proposal drafted by Alexis Richardson for the July 7th TOC meeting
during the Governance WG meeting.  Six members were present and
participated in the discussion; notes are available here:
https://docs.google.com/document/d/e/2PACX-1vSfiN1PRL3dH_ohfAs1lYvNWaBpAdvAI-9OQZYYIx8ahgy6230_oRbqljl6dUiGf5hTVJiferJgBmSX/pub

Assessment:

Regarding the specific proposal of using steering committees (SC) as a
workaround for the requirement to have maintainers from multiple
organizations for projects to move to the Graduated level, the
Governance WG recommends that the TOC not adopt it.

Full explanation:

Steering Committees are frequently important governance tools for large
and distributed projects, and more projects should consider having one
as a channel for end-user, collaborator, and diverse audience
representation.  We valued Alexis’ writeup, and would like to
incorporate it into our handbooks in progress for CNCF projects on how
to develop governance.

Projects that would need the "SC workaround" are projects that have been
unable to attract a single maintainer from outside the original
sponsoring organization, which is usually a sign of serious issues
within the project. The Governance WG feels that the CNCF ecosystem is
ill-served by moving projects with such problems to the Graduated level,
and the proposal will not have the desired outcomes.

Our decision was based on what we view as the inability of a
non-technical Steering Committee to ensure that a project with
maintainers* exclusively employed by the same organization treat
submissions, roadmap items, and maintainer candidates from other
organizations fairly.  Even diligent SC members would find it difficult
to understand enough about technical architecture decisions to
differentiate between bias and legitimate objections in reviews.
Further, unlike code and docs maintainers, it would be challenging for
the TOC to monitor activity and involvement levels of SC members, as
that would not create the same kind of contribution trail.

For this proposal, we considered specifically projects that are having
problems attracting contributors, because only such projects would need
this mechanism. It certainly takes time to bring code reviewers up to
speed, but the current requirement is a low bar; even a single dedicated
documentation leader from an end-user company would technically satisfy it.

While many folks have cited the Kubernetes project as an example,
Kubernetes has a diversity of maintainers all the way down to the SIG
level, so it would qualify for a maintainer multi-org requirement even
without a Steering Committee. At this point, the Governance WG does not
know of a good example of a project that successfully has used an SC to
moderate the influence of development being dominated by a single
company, so doing so would be experimental. As an experiment, we might
adopt it for one specific project, but we'd want to see the outcome of
that before we adopt it as general policy.

Even Alexis’s document suggests that in problem cases it would be up to
the TOC or their delegates to intervene to resolve project problems.
Given this, it’s unclear what advantage having an SC would offer over
Alexis’s original suggestion of having designated TOC monitors.

Overall, our judgement was that adopting the SC workaround would be, in
essence, removing the maintainer multi-organization requirement, and
that it would be better to simply remove the requirement instead if that
is the direction the TOC wishes to go.

Drafted by Governance WG:
Josh Berkus
Dawn Foster
Jennifer Davis
Davinum Srinivas
Paris Pittman

(* by “maintainers” we mean involved, leading contributors with the
authority to merge code, docs, and/or community materials into any of
the key repos belonging to the project.  Such contributors may be called
"maintainers", "committers", or other titles.  It does not refer to the
official CNCF maintainer list for voting purposes, as that list contains
many people who do not have merge authority in their individual projects.)


--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO





Re: Cortex Public Comment Period

Richard Hartmann
 

With my SIG o11y chair hat on: I am 100% endorsing moving Cortex to incubation.


Re: Thanos Public Comment Period

Richard Hartmann
 

With my SIG o11y chair hat on: I am 100% endorsing moving Thanos to incubation.


Re: [VOTE] Tech Lead nomination for SIG Observability: Bartłomiej Płotka

Richard Hartmann
 

+1 NB

On Fri, Jul 10, 2020 at 12:45 AM Amye Scavarda Perrin <ascavarda@...> wrote:
Matt Young and Richard Hartman of SIG Observability have nominated Bartłomiej Płotka as Tech Lead.
https://lists.cncf.io/g/cncf-toc/message/4592

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

--
Amye Scavarda Perrin | Program Manager | amye@...


Cortex Public Comment Period

Katie Gamanji
 

Hello,

Cortex has applied to move to the suite of incubation projects: https://github.com/cncf/toc/pull/315.

I am the TOC sponsor for Cortex 
(further comments here), and after completing the DD, I am opening the public comment period


The public comment period is now open for 2 weeks, and all SIGs, end users, TOC members, and community members are welcome to comment by replying to this thread.

Katie Gamanji
Attachments are


Re: [VOTE] Tech Lead nomination for SIG Observability: Bartłomiej Płotka

Nikhita Raghunath
 

Big +1 (NB) from me!

On Fri, Jul 10, 2020 at 4:15 AM Amye Scavarda Perrin <ascavarda@...> wrote:
Matt Young and Richard Hartman of SIG Observability have nominated Bartłomiej Płotka as Tech Lead.
https://lists.cncf.io/g/cncf-toc/message/4592

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

--
Amye Scavarda Perrin | Program Manager | amye@...


Re: [VOTE] Tech Lead nomination for SIG Observability: Bartłomiej Płotka

Stephen Augustus
 

+1 NB


On Thu, Jul 9, 2020, 18:45 Amye Scavarda Perrin <ascavarda@...> wrote:
Matt Young and Richard Hartman of SIG Observability have nominated Bartłomiej Płotka as Tech Lead.
https://lists.cncf.io/g/cncf-toc/message/4592

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

--
Amye Scavarda Perrin | Program Manager | amye@...


Re: [VOTE] Tech Lead nomination for SIG Observability: Bartłomiej Płotka

Oleg Chornyi
 

+1 NB

--

Oleg Chornyi, CTO

ventuscloud.eu


From: cncf-toc@... <cncf-toc@...> on behalf of Amye Scavarda Perrin via lists.cncf.io <ascavarda=linuxfoundation.org@...>
Sent: Friday, July 10, 2020 1:45 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] [VOTE] Tech Lead nomination for SIG Observability: Bartłomiej Płotka
 
Matt Young and Richard Hartman of SIG Observability have nominated Bartłomiej Płotka as Tech Lead.
https://lists.cncf.io/g/cncf-toc/message/4592

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

--
Amye Scavarda Perrin | Program Manager | amye@...


[VOTE] Tech Lead nomination for SIG Observability: Bartłomiej Płotka

Amye Scavarda Perrin
 

Matt Young and Richard Hartman of SIG Observability have nominated Bartłomiej Płotka as Tech Lead.
https://lists.cncf.io/g/cncf-toc/message/4592

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

--
Amye Scavarda Perrin | Program Manager | amye@...


Re: Sandbox annual reviews

Katie Gamanji
 

Absolutely! +1 


On Thu, Jul 9, 2020 at 4:57 PM Alena Prokharchyk via lists.cncf.io <aprokharchyk=apple.com@...> wrote:
+1, sounds like a logical thing to do.

-alena.

On Jul 9, 2020, at 1:58 AM, Liz Rice <liz@...> wrote:

Now that we have the new Sandbox application process running, it might make sense to make similar tweaks to the Sandbox annual review process too. Specifically I'd like to suggest: 

* Moving from three sponsors to a simple TOC majority vote
* A regular cadence to review & vote on these, so that projects know when they can expect to get feedback

Wdyt? 
Liz 

 



Re: Proposal for a new "Steering Committee Charter"

alexis richardson
 

Folks

The issue we are facing here is how to make projects, and hence the cncf, sustainable.  As Quinton pointed out this requires incentives.  Marketing buzz is short lived and sponsors will move on to the next thing, if there isn't an economic system to help the ecosystem. 

We have seen this before in various forms, including asf, esf, and openstack.  Ultimately these foundations need to make it possible for enough actors to make money or it is really hard to keep going.   Openstack made it too hard to differentiate.  Eclipse got bogged down in tools.  Apache is overrun by bureaucracy and placepeople, and is overprotective of its marks in the name of "open source".  

When we formed cncf we wanted something better that learned from all the prior art.  CFF was quite interesting and had created terrific end user interest, but lacked diverse projects. It was basically CF plus libs and addons. 

CNCF is not Kubernetes plus addons.  Yes k8s is our sun.  But many use cases don't use or need it, and this also helps users.  In addition ISVs like Hashicorp can see value for integration of their suite with multiple points in CNCF. 

If you look away from the bright light of k8s, you see a diverse range of projects.  Many come from ISVs, and some from end users.  

Can i suggest that we listen to these ISVs about what works *for them* and without assuming that they want to game the system or corrupt the ideals of this foundation. 

Please. 

Alexis 







On Thu, 9 Jul 2020, 18:48 Jaice Singer DuMars, <jdumars@...> wrote:
As an observer, I think this is a very solid analysis and recommendation. The risk of a "rubber stamp" steering committee is a serious concern, and clearly doesn't resolve the underlying challenge of meaningful corporate diversity among maintainers. 

That said, I do believe a standardized steering committee template has value though, especially for projects reaching the natural governance evolution where one makes sense. It's easy to forget that the Kubernetes steering committee was a response to community distress as documented in the contributor survey at the time. Having a vetted and well thought-out charter to start from can limit the time needed to resolve governance friction.

Is this working group going to suggest an alternative? 

On Thu, Jul 9, 2020 at 9:59 AM Josh Berkus <jberkus@...> wrote:
As promised, we had an in-depth discussion of the Steering Committee
proposal drafted by Alexis Richardson for the July 7th TOC meeting
during the Governance WG meeting.  Six members were present and
participated in the discussion; notes are available here:
https://docs.google.com/document/d/e/2PACX-1vSfiN1PRL3dH_ohfAs1lYvNWaBpAdvAI-9OQZYYIx8ahgy6230_oRbqljl6dUiGf5hTVJiferJgBmSX/pub

Assessment:

Regarding the specific proposal of using steering committees (SC) as a
workaround for the requirement to have maintainers from multiple
organizations for projects to move to the Graduated level, the
Governance WG recommends that the TOC not adopt it.

Full explanation:

Steering Committees are frequently important governance tools for large
and distributed projects, and more projects should consider having one
as a channel for end-user, collaborator, and diverse audience
representation.  We valued Alexis’ writeup, and would like to
incorporate it into our handbooks in progress for CNCF projects on how
to develop governance.

Projects that would need the "SC workaround" are projects that have been
unable to attract a single maintainer from outside the original
sponsoring organization, which is usually a sign of serious issues
within the project. The Governance WG feels that the CNCF ecosystem is
ill-served by moving projects with such problems to the Graduated level,
and the proposal will not have the desired outcomes.

Our decision was based on what we view as the inability of a
non-technical Steering Committee to ensure that a project with
maintainers* exclusively employed by the same organization treat
submissions, roadmap items, and maintainer candidates from other
organizations fairly.  Even diligent SC members would find it difficult
to understand enough about technical architecture decisions to
differentiate between bias and legitimate objections in reviews.
Further, unlike code and docs maintainers, it would be challenging for
the TOC to monitor activity and involvement levels of SC members, as
that would not create the same kind of contribution trail.

For this proposal, we considered specifically projects that are having
problems attracting contributors, because only such projects would need
this mechanism. It certainly takes time to bring code reviewers up to
speed, but the current requirement is a low bar; even a single dedicated
documentation leader from an end-user company would technically satisfy it.

While many folks have cited the Kubernetes project as an example,
Kubernetes has a diversity of maintainers all the way down to the SIG
level, so it would qualify for a maintainer multi-org requirement even
without a Steering Committee. At this point, the Governance WG does not
know of a good example of a project that successfully has used an SC to
moderate the influence of development being dominated by a single
company, so doing so would be experimental. As an experiment, we might
adopt it for one specific project, but we'd want to see the outcome of
that before we adopt it as general policy.

Even Alexis’s document suggests that in problem cases it would be up to
the TOC or their delegates to intervene to resolve project problems.
Given this, it’s unclear what advantage having an SC would offer over
Alexis’s original suggestion of having designated TOC monitors.

Overall, our judgement was that adopting the SC workaround would be, in
essence, removing the maintainer multi-organization requirement, and
that it would be better to simply remove the requirement instead if that
is the direction the TOC wishes to go.

Drafted by Governance WG:
Josh Berkus
Dawn Foster
Jennifer Davis
Davinum Srinivas
Paris Pittman

(* by “maintainers” we mean involved, leading contributors with the
authority to merge code, docs, and/or community materials into any of
the key repos belonging to the project.  Such contributors may be called
"maintainers", "committers", or other titles.  It does not refer to the
official CNCF maintainer list for voting purposes, as that list contains
many people who do not have merge authority in their individual projects.)


--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO





Re: Proposal for a new "Steering Committee Charter"

Josh Berkus
 

On 7/9/20 10:48 AM, Jaice Singer DuMars wrote:

That said, I do believe a standardized steering committee template has
value though, especially for projects reaching the natural governance
evolution where one makes sense. It's easy to forget that the Kubernetes
steering committee was a response to community distress as documented in
the contributor survey at the time. Having a vetted and well thought-out
charter to start from can limit the time needed to resolve governance
friction.
The template is a great idea, and we'd like to borrow that from Alexis'
draft. We're creating a templates repo that projects can clone if they
want to use our templates for the various requirements, including
contributors.md, contributor ladder, etc. He hasn't given permission to
use it though, so I may need to rewrite it from scratch.

Is this working group going to suggest an alternative?
If you're asking about an alternative to the "SC workaround", our
recommendation would be that projects that are struggling with
attracting minority-org maintainers reach out to SIG-ContribStrat and
we'll work with them to make that happen. It's part of why we created
the SIG.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO


Re: Proposal for a new "Steering Committee Charter"

Jaice Singer DuMars
 

As an observer, I think this is a very solid analysis and recommendation. The risk of a "rubber stamp" steering committee is a serious concern, and clearly doesn't resolve the underlying challenge of meaningful corporate diversity among maintainers. 

That said, I do believe a standardized steering committee template has value though, especially for projects reaching the natural governance evolution where one makes sense. It's easy to forget that the Kubernetes steering committee was a response to community distress as documented in the contributor survey at the time. Having a vetted and well thought-out charter to start from can limit the time needed to resolve governance friction.

Is this working group going to suggest an alternative? 

On Thu, Jul 9, 2020 at 9:59 AM Josh Berkus <jberkus@...> wrote:
As promised, we had an in-depth discussion of the Steering Committee
proposal drafted by Alexis Richardson for the July 7th TOC meeting
during the Governance WG meeting.  Six members were present and
participated in the discussion; notes are available here:
https://docs.google.com/document/d/e/2PACX-1vSfiN1PRL3dH_ohfAs1lYvNWaBpAdvAI-9OQZYYIx8ahgy6230_oRbqljl6dUiGf5hTVJiferJgBmSX/pub

Assessment:

Regarding the specific proposal of using steering committees (SC) as a
workaround for the requirement to have maintainers from multiple
organizations for projects to move to the Graduated level, the
Governance WG recommends that the TOC not adopt it.

Full explanation:

Steering Committees are frequently important governance tools for large
and distributed projects, and more projects should consider having one
as a channel for end-user, collaborator, and diverse audience
representation.  We valued Alexis’ writeup, and would like to
incorporate it into our handbooks in progress for CNCF projects on how
to develop governance.

Projects that would need the "SC workaround" are projects that have been
unable to attract a single maintainer from outside the original
sponsoring organization, which is usually a sign of serious issues
within the project. The Governance WG feels that the CNCF ecosystem is
ill-served by moving projects with such problems to the Graduated level,
and the proposal will not have the desired outcomes.

Our decision was based on what we view as the inability of a
non-technical Steering Committee to ensure that a project with
maintainers* exclusively employed by the same organization treat
submissions, roadmap items, and maintainer candidates from other
organizations fairly.  Even diligent SC members would find it difficult
to understand enough about technical architecture decisions to
differentiate between bias and legitimate objections in reviews.
Further, unlike code and docs maintainers, it would be challenging for
the TOC to monitor activity and involvement levels of SC members, as
that would not create the same kind of contribution trail.

For this proposal, we considered specifically projects that are having
problems attracting contributors, because only such projects would need
this mechanism. It certainly takes time to bring code reviewers up to
speed, but the current requirement is a low bar; even a single dedicated
documentation leader from an end-user company would technically satisfy it.

While many folks have cited the Kubernetes project as an example,
Kubernetes has a diversity of maintainers all the way down to the SIG
level, so it would qualify for a maintainer multi-org requirement even
without a Steering Committee. At this point, the Governance WG does not
know of a good example of a project that successfully has used an SC to
moderate the influence of development being dominated by a single
company, so doing so would be experimental. As an experiment, we might
adopt it for one specific project, but we'd want to see the outcome of
that before we adopt it as general policy.

Even Alexis’s document suggests that in problem cases it would be up to
the TOC or their delegates to intervene to resolve project problems.
Given this, it’s unclear what advantage having an SC would offer over
Alexis’s original suggestion of having designated TOC monitors.

Overall, our judgement was that adopting the SC workaround would be, in
essence, removing the maintainer multi-organization requirement, and
that it would be better to simply remove the requirement instead if that
is the direction the TOC wishes to go.

Drafted by Governance WG:
Josh Berkus
Dawn Foster
Jennifer Davis
Davinum Srinivas
Paris Pittman

(* by “maintainers” we mean involved, leading contributors with the
authority to merge code, docs, and/or community materials into any of
the key repos belonging to the project.  Such contributors may be called
"maintainers", "committers", or other titles.  It does not refer to the
official CNCF maintainer list for voting purposes, as that list contains
many people who do not have merge authority in their individual projects.)


--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO





KubeEdge Incubation Public Comment Period

Alena Prokharchyk
 

KubeEdge has applied for promotion from Sandbox to Incubation level: https://github.com/cncf/toc/pull/461 

With the completion of KubeEdge Due Diligence and SIG Runtime recommendation, I'm opening the public comment period.


SIG Runtime recommendations can be found at the end of the doc.

The public comment period is now open for 2 weeks, and all SIGs, end users, TOC members, and community members are welcome to comment either in this thread, or on the github issue.

- Alena Prokharchyk


Re: Proposal for a new "Steering Committee Charter"

Josh Berkus
 

As promised, we had an in-depth discussion of the Steering Committee
proposal drafted by Alexis Richardson for the July 7th TOC meeting
during the Governance WG meeting. Six members were present and
participated in the discussion; notes are available here:
https://docs.google.com/document/d/e/2PACX-1vSfiN1PRL3dH_ohfAs1lYvNWaBpAdvAI-9OQZYYIx8ahgy6230_oRbqljl6dUiGf5hTVJiferJgBmSX/pub

Assessment:

Regarding the specific proposal of using steering committees (SC) as a
workaround for the requirement to have maintainers from multiple
organizations for projects to move to the Graduated level, the
Governance WG recommends that the TOC not adopt it.

Full explanation:

Steering Committees are frequently important governance tools for large
and distributed projects, and more projects should consider having one
as a channel for end-user, collaborator, and diverse audience
representation. We valued Alexis’ writeup, and would like to
incorporate it into our handbooks in progress for CNCF projects on how
to develop governance.

Projects that would need the "SC workaround" are projects that have been
unable to attract a single maintainer from outside the original
sponsoring organization, which is usually a sign of serious issues
within the project. The Governance WG feels that the CNCF ecosystem is
ill-served by moving projects with such problems to the Graduated level,
and the proposal will not have the desired outcomes.

Our decision was based on what we view as the inability of a
non-technical Steering Committee to ensure that a project with
maintainers* exclusively employed by the same organization treat
submissions, roadmap items, and maintainer candidates from other
organizations fairly. Even diligent SC members would find it difficult
to understand enough about technical architecture decisions to
differentiate between bias and legitimate objections in reviews.
Further, unlike code and docs maintainers, it would be challenging for
the TOC to monitor activity and involvement levels of SC members, as
that would not create the same kind of contribution trail.

For this proposal, we considered specifically projects that are having
problems attracting contributors, because only such projects would need
this mechanism. It certainly takes time to bring code reviewers up to
speed, but the current requirement is a low bar; even a single dedicated
documentation leader from an end-user company would technically satisfy it.

While many folks have cited the Kubernetes project as an example,
Kubernetes has a diversity of maintainers all the way down to the SIG
level, so it would qualify for a maintainer multi-org requirement even
without a Steering Committee. At this point, the Governance WG does not
know of a good example of a project that successfully has used an SC to
moderate the influence of development being dominated by a single
company, so doing so would be experimental. As an experiment, we might
adopt it for one specific project, but we'd want to see the outcome of
that before we adopt it as general policy.

Even Alexis’s document suggests that in problem cases it would be up to
the TOC or their delegates to intervene to resolve project problems.
Given this, it’s unclear what advantage having an SC would offer over
Alexis’s original suggestion of having designated TOC monitors.

Overall, our judgement was that adopting the SC workaround would be, in
essence, removing the maintainer multi-organization requirement, and
that it would be better to simply remove the requirement instead if that
is the direction the TOC wishes to go.

Drafted by Governance WG:
Josh Berkus
Dawn Foster
Jennifer Davis
Davinum Srinivas
Paris Pittman

(* by “maintainers” we mean involved, leading contributors with the
authority to merge code, docs, and/or community materials into any of
the key repos belonging to the project. Such contributors may be called
"maintainers", "committers", or other titles. It does not refer to the
official CNCF maintainer list for voting purposes, as that list contains
many people who do not have merge authority in their individual projects.)


--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO


Re: Sandbox annual reviews

Alena Prokharchyk
 

+1, sounds like a logical thing to do.

-alena.

On Jul 9, 2020, at 1:58 AM, Liz Rice <liz@...> wrote:

Now that we have the new Sandbox application process running, it might make sense to make similar tweaks to the Sandbox annual review process too. Specifically I'd like to suggest: 

* Moving from three sponsors to a simple TOC majority vote
* A regular cadence to review & vote on these, so that projects know when they can expect to get feedback

Wdyt? 
Liz 

 



[RESULT] Operator Framework SDK and OLM approved

Amye Scavarda Perrin
 

Operator Framework SDK and OLM sub-projects have applied to join as incubating projects (https://github.com/cncf/toc/pull/303).


+1 Binding: *note: Quorum is 10 as Jeff Brewer has been away*
Katie Gamanji: https://lists.cncf.io/g/cncf-toc/message/4799
Liz Rice: https://lists.cncf.io/g/cncf-toc/message/4833
Justin Cormack: https://lists.cncf.io/g/cncf-toc/message/4834
Xiang Li: https://lists.cncf.io/g/cncf-toc/message/4835
Alena Prokharchyk: https://lists.cncf.io/g/cncf-toc/message/4849
Brendan Burns: https://lists.cncf.io/g/cncf-toc/message/4839
Michelle Noorali: https://lists.cncf.io/g/cncf-toc/message/4939

+1 Non-binding:
Alex Chircop: https://lists.cncf.io/g/cncf-toc/message/4789
Ken Owens: https://lists.cncf.io/g/cncf-toc/message/4790
Karl Wehden: https://lists.cncf.io/g/cncf-toc/message/4791
Ricardo Aravena: https://lists.cncf.io/g/cncf-toc/message/4792
Gou Rao: https://lists.cncf.io/g/cncf-toc/message/4795
Ken Sipe: https://lists.cncf.io/g/cncf-toc/message/4797
Anil Vishnoi: https://lists.cncf.io/g/cncf-toc/message/4801
Erin Boyd: https://lists.cncf.io/g/cncf-toc/message/4802
Diane Mueller: https://lists.cncf.io/g/cncf-toc/message/4803
Rob Szumksi: https://lists.cncf.io/g/cncf-toc/message/4804
Oleg Chornyi: https://lists.cncf.io/g/cncf-toc/message/4805
Marc Boorshtein: https://lists.cncf.io/g/cncf-toc/message/4806
Alexis Richardson: https://lists.cncf.io/g/cncf-toc/message/4807
Alois Reitbauer: https://lists.cncf.io/g/cncf-toc/message/4808
Paul Buck: https://lists.cncf.io/g/cncf-toc/message/4809
Steven Dake: https://lists.cncf.io/g/cncf-toc/message/4820
Jonathan Berkhaun: https://lists.cncf.io/g/cncf-toc/message/4821
Srinivas R Brahmaroutu: https://lists.cncf.io/g/cncf-toc/message/4822
Naren Narendra: https://lists.cncf.io/g/cncf-toc/message/4823
Chris Short: https://lists.cncf.io/g/cncf-toc/message/4824
Suresh Krishnan: https://lists.cncf.io/g/cncf-toc/message/4826
Fredrick Kautz: https://lists.cncf.io/g/cncf-toc/message/4837
Jifeng: https://lists.cncf.io/g/cncf-toc/message/4852

--
Amye Scavarda Perrin | Program Manager | amye@...


Re: Sandbox annual reviews

Kiran Mova
 

+1 NB - sounds good!

On Thu, Jul 9, 2020 at 6:58 PM Michelle Noorali <michelle.noorali@...> wrote:
+1

On Jul 9, 2020, at 4:58 AM, Liz Rice <liz@...> wrote:


Now that we have the new Sandbox application process running, it might make sense to make similar tweaks to the Sandbox annual review process too. Specifically I'd like to suggest: 

* Moving from three sponsors to a simple TOC majority vote
* A regular cadence to review & vote on these, so that projects know when they can expect to get feedback

Wdyt? 
Liz 

 

1381 - 1400 of 6343