Date   

Re: Istio Steering Committee

Matt Wilson
 

+1 to messages that Kris and Josh have sent on this thread.

On Tue, Aug 25, 2020 at 12:04 PM, alexis richardson wrote:

It isn't but it has aspects we can learn from (good and bad) as do other
projects (eg apache kafka to name one).
I am not familiar with specific concerns or complaints about Apache
Kafka. But I have also not experienced how the project is operating
from a first hand perspective. From a distance, it seems that the
Apache Kafka PMC is welcoming to newcomers, and the work is done in
the open. The committer roster, and the Project Management Committee,
is made of individuals from many different backgrounds and employment
sponsorship. The employer of the majority of committers and PMC
members is on the record as being "committed to maintaining a good
relationship with the Apache Software Foundation as well as the Apache
Kafka community." [1]

I definitely agree that there is much to learn (good and bad) from
other projects, and welcome other perspectives on this. My intuition
(biased by my limited sampling history, and various conversations) is
that the ASF is going to _trust_ PMCs to operate in accordance with
the philosophies and policies of the top level ASF. In those rare
cases where concerns of undue commercial influence peculate up to the
Board of Directors of the ASF (e.g., through the auditing process of
quarterly reporting to the BOD), corrective actions are taken (like
those in the frequently cited Apache Cassandra / DataStax event [2]).

This thread is specifically about steering committees, and what they can
help with especially governance over direction. And avoiding open core
feature withholding.
I think it's good that you highlighted a *specific* concern about
open-core feature withholding. Highlighting concerns can help focus a
conversation toward how they can best be addressed. To me, it is not
obvious that Steering Committees, Governing Boards, Advisory Boards,
and Technical Oversight Committees are a good way to avoid the "slow
walking" of capabilities that a vendor wants to hold as a proprietary
capability.

To me, much of what is generally desired is "insurance" that protects
corporate interest in some piece of open-source software, and any
valuable assets around it. It's not wrong to have corporate interests,
or to seek conditions where corporate interests can be represented in
a multi-stakeholder system. Personally, I find it easier to talk about
them plainly and clinically.

There is a lot of focus on having "a seat at the table" because you
don't want another person to work against your interests. There's a
lot less focus on what conversations are had and what decisions that
are made around that table, and if the table is behind closed doors. I
would like this to be better understood in across multiple communities
and projects.

My advice about open-core feature withholding is a pretty simple one:
deliberations on how to best build software should be done in the
public, in a way that puts the common good ahead of any particular
company's priorities. Setting the culture, and expectations, should
receive the most attention and continuous reinforcement. I think that
signs point to Kubernetes getting that generally right: "Community
over product or company" [3].

When making a deliberation about a feature or direction for the
software, wear your "individual hat" most often, and if you find that
you need to advocate on behalf of your employer, make it explicit by
declaring that you're wearing employee-of-company hat.

If we think that a committee or decision making board is required to
make sound decisions that are free from conflicts of interest (like if
a feature should be withheld because it is to the advantage /
disadvantage of a particular company with a commercial interest in the
software), I'd say that we need more attention on community building.

Istio just launched a Steering Committee and that's why it is relevant.
I think it is too soon to say much about this development. I've
already made some less verbose views of mine (and mine alone) known on
Twitter. Personally speaking, I think that the current seat allocation
formula is problematic, as it can encourage gaming statistics. And
that doesn't address a more fundamental question: what does a Steering
Committee *do*, exactly? And why must it be done privately? Without
getting a seat at the table, or at least being allowed in the room,
you don't know.

I think this all leads to conditions that weaken trust bonds through a
sense of uneven power dynamics. And then everyone starts competing so
they can be in The Room Where It Happens [4].

--msw (wearing his "individual" hat)

[1] https://www.confluent.io/apache-guidelines/#the_importance
[2] https://sdtimes.com/afs/apache-foundation-board-reining-datastax/
[3] https://github.com/kubernetes/community/blob/master/values.md#community-over-product-or-company
[4] https://www.youtube.com/watch?v=WySzEXKUSZw


TOC meeting agenda for 9/1

Amye Scavarda Perrin
 

Hi all,
We'll be meeting tomorrow with a SIG update meeting. 

Presentation: https://docs.google.com/presentation/d/1dNZKxH973SejImtD9-7eqfqDhUqY1xMLBm69ftpq8Ks/edit#slide=id.g25ca91f87f_0_0

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


Re: Istio Steering Committee

alexis richardson
 

+1 for async comms

For sync, I can't due any time after 10am PT due to family commitments.


On Mon, 31 Aug 2020, 19:25 Matt Wilson, <msw@...> wrote:
On Thu, Aug 27, 2020 at 02:51 PM, Josh Berkus wrote:
Hey, all:

If you want to continue this discussion, I wanted to invite anyone
interested to attend the Governance WG meeting on Tuesday at 10amPDT.

https://docs.google.com/document/d/1P9tQgCM6OwDHd1F8UnWuauL4KDVTMTp49_n64_w8nrs/edit?usp=sharing
I'd like to participate in a discussion, but my calendar commitments at work make it very difficult to commit to appointed times to jump on Zoom. This makes asynchronous communication more accessible to me. I understand that this is not necessarily the same for others, and that that is a lot of value in "high bandwidth" direct conversations.

--msw


Re: Istio Steering Committee

Matt Wilson
 

On Thu, Aug 27, 2020 at 02:51 PM, Josh Berkus wrote:
Hey, all:

If you want to continue this discussion, I wanted to invite anyone
interested to attend the Governance WG meeting on Tuesday at 10amPDT.

https://docs.google.com/document/d/1P9tQgCM6OwDHd1F8UnWuauL4KDVTMTp49_n64_w8nrs/edit?usp=sharing
I'd like to participate in a discussion, but my calendar commitments at work make it very difficult to commit to appointed times to jump on Zoom. This makes asynchronous communication more accessible to me. I understand that this is not necessarily the same for others, and that that is a lot of value in "high bandwidth" direct conversations.

--msw


Re: Istio Steering Committee

Kris Nova <kris.nova@...>
 

I can only make the governance meeting - we have our meetings with the EU during the TOC meetings unfortunately. 

If we push the TOC discussion back until the next call I can make it. 


On Sat, Aug 29, 2020 at 10:04 AM Alexis Richardson <alexis@...> wrote:
I'm keen to discuss this in the TOC, and then work out details in the various WGs and community.  When is everyone back?


On Thu, 27 Aug 2020, 22:51 Josh Berkus, <jberkus@...> wrote:
Hey, all:

If you want to continue this discussion, I wanted to invite anyone
interested to attend the Governance WG meeting on Tuesday at 10amPDT.

https://docs.google.com/document/d/1P9tQgCM6OwDHd1F8UnWuauL4KDVTMTp49_n64_w8nrs/edit?usp=sharing


--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO



--
Kris Nova
Chief Open Source Advocate


85 2nd Street
San Francisco, CA 94105


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

Kevin Wang
 

+1 NB


Re: Istio Steering Committee

alexis richardson
 

I'm keen to discuss this in the TOC, and then work out details in the various WGs and community.  When is everyone back?


On Thu, 27 Aug 2020, 22:51 Josh Berkus, <jberkus@...> wrote:
Hey, all:

If you want to continue this discussion, I wanted to invite anyone
interested to attend the Governance WG meeting on Tuesday at 10amPDT.

https://docs.google.com/document/d/1P9tQgCM6OwDHd1F8UnWuauL4KDVTMTp49_n64_w8nrs/edit?usp=sharing


--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO


Re: [VOTE] KubeEdge for Incubation

Katie Gamanji
 

+1 binding

Katie Gamanji

On Thu, 6 Aug 2020, 09:19 , <zongkeshuaige@...> wrote:
+1 non-binding


Re: Istio Steering Committee

Josh Berkus
 

Hey, all:

If you want to continue this discussion, I wanted to invite anyone
interested to attend the Governance WG meeting on Tuesday at 10amPDT.

https://docs.google.com/document/d/1P9tQgCM6OwDHd1F8UnWuauL4KDVTMTp49_n64_w8nrs/edit?usp=sharing


--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO


Re: [VOTE] TiKV Graduation

Katie Gamanji
 

+1 binding 


On Mon, 24 Aug 2020, 02:06 Li, Xiang, <x.li@...> wrote:
+1 binding
------------------------------------------------------------------
From:GolfenGuo <golfen.guo@...>
Sent At:2020 Aug. 21 (Fri.) 20:59
To:Amye Scavarda Perrin <ascavarda@...>
Cc:CNCF TOC <cncf-toc@...>
Subject:Re: [cncf-toc] [VOTE] TiKV Graduation

+1 NB

 

Thanks

--

郭峰  Golfen Guo

Shanghai DaoCloud Network Technology Co,. Ltd

#Your Cloud Native Application Delivered!#

 

发件人: <cncf-toc@...> 代表 "Alena Prokharchyk via lists.cncf.io" <aprokharchyk=apple.com@...>
答复: "aprokharchyk@..." <aprokharchyk@...>
日期: 2020822星期六上午8:14
收件人: Amye Scavarda Perrin <ascavarda@...>
抄送: CNCF TOC <cncf-toc@...>
主题: Re: [cncf-toc] [VOTE] TiKV Graduation

 

+1 binding.

 

-alena.



On Jul 6, 2020, at 3:05 PM, Amye Scavarda Perrin <ascavarda@...> wrote:

 

The TiKV project has applied for promotion to "Graduated" (see https://github.com/cncf/toc/pull/414).

Saad Ali is the TOC sponsor and has called for the vote at the end of the public comment period. (https://lists.cncf.io/g/cncf-toc/message/4847)

Due diligence doc can be found here: https://docs.google.com/document/d/1KCFeOdTIUXEkJJjaBrge8aIdovwdx4W2HngmUm5nfOA/edit#

CNCF SIG Storage has reviewed the proposal, their recommendation can be found here: https://docs.google.com/document/d/15TQERAYI-6NWj3eTGZxKJ_g3kBP9E11v1b-Gx8lFpt0/edit#

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

 


本邮件及附件含 DaoCloud 保密信息,仅限发送给上面地址中列出的个人或群组,禁止任何其他人以任何形式使用本邮件中的信息。若误收本邮件,请务必通知发送人并直接删去,不得使用、传播或复制本邮件。


FYI: End User TOC Seat Election Opening for September 2020

Chris Aniszczyk
 

Just a heads up, Jeff will be stepping down from the TOC next month and we will run an election within the end user community: https://www.cncf.io/people/end-user-community

Please see GitHub for details but we will open nominations to the end user community starting next month: https://github.com/cncf/toc/issues/518

I want to personally thank Jeff for his service, he has done amazing work showing the impact an end user company can have in the cloud native community by sharing their story: https://www.cncf.io/case-study/intuit

--
Chris Aniszczyk (@cra) | +1-512-961-6719


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

Katie Gamanji
 

+1 binding 

On Tue, Aug 18, 2020 at 6:40 PM Andrew Aitken via lists.cncf.io <andrew.aitken=wipro.com@...> wrote:

+1 binding

 

 

Regards,

 

Andrew Aitken

GM & Global Open Source Practice Leader

Wipro Technologies

650-704-6321

 

1494361338303_PastedImage

 

 

 

 

Sensitivity: Internal & Restricted

From: cncf-toc@... <cncf-toc@...> On Behalf Of Ganesh Vernekar via lists.cncf.io
Sent: Monday, August 17, 2020 8:19 AM
To: cncf-toc@...
Subject: Re: [cncf-toc] [VOTE] Tech Lead nomination for SIG Observability: Bartłomiej Płotka

 

** This mail has been sent from an external source. Treat hyperlinks and attachments in this email with caution**

+1 NB

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com


Re: Istio Steering Committee

Josh Berkus
 

On 8/25/20 12:53 PM, April Kyle Nassi wrote:
I do echo Kris' comment about CNCF having an opinion on how projects
govern. It seems like as CNCF has grown, perhaps there is now a desire
to be more explicit about the types of governance we want projects to
have? This is something those of us on the Governance WG would love to
get more direction around so we can help make templates, etc and build
programs that would benefit projects. 
There's going to be a huge gap between the governance structures we
*recommend* and the ones that are *acceptable to CNCF*. The CNCF was
founded on having considerable autonmy for projects in governance, and
that has to include adopting systems we think are "bad".

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO


Re: [VOTE] Rook Graduation

Katie Gamanji
 

+1 binding

  Great addition to the graduated suite of CNCF projects!

On Tue, Aug 25, 2020 at 7:35 PM Alena Prokharchyk via lists.cncf.io <aprokharchyk=apple.com@...> wrote:
+1 binding

-alena.

On Jul 6, 2020, at 3:03 PM, Amye Scavarda Perrin <ascavarda@...> wrote:

Rook has applied for graduation (see https://github.com/cncf/toc/pull/366).

Saad Ali is the TOC sponsor for Rook, has completed DD and has called for a vote.  (https://lists.cncf.io/g/cncf-toc/message/4846)

Due diligence doc can be found here: https://docs.google.com/document/d/1acp9gJ1D_qflHKJBg4gB-nZwZQs87_Dh9uiH4pITc_U/edit?usp=sharing

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: Istio Steering Committee

Kris Nova <kris.nova@...>
 

Not trying to create a fallacy - apologies - these threads seem to be glamorizing steering committees more and more - and I just wanted to advocate that not every project needs one. 


On Tue, Aug 25, 2020 at 12:46 PM Alexis Richardson <alexis@...> wrote:
Nobody is suggesting imposing anything.   That suggestion is a red herring.


On Tue, 25 Aug 2020, 20:42 Kris Nova, <kris.nova@...> wrote:
+1 to Josh 

Speaking as a Falco maintainer here, our community just re-vamped our model for how we manage sub projects, official support, and decision making in the open. All of these seem like they would fit under a steering committee charter. [1] [2] We even mentioned this in our latest update [3].

Having a steering committee imposed on the project would just create more process and impair innovation for us. It's not that we are necessarily against the idea, we just aren't there yet as a project. Furthermore I doubt any of the engineers are going to be keen on introducing process to solve a problem that doesn't exist yet for the project. As far as end-users are concerned, we see them engaged in all of the community activities and contributing to the process outlined in the references below. Again -- we just aren't there yet. 

I look at a SC like a tool. It's a well-known tool, that obviously works to solve well-known issues for folks. Can we just keep it at that? It's a tool. The tool works well, if you happen to need it and decide to use it. <click here to read more>

TLDR; I thought that the whole point of this was that the CNCF didn't impose rules/regulations on how projects self-govern? Maybe I am mistaken, but I thought that was -- like -- a thing. 


On Tue, Aug 25, 2020 at 12:38 PM alexis richardson <alexis@...> wrote:
Agree that SC should (if suggested) remain a known good option, and Not Compulsory.

Agree that some projects are "small" - but i would have said Helm is small!  My belief is that SCs can help growth. Many projects now have numerous repos and moving parts.  The direction may not be clear.  End users may want more of a say.  Contributors and maintainers should welcome this, and most do.


On Tue, 25 Aug 2020, 20:30 Josh Berkus, <jberkus@...> wrote:
On 8/25/20 12:20 PM, Alexis Richardson wrote:
> During the summer break it occurred to me that many of the advantages i
> could envisage in adding SCs would be achieved if the notion of
> Maintainer was broadened to include non coding people.  But you still
> get benefit from org level direction over the top.

And for large projects like Helm, an SC has these benefits.  Just like
Kubernetes.  But in smaller projects, where you're looking at a couple
dozen regular contributors period, there's not a lot o benefit --
generally the exact same people are on the SC as are in the other
groups.  Unless you add someone from outside the project, in which case
you have different problems.

For a small project, I'd recommend (were I advising them) trying to
broaden their maintainers group to include non-code maintainers (like
docs and advocacy), which is usually a better approach when dealing with
a small pool.

Of course, it's really up to what the project wants.

> Fwiw, i don't believe in imposing or forcing things either.  Apologies
> if I have given that impression.

We have to recognize that if we make an SC an alternative for other
governance requirements, that will result in an SC being imposed on a
few projects where the contributors otherwise don't want one.

BTW, in this thread I am speaking as a single member of SIG-Contributor
Strategy, and not for the whole committee.  Other members of the SIG may
well disagree with me.  I am also not speaking for Red Hat.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO



--
Kris Nova
Chief Open Source Advocate


85 2nd Street
San Francisco, CA 94105


--
Kris Nova
Chief Open Source Advocate


85 2nd Street
San Francisco, CA 94105


Re: Istio Steering Committee

Kris Nova <kris.nova@...>
 

+1 to Josh 

Speaking as a Falco maintainer here, our community just re-vamped our model for how we manage sub projects, official support, and decision making in the open. All of these seem like they would fit under a steering committee charter. [1] [2] We even mentioned this in our latest update [3].

Having a steering committee imposed on the project would just create more process and impair innovation for us. It's not that we are necessarily against the idea, we just aren't there yet as a project. Furthermore I doubt any of the engineers are going to be keen on introducing process to solve a problem that doesn't exist yet for the project. As far as end-users are concerned, we see them engaged in all of the community activities and contributing to the process outlined in the references below. Again -- we just aren't there yet. 

I look at a SC like a tool. It's a well-known tool, that obviously works to solve well-known issues for folks. Can we just keep it at that? It's a tool. The tool works well, if you happen to need it and decide to use it. <click here to read more>

TLDR; I thought that the whole point of this was that the CNCF didn't impose rules/regulations on how projects self-govern? Maybe I am mistaken, but I thought that was -- like -- a thing. 


On Tue, Aug 25, 2020 at 12:38 PM alexis richardson <alexis@...> wrote:
Agree that SC should (if suggested) remain a known good option, and Not Compulsory.

Agree that some projects are "small" - but i would have said Helm is small!  My belief is that SCs can help growth. Many projects now have numerous repos and moving parts.  The direction may not be clear.  End users may want more of a say.  Contributors and maintainers should welcome this, and most do.


On Tue, 25 Aug 2020, 20:30 Josh Berkus, <jberkus@...> wrote:
On 8/25/20 12:20 PM, Alexis Richardson wrote:
> During the summer break it occurred to me that many of the advantages i
> could envisage in adding SCs would be achieved if the notion of
> Maintainer was broadened to include non coding people.  But you still
> get benefit from org level direction over the top.

And for large projects like Helm, an SC has these benefits.  Just like
Kubernetes.  But in smaller projects, where you're looking at a couple
dozen regular contributors period, there's not a lot o benefit --
generally the exact same people are on the SC as are in the other
groups.  Unless you add someone from outside the project, in which case
you have different problems.

For a small project, I'd recommend (were I advising them) trying to
broaden their maintainers group to include non-code maintainers (like
docs and advocacy), which is usually a better approach when dealing with
a small pool.

Of course, it's really up to what the project wants.

> Fwiw, i don't believe in imposing or forcing things either.  Apologies
> if I have given that impression.

We have to recognize that if we make an SC an alternative for other
governance requirements, that will result in an SC being imposed on a
few projects where the contributors otherwise don't want one.

BTW, in this thread I am speaking as a single member of SIG-Contributor
Strategy, and not for the whole committee.  Other members of the SIG may
well disagree with me.  I am also not speaking for Red Hat.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO



--
Kris Nova
Chief Open Source Advocate


85 2nd Street
San Francisco, CA 94105


Re: Istio Steering Committee

Matt Farina
 

Thanks for bringing this up Stephen.

I would suggest that the structure (which includes SC or not) can't fix problems that may be cultural. For example, knowing ones audience is important. Taking the time to sit down with users, understand them, understand when one project ends and others begin, and work for the benefit of the people involved is a cultural trait.

I would like to see more that teaches this trait.

On Tue, Aug 25, 2020, at 3:42 PM, Stephen Augustus wrote:
(+ SIG ContribStrat)

I could see the overarching theme as "distilling what it could mean to be a 'good maintainer'".

SIG Contributor Strategy is exactly the kind of venue to have this discussion and we'd welcome (kind) discourse around this across our main meeting, WG Governance, and the soon-to-be-launched Maintainer's Circle.


-- Stephen

On Tue, Aug 25, 2020, 15:38 alexis richardson <alexis@...> wrote:
Agree that SC should (if suggested) remain a known good option, and Not Compulsory.

Agree that some projects are "small" - but i would have said Helm is small!  My belief is that SCs can help growth. Many projects now have numerous repos and moving parts.  The direction may not be clear.  End users may want more of a say.  Contributors and maintainers should welcome this, and most do.


On Tue, 25 Aug 2020, 20:30 Josh Berkus, <jberkus@...> wrote:
On 8/25/20 12:20 PM, Alexis Richardson wrote:
> During the summer break it occurred to me that many of the advantages i
> could envisage in adding SCs would be achieved if the notion of
> Maintainer was broadened to include non coding people.  But you still
> get benefit from org level direction over the top.

And for large projects like Helm, an SC has these benefits.  Just like
Kubernetes.  But in smaller projects, where you're looking at a couple
dozen regular contributors period, there's not a lot o benefit --
generally the exact same people are on the SC as are in the other
groups.  Unless you add someone from outside the project, in which case
you have different problems.

For a small project, I'd recommend (were I advising them) trying to
broaden their maintainers group to include non-code maintainers (like
docs and advocacy), which is usually a better approach when dealing with
a small pool.

Of course, it's really up to what the project wants.

> Fwiw, i don't believe in imposing or forcing things either.  Apologies
> if I have given that impression.

We have to recognize that if we make an SC an alternative for other
governance requirements, that will result in an SC being imposed on a
few projects where the contributors otherwise don't want one.

BTW, in this thread I am speaking as a single member of SIG-Contributor
Strategy, and not for the whole committee.  Other members of the SIG may
well disagree with me.  I am also not speaking for Red Hat.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO





Re: Istio Steering Committee

alexis richardson
 



On Tue, 25 Aug 2020, 20:49 Kris Nova, <kris.nova@...> wrote:
Not trying to create a fallacy - apologies - these threads seem to be glamorizing steering committees more and more - and I just wanted to advocate that not every project needs one. 

Agree. 

The underlying issues are set out here 




On Tue, Aug 25, 2020 at 12:46 PM Alexis Richardson <alexis@...> wrote:
Nobody is suggesting imposing anything.   That suggestion is a red herring.


On Tue, 25 Aug 2020, 20:42 Kris Nova, <kris.nova@...> wrote:
+1 to Josh 

Speaking as a Falco maintainer here, our community just re-vamped our model for how we manage sub projects, official support, and decision making in the open. All of these seem like they would fit under a steering committee charter. [1] [2] We even mentioned this in our latest update [3].

Having a steering committee imposed on the project would just create more process and impair innovation for us. It's not that we are necessarily against the idea, we just aren't there yet as a project. Furthermore I doubt any of the engineers are going to be keen on introducing process to solve a problem that doesn't exist yet for the project. As far as end-users are concerned, we see them engaged in all of the community activities and contributing to the process outlined in the references below. Again -- we just aren't there yet. 

I look at a SC like a tool. It's a well-known tool, that obviously works to solve well-known issues for folks. Can we just keep it at that? It's a tool. The tool works well, if you happen to need it and decide to use it. <click here to read more>

TLDR; I thought that the whole point of this was that the CNCF didn't impose rules/regulations on how projects self-govern? Maybe I am mistaken, but I thought that was -- like -- a thing. 


On Tue, Aug 25, 2020 at 12:38 PM alexis richardson <alexis@...> wrote:
Agree that SC should (if suggested) remain a known good option, and Not Compulsory.

Agree that some projects are "small" - but i would have said Helm is small!  My belief is that SCs can help growth. Many projects now have numerous repos and moving parts.  The direction may not be clear.  End users may want more of a say.  Contributors and maintainers should welcome this, and most do.


On Tue, 25 Aug 2020, 20:30 Josh Berkus, <jberkus@...> wrote:
On 8/25/20 12:20 PM, Alexis Richardson wrote:
> During the summer break it occurred to me that many of the advantages i
> could envisage in adding SCs would be achieved if the notion of
> Maintainer was broadened to include non coding people.  But you still
> get benefit from org level direction over the top.

And for large projects like Helm, an SC has these benefits.  Just like
Kubernetes.  But in smaller projects, where you're looking at a couple
dozen regular contributors period, there's not a lot o benefit --
generally the exact same people are on the SC as are in the other
groups.  Unless you add someone from outside the project, in which case
you have different problems.

For a small project, I'd recommend (were I advising them) trying to
broaden their maintainers group to include non-code maintainers (like
docs and advocacy), which is usually a better approach when dealing with
a small pool.

Of course, it's really up to what the project wants.

> Fwiw, i don't believe in imposing or forcing things either.  Apologies
> if I have given that impression.

We have to recognize that if we make an SC an alternative for other
governance requirements, that will result in an SC being imposed on a
few projects where the contributors otherwise don't want one.

BTW, in this thread I am speaking as a single member of SIG-Contributor
Strategy, and not for the whole committee.  Other members of the SIG may
well disagree with me.  I am also not speaking for Red Hat.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO



--
Kris Nova
Chief Open Source Advocate


85 2nd Street
San Francisco, CA 94105


--
Kris Nova
Chief Open Source Advocate


85 2nd Street
San Francisco, CA 94105


Re: Istio Steering Committee

April Kyle Nassi
 

I think we can all agree that there is no one way to do open source, and that every project has different needs. 

I do echo Kris' comment about CNCF having an opinion on how projects govern. It seems like as CNCF has grown, perhaps there is now a desire to be more explicit about the types of governance we want projects to have? This is something those of us on the Governance WG would love to get more direction around so we can help make templates, etc and build programs that would benefit projects. 

On Tue, Aug 25, 2020 at 12:46 PM alexis richardson <alexis@...> wrote:
Nobody is suggesting imposing anything.   That suggestion is a red herring.


On Tue, 25 Aug 2020, 20:42 Kris Nova, <kris.nova@...> wrote:
+1 to Josh 

Speaking as a Falco maintainer here, our community just re-vamped our model for how we manage sub projects, official support, and decision making in the open. All of these seem like they would fit under a steering committee charter. [1] [2] We even mentioned this in our latest update [3].

Having a steering committee imposed on the project would just create more process and impair innovation for us. It's not that we are necessarily against the idea, we just aren't there yet as a project. Furthermore I doubt any of the engineers are going to be keen on introducing process to solve a problem that doesn't exist yet for the project. As far as end-users are concerned, we see them engaged in all of the community activities and contributing to the process outlined in the references below. Again -- we just aren't there yet. 

I look at a SC like a tool. It's a well-known tool, that obviously works to solve well-known issues for folks. Can we just keep it at that? It's a tool. The tool works well, if you happen to need it and decide to use it. <click here to read more>

TLDR; I thought that the whole point of this was that the CNCF didn't impose rules/regulations on how projects self-govern? Maybe I am mistaken, but I thought that was -- like -- a thing. 


On Tue, Aug 25, 2020 at 12:38 PM alexis richardson <alexis@...> wrote:
Agree that SC should (if suggested) remain a known good option, and Not Compulsory.

Agree that some projects are "small" - but i would have said Helm is small!  My belief is that SCs can help growth. Many projects now have numerous repos and moving parts.  The direction may not be clear.  End users may want more of a say.  Contributors and maintainers should welcome this, and most do.


On Tue, 25 Aug 2020, 20:30 Josh Berkus, <jberkus@...> wrote:
On 8/25/20 12:20 PM, Alexis Richardson wrote:
> During the summer break it occurred to me that many of the advantages i
> could envisage in adding SCs would be achieved if the notion of
> Maintainer was broadened to include non coding people.  But you still
> get benefit from org level direction over the top.

And for large projects like Helm, an SC has these benefits.  Just like
Kubernetes.  But in smaller projects, where you're looking at a couple
dozen regular contributors period, there's not a lot o benefit --
generally the exact same people are on the SC as are in the other
groups.  Unless you add someone from outside the project, in which case
you have different problems.

For a small project, I'd recommend (were I advising them) trying to
broaden their maintainers group to include non-code maintainers (like
docs and advocacy), which is usually a better approach when dealing with
a small pool.

Of course, it's really up to what the project wants.

> Fwiw, i don't believe in imposing or forcing things either.  Apologies
> if I have given that impression.

We have to recognize that if we make an SC an alternative for other
governance requirements, that will result in an SC being imposed on a
few projects where the contributors otherwise don't want one.

BTW, in this thread I am speaking as a single member of SIG-Contributor
Strategy, and not for the whole committee.  Other members of the SIG may
well disagree with me.  I am also not speaking for Red Hat.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO



--
Kris Nova
Chief Open Source Advocate


85 2nd Street
San Francisco, CA 94105


Re: Istio Steering Committee

Paris Pittman
 

We have to recognize that if we make an SC an alternative for other governance requirements, that will result in an SC being imposed on a few projects where the contributors otherwise don't want one.

This is why I really like the idea that Dims brought to the table with governance badging. We shouldn’t be prescribing governance but making sure its align with the open values of the project/cncf and a Steering committee can be one of those vehicles, discovered clearly on the readme. There is a wg-governance meeting next Tuesday to go into the badging idea more and continue other governance conversations: can we all meet there and discuss? alexis?

On Tue, Aug 25, 2020 at 12:30 PM Josh Berkus <jberkus@...> wrote:
On 8/25/20 12:20 PM, Alexis Richardson wrote:

> During the summer break it occurred to me that many of the advantages i

> could envisage in adding SCs would be achieved if the notion of

> Maintainer was broadened to include non coding people.  But you still

> get benefit from org level direction over the top.



And for large projects like Helm, an SC has these benefits.  Just like

Kubernetes.  But in smaller projects, where you're looking at a couple

dozen regular contributors period, there's not a lot o benefit --

generally the exact same people are on the SC as are in the other

groups.  Unless you add someone from outside the project, in which case

you have different problems.



For a small project, I'd recommend (were I advising them) trying to

broaden their maintainers group to include non-code maintainers (like

docs and advocacy), which is usually a better approach when dealing with

a small pool.



Of course, it's really up to what the project wants.



> Fwiw, i don't believe in imposing or forcing things either.  Apologies

> if I have given that impression.



We have to recognize that if we make an SC an alternative for other

governance requirements, that will result in an SC being imposed on a

few projects where the contributors otherwise don't want one.



BTW, in this thread I am speaking as a single member of SIG-Contributor

Strategy, and not for the whole committee.  Other members of the SIG may

well disagree with me.  I am also not speaking for Red Hat.



--

--

Josh Berkus

Kubernetes Community

Red Hat OSPO









2461 - 2480 of 7712