|
FYI: End User TOC Seat Election Opening for September 2020
Chris Aniszczyk
|
|
|
Re: [VOTE] Tech Lead nomination for SIG Observability: Bartłomiej Płotka
toggle quoted message
Show quoted text
+1 binding
Regards,
Andrew Aitken
GM & Global Open Source Practice Leader
Wipro Technologies
650-704-6321
** This mail has been sent from an external source. Treat hyperlinks and attachments in this email with caution**
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
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
+1 binding Great addition to the graduated suite of CNCF projects!
+1 binding
-alena. On Jul 6, 2020, at 3:03 PM, Amye Scavarda Perrin < ascavarda@...> wrote:
|
|
|
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.
+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
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
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.
+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
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.
+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
> 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
|
|
|
Re: Istio Steering Committee
Nobody is suggesting imposing anything. That suggestion is a red herring.
+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
Stephen Augustus
(+ 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
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
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
I think you are creating a strawman argument. We are not substituting one form of governance for another.
The issue is how SCs can add value eg direction, participation, and user confidence that features won't be withheld. I think Matt offered an example of a project, Helm, where the SC complements, at org level, the repo level project governance.
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.
Fwiw, i don't believe in imposing or forcing things either. Apologies if I have given that impression.
On Tue, 25 Aug 2020, 20:13 Josh Berkus, < jberkus@...> wrote: On 8/25/20 12:10 PM, Alexis Richardson wrote:
> Josh, please disentangle your feelings about istio from the constructive
> discussion i can see you want to have.
>
Then pick a better example of a steering committee.
I don't know of a single example of a steering committee successfully
evolving otherwise broken leadership within a project. Maybe you do?
I've never seen it in practice.
--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO
|
|
|
Re: Istio Steering Committee
On 8/25/20 12:10 PM, Alexis Richardson wrote: Josh, please disentangle your feelings about istio from the constructive
discussion i can see you want to have.
Then pick a better example of a steering committee. I don't know of a single example of a steering committee successfully evolving otherwise broken leadership within a project. Maybe you do? I've never seen it in practice. -- -- Josh Berkus Kubernetes Community Red Hat OSPO
|
|
|
Re: Istio Steering Committee
Josh, please disentangle your feelings about istio from the constructive discussion i can see you want to have.
On Tue, 25 Aug 2020, 20:08 Josh Berkus, < jberkus@...> wrote: On 8/25/20 11:57 AM, Alexis Richardson wrote:
> Josh, feel free to highlight the negative aspects of Istio's history and
> governance on another thread. I may well join you. But please let's
> also give them credit for moving forward with improvements. As i said
> in the email you quoted, their SC illustrates some of the positives. I
> never said it is a panacea!
>
Others have already gone over the issue of having positions and
contributions accrue to companies and not individuals.
Second, there's the fact that the 3 biggest corporate contributors get
100% of representation, and smaller contributors get none in practical
terms. This is presently causing some of the smaller contributors to
leave Istio. Overall, the Istio SC is a great example of how not to do
an SC.
I'm not saying SCs are bad, particularly as someone who is currently an
elections officer for the Kubernetes SC. What I'm saying is that SCs do
not work as a substitute for having balanced technical leadership. I
big, successful project can often use an SC to supply leadership beyond
the technical, but that doesn't do anything to fix technical leadership
that is concentrated into too few hands (whether corporate or individual).
What I'm particularly opposed to the TOC doing is imposing an SC on
projects that have governance problems. If a project has broken
governance, adding extra committees will just make it more broken --
particularly since unbalanced governance problems are often reflective
of other issues like contributor recruitment issues, i.e. if you can't
recruit outside contributors to your maintainer group, why would you
suddenly have the ability to recruit knoweldgable non-technical people
to your SC? The solution is to fix the recruitment problems, not add an
SC if the project doesn't otherwise need one.
--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO
|
|
|
Re: Istio Steering Committee
On 8/25/20 11:57 AM, Alexis Richardson wrote: Josh, feel free to highlight the negative aspects of Istio's history and
governance on another thread. I may well join you. But please let's
also give them credit for moving forward with improvements. As i said
in the email you quoted, their SC illustrates some of the positives. I
never said it is a panacea!
Others have already gone over the issue of having positions and contributions accrue to companies and not individuals. Second, there's the fact that the 3 biggest corporate contributors get 100% of representation, and smaller contributors get none in practical terms. This is presently causing some of the smaller contributors to leave Istio. Overall, the Istio SC is a great example of how not to do an SC. I'm not saying SCs are bad, particularly as someone who is currently an elections officer for the Kubernetes SC. What I'm saying is that SCs do not work as a substitute for having balanced technical leadership. I big, successful project can often use an SC to supply leadership beyond the technical, but that doesn't do anything to fix technical leadership that is concentrated into too few hands (whether corporate or individual). What I'm particularly opposed to the TOC doing is imposing an SC on projects that have governance problems. If a project has broken governance, adding extra committees will just make it more broken -- particularly since unbalanced governance problems are often reflective of other issues like contributor recruitment issues, i.e. if you can't recruit outside contributors to your maintainer group, why would you suddenly have the ability to recruit knoweldgable non-technical people to your SC? The solution is to fix the recruitment problems, not add an SC if the project doesn't otherwise need one. -- -- Josh Berkus Kubernetes Community Red Hat OSPO
|
|
|
Re: Istio Steering Committee
Kris Nova <kris.nova@...>
I see - well good on them for getting a steering committee in that case!
On Tue, Aug 25, 2020 at 12:04 PM Alexis Richardson <alexis@...> 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).
This thread is specifically about steering committees, and what they can help with especially governance over direction. And avoiding open core feature withholding.
Istio just launched a Steering Committee and that's why it is relevant.
Excuse my ignorance here - but I thought Istio wasn't a CNCF project? Is there an official statement anywhere on where Istio landed? I am confused why I am seeing Istio threads like this if it's not a CNCF project? Or maybe it is? I honestly have no idea.
On Tue, Aug 25, 2020 at 11:52 AM Josh Berkus < jberkus@...> wrote: On 8/25/20 1:42 AM, alexis richardson wrote:
>
> Istio is highlighting some benefits of an SC model
>
> 1. Applies across whole 'broad' project not just repo level
> 2. Encourages diversity via non coding SC members, eg as Dan says you
> can also write .md files
> 3. Focus on overall direction on behalf of end users and community
> (avoiding the open core problems we see in other cases)
>
The Istio SC is a serious political problem, and the project has ongoing
governance issues. Why would we want to emulate this with CNCF projects?
An SC can be useful to a project that is large enough to warrant it, but
it isn't a cure for projects with problematic governance. A project
with broken governance will just end up with a broken SC.
--
--
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
It isn't but it has aspects we can learn from (good and bad) as do other projects (eg apache kafka to name one).
This thread is specifically about steering committees, and what they can help with especially governance over direction. And avoiding open core feature withholding.
Istio just launched a Steering Committee and that's why it is relevant.
Excuse my ignorance here - but I thought Istio wasn't a CNCF project? Is there an official statement anywhere on where Istio landed? I am confused why I am seeing Istio threads like this if it's not a CNCF project? Or maybe it is? I honestly have no idea.
On Tue, Aug 25, 2020 at 11:52 AM Josh Berkus < jberkus@...> wrote: On 8/25/20 1:42 AM, alexis richardson wrote:
>
> Istio is highlighting some benefits of an SC model
>
> 1. Applies across whole 'broad' project not just repo level
> 2. Encourages diversity via non coding SC members, eg as Dan says you
> can also write .md files
> 3. Focus on overall direction on behalf of end users and community
> (avoiding the open core problems we see in other cases)
>
The Istio SC is a serious political problem, and the project has ongoing
governance issues. Why would we want to emulate this with CNCF projects?
An SC can be useful to a project that is large enough to warrant it, but
it isn't a cure for projects with problematic governance. A project
with broken governance will just end up with a broken SC.
--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO
--
Kris Nova Chief Open Source Advocate
85 2nd Street San Francisco, CA 94105
|
|
|
