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@...

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@...

+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 

 

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

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

+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 

 

Hi all

Please see below a link to a public document that describes a proposed
charter for projects wishing to establish a Steering Committee.

https://docs.google.com/document/d/11Hiz1dGYRS7GcjedpRVnSlDjIj0AVjeTa0-Td7aW-Lk/edit?usp=sharing

The model proposed in the doc is intended to provide 'best practice'
for projects and governance through graduation and beyond. It is not
intended to be mandatory.  It is consistent with our existing CNCF TOC
Principles.

The model addresses some of the questions raised in this github thread
- https://github.com/cncf/toc/issues/459

I welcome commentary in the doc or on this list.

alexis