Add a meeting Rate this page

A

Hello.

B

Thank.

B

You.

B

Don't worry about.

B

That.

C

All right, we are just at the top of the hour, so we'll give it a few more minutes for folks to come on in this. One may be a pretty late meeting, because it's kind of a special edition so but alexis thank you for dropping on in josh you're. Here too excellent.

D

Hello.

C

Hello, excellent hello, you made it as well, I wasn't sure if people were going to make it, because this is the uh the time where zoom started gating meetings. I think I caught everything.

E

Yeah I I when I clicked on the link, I thought I was going to have to press some sevens or something, but it just. Let me in.

C

So the the links have been set up that the passwords are embedded in there, so folks should be able to get in. um But you know it's we'll see what happens this week as far as like who gets in and all of that so.

E

Alexis is here hello,.

F

Hello, liz.

E

How are you hey everyone.

F

Good, I guess thank you. It feels like coming home.

E

If, at any point you feel like you know, you want to take over.

F

Thank you, but no.

E

How are we doing? I.

F

Know that's left super glue on the steering wheel.

F

Bye.

E

There we go god, I haven't seen you in person like seen what you look like alexis for a long time got more beard than last. I saw you.

F

It gets shaved every three weeks. Okay, this is not officially a beard.

C

Okay,.

C

Justin cormac ping me said: he'd be a little bit late, but um I think we can go ahead and get started as far as.

E

Getting started looks like we have a good showing of people. Welcome everyone all right made it normal things.

E

Mysterious passcode.

C

Game.

E

On okay game on so I think today it's all about graduation requirements, maintaining diversity and alexis's uh kind of suggestions around steering committee, and um you know how we might be able to help projects and enable projects to run in a you know, a way that is good for the entire community, uh while also you know well, that's be good for the entire community in broader ways than we currently require. So we currently have the multiple organization requirement on maintainers.

E

We, I think we have all acknowledged that the definition of the word maintainer is a bit unclear.

E

Maybe there are other vested interests involved in projects. Other ways that we can you know doesn't all just have to be about code commits alexis. Do you want to talk us through your proposal and why you.

F

Hold on, let me just I've got a stripe of sun on my face, which is going to turn me into stone.

F

Right um thanks everybody for being so patient on this.

F

Let's see if I can try to summarize what we've got to in the many many many discussions that we've had on github on email on twitter and probably some other places that I can't remember right now.

F

um I think that the key objective for me uh stems right back to when we formed the cncf and wanted it to be a place where all sorts of different participants in the industry could come together and benefit from the things that a foundation can offer, including a firm legal uh basis for sharing intellectual property, um a marketing umbrella and potentially other things as well, and um I was certainly very keen to see what I thought of as high velocity projects uh be in the cncf and I'm delighted that we have some really good high velocity projects like envoy from um lyft originally and prometheus from soundcloud, uh which came in, but also.

F

I think that some of the sources of innovation in our industry are from from isvs, and I've been in many isvs myself.

F

Small independent software, vendors and I've also worked in larger companies that have partnered with them and acquired them and so on, and I do feel that they have a special set of challenges which we need to understand better and we do have companies and teams associated with cncf, some of whom are vc, backed some of whom are not, um who I think need to be heard and listened to and supported so that we have um big and small vendors as well as big and large end users.

F

Sorry, large and small end users in in the cncf a sort of four-legged table, and I think that if we stop supporting isvs, we might find the table wobbles over and just becomes a three-legged table. That's half on the floor so um going to the detail and that's why for me, what I would really like to hear today is the views and real challenges that have been run into by independent software vendors, with um getting more maintainers retaining maintainers and maintain keeping up the the mix of maintainers.

F

I just want to say first that I know that the um maintain the diversity language has been in there for a while, but I do think we should reserve the word diversity for other uh social and political purposes and focus this maintainer issue on some other language that expresses you know a mix of companies or some other concept that expresses.

F

We did discuss this on github or already, and so um for me, the question is what are the downsides of single vendor open source or open source projects where there is a lot of initiative coming from a single vendor and I've seen um various different versions of this over the years and I've seen it to be very successful under foundations? I mean, for example, we talked about. I think the example of kafka on the apache software foundation, asf, where um most of the committers and maintainers are people associated with conflict, but but not all.

F

uh That seems to be one where the community feels it's maintaining a decent balance. I think that's a pretty pretty good situation, um but there are other ones as well and not all projects are as big or mature as kafka. So how do we help smaller projects get there, and I believe it's very, very important that whatever we are doing, we are helping projects if we're helping projects get to where they need to be.

F

In the long run, then end users will have the confidence to trust us and our recommendations and thoughts around projects architectures and the whole cloud native uh tool chain, and if we don't have that trust, then they might as well use something else.

F

So what are the two issues that came up again and again when we talked about this before what were the downsides of um having a concentration of coding, maintainers um associated with one or a handful small handful of companies? Really it came back to two things.

F

One of them was um this issue of the sort of uh I think what was the the project that was acquired by apple and then disseparated. I can't remember what it was called the database project. um Thank you very much. There's the foundation db problem. Where you know a project. A um has employees associated with it from a single company that gets acquired goes into large co, which, for whatever reason it may not be malicious.

F

Then just basically evaporates all the work on the project and somehow there isn't a mechanism for rescuing that situation, and I think that um I'm not convinced this situation is truly mitigated by having um multiple vendors, I think, having lots of vendors helps in the case of something like kubernetes, that's a big enough project to sustain um acquisitions and all kinds of changes, but there are other projects that are smaller and medium-sized. Where you know, even if you had two vendors, it would rock it quite a bit to have something like that happen.

F

So I believe that that's worth discussing- and I think the lf is- can play a role here in helping projects to migrate, and I think the lf should provide an underwriting guarantee that in some sense this can never happen to a project.

F

It will always continue to exist in some form and then the other thing is um this issue that I described in great depth um in the document that I sent around about the so-called steering committee proposal, which is this feature, hold back open core thing and for me I think this is the number one thing that really upsets me about um commercial, open source and some of the more recent debates around licensing models.

F

I think that um there is a I just don't like projects where the project is crippled or held back in some way deliberately due to a servicing someone's commercial strategy. I just think that if you're gonna play the foundation game, you have to be willing to have a fully featured product and sell ancillary things. Like you know, in the case of cinedia, uh nats is fully featured. They have a separate product in the form of a sas.

F

That's an example, um and I think this comes up again and again, there's also uh reality that needs to be recognized um not in a small group of engineers, it's very very hard to add all the features everybody wants.

F

So you know you do need to prioritize things, and I've also seen um other projects like prometheus, for example, have problems with um feature hold back, not for commercial reasons, but simply because from time in the past, there's been a tiny group of maintainers and far too much work to do so, they just haven't been able to keep up.

F

So it's often not a malicious situation, but I think that it's really important that end users have a voice in this process and we see a well-governed project as one that listens to its end users and doesn't hold back features. That really ought to be in the open source project.

F

I mean for me that is the number one goal of graduation other than long-term stability, and I believe that uh individual companies or teams or groups you know other weird structures that we haven't thought of perhaps should be able to convince uh the cncf they've they've taken this seriously, and so one model that I thought could do. That would be the so-called steering committee.

F

Now I don't think the steering committee is the only model for doing this, and I would like to briefly uh note some alternatives.

F

uh First of all, one alternative certainly is for every project to be like kubernetes, to have a large number of vendors and to have a really nice um quite complicated uh governance model with with sigs and steering committees and charters and elections. That's great. If you've got a big enough project, then you have um the other model. Where you don't actually have a steering committee.

F

You continue to have a repo level or org level management committee of maintainers, but you change the notion of a maintainer so that it's not only coding people but can include end users, people who do documentation, uh people who organize events- and you know anyone else that I haven't thought of who is involved in the project and one thing that I really admire in the world of kubernetes- is the way that they have accommodated uh that type of person non-coders in their structures, and I see people being elected right now, standing for election to the kubernetes steering committee, who won't necessarily be coding on kubernetes but are heavily involved in some way in the project.

F

That's great! So that's another model and then there's another model that I proposed, which is the so-called steering committee, which is simply a recognition that end users and coders and documenters and other people with a stake in the project, could form a oversight committee which acts at the organizational level by which I mean, uh let's take prometheus as an example, there's a prometheus org and it has multiple repos and the maintainer is associated with the repo. So this is an org level structure.

F

It meets periodically it acts as an intermediary between things that are concerns of maintainers and repos and the cncftoc itself. So it can listen to, for example, complaints about people being unfairly treated like. Why is my contribution not being accepted? Is it because I work at ibm? Is it because of some social discrimination, or is it because of a technical reason, and that would be a complaint that could be heard at that level?

F

And then, of course, there is the extreme exception of if things are still not being sorted out properly, they can go up to the toc. So the steering committee isn't acting in lieu of the toc.

F

It's there to provide good, transparent project governance at the org level uh involving end users involving documentation, people and other members of the community, in what I hope is a very healthy way and my intention there was to open up the org level governance more so that people who were non-coders could get involved, and this, I believe I hope, would help um some of the folks like buoyant sorry, storage, os, uh upbound uh and others who um are behind some very exciting projects, like you know, linker d and others so, and I also want to stress that I don't believe that, for me, weave works is anything to do with us.

F

We are completely committed to the what I would call the previous cncf model with all of our projects. We happily work with refiner labs on cortex and other people on flux, and we'll continue to do that. So we're not looking for anything like this, but we do want to see. I do want to see healthy projects like linkadee, get help in this regard, and that's as well.

F

So I hope I've covered the aim of the steering committee, which is to solve the problem of an open, fair roadmap involving end users and also perhaps help us to focus on the other problem of the foundation db issue and thereby give us a different approach to governance than simply mandating multiple vendors be involved at some scale.

F

Does that answer your request for an intro liz.

E

I think it does.

E

Okay, so I wonder if the next set of people- uh I'm I'm thinking the working group who looked at governance, governance working group, I think you're called yeah josh. Are you a good person to speak for yeah.

G

um And unless dimms is not on this, is he he took the lead in this particular issue.

B

Jim's is on.

G

Oh yeah, um the um do you want to summarize um and we wrote this up and sent it to the dlc. But you want to summarize um where you found problems with this particular proposal, not the general concept of steering committees, but the particular steering committee proposal being made.

D

um So I think alexis addressed most of the things that I was going to comment on, so it's hard to um how to do that right now. um So one thing that I was thinking about was like: how do we set up like a progression where um the com, the project, might start? The way um you know alex is laid out, for example, right and then how do we uh over a period of time? Maybe they start getting attracted attracting more um contributors from different companies? How do we get them to progress?

D

It's almost like um in a contributor ladder in kubernetes is for getting contributors to go where we want them to go, um so this would be like a ladder for how do we get projects to go from, like you know, to a better stage than um or aspire to something more um you know. So that is the kind of thing that I was looking for um and you know, because I don't want people to say.

D

Okay, I'm going to pick this, I'm going to stick to it and I'm not I'm going to stay with it like.

D

So there should be a life cycle for things progressing forward um in terms of uh what uh the people in the project can aspire to and the people looking at it from outside can aspire to as well. uh Does that help uh alexis josh.

G

Yeah, the the other thing we discussed is there's a huge difference between a syrian committee that exists, because these people are actually leaders of the project and a steering committee. That's been imposed by the cncf, where members of the steering committee are not necessarily otherwise involved in the project, and we felt that the second kind of steering committee would be completely ineffective in resolving any issues around multiple organizations ability to participate in the project.

G

um The um and you know so.

G

What we actually drafted um uh and have not submitted yet to cncf is to have um a more general sort of conception of project leadership, regardless of where that leadership resides. You know, sometimes it's just the group of maintainers on the core module. Sometimes it's uh technical toc.

G

Sometimes it's a steering committee um the um um and that's where it's important to have multi-organizational representation of some kind, um the um uh because I certainly agree with alexis that you know the term maintainer within the cncf contact is extremely loosely defined um and- and even if I look at a couple of our projects, getting down to trying to tell the projects to reword how they define their own contributors, which is really.

H

Not.

G

Where we want to be.

G

The um so um when we raised some objections to alexis's actual full proposal it had to do with.

G

There was some conception in there of having a steering committee that would actually be assigned by the toc instead of coming from within the project and importantly, that that steering committee wouldn't necessarily actually be project leadership, um because because down there, because when you say that you just said this again, that if there was a conflict between the steering committee and the people with merge rights on the project that the steering committee still wouldn't be able to do anything about it, they would have to take it to the toc.

G

Whereas, if you look at other projects like we just went through this long process of revising the steering committee for k-native and the steering committee actually has the rights to tell people to do things.

G

um Instead of just being there in sort of an advisory capacity.

E

Although I think there is some uh benefit in having a group of people who are in some way more closely involved with the project who can serve as some kind of intermediary or sounding board between the people who have a concern and taking something to the toc, I mean ideally things get raised.

E

The toc is ultimately there to try and smooth over and help resolve issues that might come up like that, but we're not involved in every project day to day and the steering wheel could be more knowledgeable about the actual operation of that project. I don't.

F

Think that the um a steering committee would be welcomed at all by the maintainers if it was imposed from above. There was a group of random folks who you know it's like it's the classic kind of architect astronaut problem, and I also- and I also- and I also believe, the ncf's existence, which happily, we managed to fend off. There was an early desire for sponsors who paid for membership to form essentially groups of people who wrote product requirements, documents which would then be sort of imposed on the projects.

F

And um you know I had to sort of fight against this because it was sort of going to break the will of the poor people working on the projects to have this sort of thing going on. It would be much better for those things just to service, naturally through the community, which in fact they do in most of the projects. So I believe the steering committee or if it includes end users and people who do other non-coding activities, should it should arise naturally and organically from the community itself, who are around the project.

F

And I point at kubernetes as a large-scale example of such a thing. um I don't know quite how this has been achieved, it's to the credit of those involved, but certainly there are all sorts of interesting people who don't all write, kubernetes core code who seem to be welcome, included and and have surfaced through the system in a good way. So, let's try and capture some of that thinking.

F

If we come up with a steering committee idea for smaller projects,.

B

And to jump in here on this, I think there there's an important element. You brought up that happened in kubernetes right, you saw people who chopped wood carried water did work, it's not an advisory group or people who have opinions on what a project should be that got involved in the steering committee model or even got involved in things like say, docs and other things that aren't working on core code. But it is people who ended up chopping, wood and carrying water and being involved in the day-to-day. They didn't show up for meetings.

B

They didn't show up with ideas of what other people should do. They showed up and they did things and they earned respect that way, and I think that in any steering committee model needs to be there or the people who are contributing code.

B

The people who are around them aren't going to have that same level of respect, they're not going to want to listen to them, and it's going to create a well, not a great community, and then I think the other thing to think about here is lots of people have opinions on what a project should be, and it's also important to say: no, that's not what this project is.

B

That's a great place for this other project or that's a great place to create a new project to solve that problem and as somebody who's worked to maintain things as a kubernetes sig chair and on helm and with different things. What I've learned is lots of people have opinions on what you should do and if you go down all of those things it's going to be the death of a million paper cuts because you're getting outside of your core thing, and so whoever's on that. Steering committee also needs to be of here's.

B

What this project is here for and kind of hears its boundaries, and if somebody wants to go in a direction, that's different from those boundaries, then that's a great place to encourage something new or encourage the use of something else.

B

That's complementary, rather than try to grow to be all of the things and I think some of the most successful projects we have have done that and you know in kubernetes lots of times they say we're not adding new controllers to core, but you can extend core to create your own because that's not us we're ending our boundary here, but we're giving you a plan a place to go further and I think a steering committee needs to have the knowledge and wherewithal to do that as well in any model, and I think dims has his hands up so polite.

B

So I want to point to you next, okay,.

D

uh So I don't want to talk about kubernetes, but I do want to talk about uh turning the view from okay, the solution to the problem and the problem is what can end users of a of a project expect from the project right? uh How can we surface the information on the how the governance works, or how do we give them at one glance that look? This is a project that works this way right.

D

um So one of the ideas that we had been throwing around uh in in the governance subgroup was: uh do you want to talk about it, josh the tags.

G

Oh badges yeah, um the.

G

We're still not, we still haven't finished. That proposal, though,.

G

Which I need to ping you about so yeah.

D

Yeah, the the short version of it is like how um so the toc can apply badges to projects and the badges can give some information about how the project works or what state it is in. uh We can include all the in stuff that we already have like incubating levels and whatnot right, but then we can also have additional badges based on different criteria and within each like groups of badges they'll, be like a progression that I was talking about before right so and so it we kind of like give guidance to the project.

D

Saying: okay, go from, you may be starting with this bad set of badges. But then this is what you need to aspire to and you can earn the badges as you go along right and then this is so when uh the toc um does annual reviews or uh whenever it talks to uh the different projects, then the toc can say: oh now looks like uh they.

D

We can call them like whatever uh multi-vendor or whatever right so uh and they go from a single vendor to multivendor, so the so and the end users of the project when they come to a project and they look at it. They'll say: oh okay, I know what to expect from this project. This is the set of things, so that was the kind of idea that we were uh chewing on, but we haven't finished it yet.

F

So I would like to support that idea, but I think it's an overlay to all of this, so I believe that, um funnily enough, I discussed a very similar concept with abby when she was running cloud foundry.

F

um The end users would love to know for specific features, how many vendors they can get support from, and we could have a whole completely different hierarchy for graduated projects of commercial badging.

F

You know bronze silver and gold, reflecting that uh your bronze project means you can only buy things from one vendor silver means you can buy from more than one vendor and gold. You know, there's lots of vendors or something like that would be pretty cool because then you're sort of making it into a business thing and end users can then express their preferences in business ways. I think for graduation.

F

This should be about governance and making sure that the project is well looked after, has good mechanisms dealing with complaints and error handling and such like in a way that the toc can provide um a blessing for and support too, without creating an administrative burden for itself and in terms of um how? How do you get people going? um There is one example of this out there, which is the upbound uh bassam, has got a thing for their cross-cloud project.

F

I think which is quite formalized worth having a look at for prior arts, but you know there might be others out there that we can take as a starting point. I believe colin wants to say something.

I

um Yeah thanks alexis and by the way, thanks for all the work on the steering committee doc, that was uh those really good stuff um at a higher level and we're kind of dancing around this but and alexis you started talking about this. What does the cncf wish to convey with graduated status, to the users.

F

I think it's about being stable here to stay, um and people can make if you're, if you're a big it shop. You want to know that you can basically put your money behind these projects. That's what it really comes down to. I think I know that there are other people in the world and we should think about them too, but ultimately, I think the people who are really paying closest attention to this are our folks making big risky bets on the technology.

F

So I think we should make sure they understand that the technology is is, is relatively likely to continue to exist and is being looked after by the cncf and the toc to to to keep it on an even keel to keep it moving forward. Now that doesn't mean that there that is impossible for a project to run aground, but I think it's it should be a lot harder by the time it gets to graduation.

E

Yeah agreed, I think, we've used quite a lot of language around risk. You know in uh coupon discussions uh presentations, for example, at graduation, the risk sufficiently low that it's fine for basically mass adoption.

G

Yeah the I I'd like to talk about another aspect about risk, just because this is something that has cropped up um for me recently in projects outside of the cncf, um which has to do with um vendor risk as well.

G

So um I work at a vendor that often decides to participate in open source projects that were started by other companies and to incorporate those into our stack um when we incorporate a project into our stack. One of the things that we want to know is that the you know, other folks involved in the project are not going to change that project in a way that breaks our stack and the best way for us to ensure that is to ensure that we have some kind of voice in how the project is run.

G

um I think this really needs to be a critical part of how the cncf looks at the multi-organizational requirement.

G

As in if a project gets to graduated, and at that point it is still run entirely by one organization, and that organization has the ability to break compatibility with other projects and with other products um through an internal process right. They make a corporate strategy decision and it breaks everybody else's stuff. Then that's kind of a major problem.

G

um You know, and- and I'm not talking about you know other vendors, getting to say how the project is wrong. I'm talking about other vendors who want to put people on the project to make sure that it maintains compatibility with their products and are prevented from doing so, and we would like to think no one would do that, but I can tell you from other outside cnc projects. I would name this happens.

J

Can I add something here, so uh I think if we peel this back to the fundamental problems that alexis laid out, I think one is ensuring that end user voices are heard on the project even once the project is graduated and two is ensuring that uh the co, a given project, is not at the whim of a single company in terms of longevity uh in terms of kind of what the project is implementing and that kind of reflects itself in that making sure that they're building, something that end users want- and I think both of those problems are very legitimate and ones that the toc should look to resolve.

J

I think the problem I see with the steering committee solution is that it's an imperfect solution for both of those problems. If we talk about maintainer or we're calling it multi-organizational, uh I guess diversity.

J

The problem with a steering committee approach is that you know what we're trying to address. Is you have a project that is effectively you know all the maintainers are from a single company, and that is problematic so to address that we're saying, let's, let's put in a steering committee and the steering committee could be made up of folks that are from other organizations. Potentially end. Users are not completely unrelated to the project, but then the question comes down to. How do you maintain kind of the relationship between the maintainers and this committee uh in general?

J

I think what we've tried to do with kubernetes is maintain a strict wall between the folks who make technical decisions and the steering committee and we've said that the steering committee does not influence technical decisions and the only way that you get to make technical decisions or become a technical leader is through contributions, and I think the way matt described it was lots of chopping wood and carrying water, and so that's something I think we would like to maintain.

J

But where we're kind of it's, it's a we're in a tough spot right. We want this multi-organizational kind of cooperation and maintainership, but at the same time we have very good projects that don't have this, so we're kind of struggling to find a governance model that would allow us to have have both effectively, and so I I don't know a steering committee could work.

J

I'm not sure it's a perfect way to be able to address that issue and then going back to the second issue of listening to end users and ensuring that that feedback is incorporated back into the project roadmap. You know a steering committee is made up of a fixed set of folks. It may be that today you have users a b and c, but in the future you may have d e and f right.

H

Yeah reviews.

J

Right right.

F

You won't.

J

Be seeing you.

F

Otherwise they will die.

J

And ideally, you know if we have things like surveys or or I think the idea of an evolving or dynamic group of of end users who come together periodically would be very interesting. So I think what I'm getting at in this long-winded way is that I completely agree with the problem set. I think what I'm concerned about is dictating a very kind of narrow solution from the toc.

J

Instead, what I'd like to see is sorry. I just wanted to complete my thought. What I'd like to see is the toc would, instead of dictating a solution, would instead dictate just the problem statement in saying that hey as a project that is going to graduation, you must provide two things. One is a longevity plan, which means if the one company behind this project ends up disappearing.

J

How do you ensure uh longevity, and so then it falls on the project to figure out how that's possible and the same thing with with user feedback. It's give us a plan for how you plan to incorporate user feedback so, instead of the toc enforcing that we become kind of fake, hey get you tell us what works for you and the toc can determine whether that works or not.

F

I really like that.

F

I, I think that's a great formulation of one of my concerns through the process of discussing this with everybody has been to focus on outcomes not on not not on the means for getting things um stipulating that the toc must be convinced of the longevity and fairness of the roadmap would be great and then individual projects can solve that in different ways: we're not trying to mandate a steering committee.

F

It's it's one potential solution to the roadmap problem and possibly might help with the other problem too, but it's not by any means the only solution and it may not be to everybody's liking.

F

So that was the thought sad. But I really like your formulation.

J

Got it? Thank you.

J

I think alex has his hand up alex.

A

Yeah, I just I just wanted to sort of summarize something small. So if, if I take this back down to sort of the core, I guess what we're looking to do is to have graduated projects that are dependable, long-lasting, etc, and you know, as as alexa said, they're projects that, after due diligence and after that stamp of approval from the toc that companies can depend on that companies can put into production right. It's it's it's that definition.

A

um I guess what we're trying to say is that, in order for those projects to be dependable and long-lasting, they have to have user input and they have to have that roadmap and they have to have um you know a dependable future, but there are probably multiple ways of ensuring that happening and having, and we we probably.

A

I guess the cncf should be flexible. Having multiple containers could be one way of doing it. Having a steering committee could be another way of doing it, but you know, as sad said there might be.

A

There might be other ways of doing that as well, um and yet I can't help thinking that we should still have some high-level guidance of you know what is a good idea and what isn't a good idea or what's worked, and what hasn't worked, because um I kind of feel that otherwise we're going to end up in circular loops every time we do a due diligence on one of these projects and it becomes a very subjective decision.

A

So you know a syrian committee could be a good idea and it could be a way of ensuring longevity multiple maintainers could be. Of course, you can always argue that either of those things could not necessarily ensure the longevity or the or the roadmap, or you know, because some there are definitely projects with multiple maintainers that have had those sort of issues too.

A

um So we probably should have maybe a handful or one or two or three methods that the toc probably says. Look. These are things that we can recommend. um But yes, ultimately, it's up to the project to prove it, but I kind of feel if we don't have any guidelines at all and just focus on the outcome that then we end up with a very, very subjective decision process.

B

Might I suggest we do three things one uh kind of document and agree to the outcomes we want first right, let's just start there, rather than the model of how you do it and then the second part is for each of those outcomes document, hopefully two or more patterns that can be used to solve for that outcome.

B

So people can see, there's different ways of doing it and then, after all of that, take to maybe a few different projects that do their governance slightly different and point people to these as examples that they could use as starting points if they wanted to understand how this worked as a whole. And then you get your outcomes, you get a general set of patterns. People can look to, and hopefully understanding of, why these patterns work and take them from successful projects.

B

And then because one of the things that I've been asked by several sandbox projects lately is, I need to go, do a governance. Where can I start, and of course you tell them, go look at this project or that project, but they also want to understand why and what patterns and so by pointing them at some projects that have solved for it, then you also give them a good starting point. I think, if you have those three things, it would help us get past this hurdle without recommending just one way to do.

F

Things.

F

Having a couple.

K

Of days.

K

Yes,.

F

Sorry.

E

Reading a couple of last comments.

E

I guess it crossed my mind that we were talking about one of the problems being user feedback or input onto and.

E

You can see arguments both ways for whether a single vendor maintained project should also be influenced by other vendors.

E

I think josh's uh kind of nailed it when he said it's not feedback there as contributions that we would expect a well-governed project to accept contributions from other vendors, even if those vendors are competitors to the single vendor who's. The main maintainer of that.

E

Project, I guess that's one thing that a steering committee model can allow. You know if you have multiple maintainers, that also you know you want to prevent the veto from a single vendor right.

B

Yeah and and just one of the simple ways to do that is whoever your top body of maintainers are: don't let one company in a graduated company have a majority of those maintainers right, because then you're you're forced to have at least three different organizations with maintainers and they have to coalesce. In order to do that, and so there is a pattern you could say you know, no one vendor has so control of the project. A pattern is your top governing body.

B

No one company can employ a majority of those maintainers at the top level right and then you could point to a couple projects, helm and kubernetes that already do this and they do it in slightly different ways right, um and so there you've kind of got your stepping stone, but it starts with that criteria.

E

And I think that's why we've up until this point had that definition of multiple maintainers and not wanting to see a single maintainer having control over the project? I guess what we're now saying is code. Committers are not the only body. There can be a another level of body who uh and are we saying they don't make technical decisions, but they are a body to whom people can bring complaints if they believe.

E

I guess that's actually part of the that's, not the problem statement right, so we, I think start making. A very good point about um saying here are the two problems. We need your governance model to solve longevity and, let's say input to the roadmap.

F

So liz, I think one out one one artifact that could be created by a steering committee is a road map. I'm not sure this is the right thing. Okay, it's brainstorming live here, but, um and you know, a steering committee could produce a three-month a roadmap every three months that could be a recommendation and that reflects that it's taking input from end users on high level direction of the project. um I think that would go a very long way to dealing with this issue.

F

um I mean I would love it if everybody could be like kubernetes, but they may need to go through several stages to get there, and this is a an interim stage, just the thought.

E

uh Josh, do you have your hand up yep.

G

Yeah so um two um two things here: one is, you know in a comment for a sort of sod's thing about um uh uh outcomes and that sort of thing one of the things we could look at and speak here for contributor strategy is asking projects to specifically have a plan for recruiting and advancing contributors.

G

I mean at least from my perspective, when I'm evaluating a project, even if the project currently all of their senior maintainers work for one organization, if they actually have a published contributor ladder that demonstrates, you know a clear way for any contributor, regardless of who they work for to advance to senior maintainer status.

G

Then that's a very different situation from a project where all the senior maintainers work for one organization and they don't have that um the um says thing number one. The other thing I want to remind people of- and I address this on, the toc mailing list is well it's important that, whatever structures we have are capable of taking complaints, we can't rely on complaints as a way of determining whether something is wrong.

G

You know again speaking for somebody who works for a publicly traded company.

G

I can't simply, as a contributor bring a complaint about a project run by another company that has to like go through my executive management, and so unless the problem is really disastrously serious, I'm not going to do it um and I think a lot of other contributors from the cncf ecosystem are in the same situation.

G

um So I mean we do need to deal with complaints, but that's not a way to know whether or not something is wrong.

B

And- and I I like what you said, though, with the whole contributor ladder thing um what's been said there, because it's not just that, somebody who approaches the project knows how to get up uh to go up the ladder to become a maintainer. It means those people who maintain it have had to think about how do they bring in new people and how does that process work uh for lots of maintainers who just want to go sling code work on things.

B

They may be great at getting feedback that whole world of mentoring, bringing in other people is foreign to them, and I think for a lot of the folks who are going to do that, they're actually going to struggle with this and giving them people who can help them figure this out and understand it and maybe mentor them when they start going from other projects who already know how to do. This would be really useful and kind of a benefit of the cncf, because right now, a lot of projects struggle to bring in new people.

B

But yet they don't know how and coming up with that plan on. How and thinking it through is useful for everybody involved, not just people who want to become maintained.

F

It's also important to retain maintainers. That's been a big challenge that I've seen with smaller companies. Like you know, boyan mentioned this- that you know somebody comes along, contributes for a year and then for some reason they disappear. So you need a sort of critical mass of other people in order for this to work.

G

I'm trying to see if paris wants to speak out loud um the I mean that's pretty much why we started sig contributor strategy, because we saw that a lot of projects needed help with these things.

L

Ignore my ignore my work from home bed head.

L

uh Yeah so yeah.

L

This is the exact stuff that we're talking about in contributor strategy and, like, I think, ultimately, what you're saying is like we're dancing around this notion of of community management and maintainers doing community management, and I really think that there needs to be a community management strategy at the time of graduation and that's sort of hand in hand with what I think saad was saying, as well with like some kind of strategy on how you're gonna get to where you need to go, um and especially with how are you gonna, take care of your people because there's multiple ways to do that, as we see with multiple projects, there's sigs that deal with contributors working groups that deal with outreach, full-time community managers, part-time community managers, but in my research that hopefully I can present at some point when life isn't weird.

L

My research is suggesting that the open source projects that have that kind of a strategy are longer lasting projects and projects that are more transparent and projects that are also more aligned with urban governance.

L

So I think that's one of the the crux of the the issues at hand is we have maintainers, we have maintainers burning out and working on 800 million things, and not necessarily thinking about the long term strategy in the long term is community management.

E

I wonder if um colin or someone else representing one of the those- let's let's say I don't mean this pejoratively at all, but let's say a single vendor uh project.

E

How you feel about this idea of contributing ladders and community management strategy.

I

um You know I'll share our experience and then maybe that can inform from the discussion um we have about 90 repos in under gnats and there's there's only two that were really um you know not to use inflammatory language flagged as problematic by the toc and and they were our server repos. So if you look at maintainer mix as a whole across snaps, we're actually pretty good in these two repositories: the server repositories um they are isv led and and cinedialed- um and that's that's because we we know the code.

I

We have efficacy in solving problems and responding quickly to to bugs they're very complex. So it's not a weekend project. It's not something! Somebody can. You know even come in in a week and learn it. It takes a dedicated resource and we kind of have a chicken in the egg problem right. We're solving these problems quickly, we're moving very quickly the project's moving quickly, but we're doing everything right. So our end users, don't see the value in adding a resource to the at least to the servers they do with clients all the time.

I

We get contributions all the time on the client side and connectors bridges that sort of stuff- and this is where I think a steering committee- would really help us out, because the servers you know and one one other comment I'd like to make is in order to get to be a successful product project you need to have, you know, solve the market problem and then listen to your users to continue to evolve and solve that problem.

I

um So I would argue any any project. That's that's, has a velocity and meaning maintaining and gaining adoption and users, and pr in particular, if they're production worthy, if they're being used in production, they're doing the right thing, and I don't think you should really change much in their process of listening to user requirements.

I

But I I went off on a little tangent there you know back to getting maintainers. um We have tried to get maintainers for the servers and we we have some. We have a couple external maintainers, but um you know again. This is this is an area where we're doing things uh you know we're doing things very good, so people other end users, don't see the need to add maintainers to these particular repositories of our prod project.

I

A lot there did, I answer your question.

E

I guess I was wondering how you feel about the idea of uh if we were to make requiring a contributor strategy to be part of the graduation requirements.

I

A contributor strategy is you're talking about like the maintain a ladder. How somebody.

M

Can.

I

Get on the project and move forward, I don't see a problem with that.

I

Where, where I would be concerned, is what happens if you know, let's say we get somebody that that meets the bar to barely be a a maintainer to work on the server right and then they don't really do much, because everything's working will that be an issue for graduation.

E

I think what we're saying is if we are changing the requirements so that other governance models such as steering committee so long as there is some kind of multi-organization.

E

Well, actually so long as it solves the problems that we're identifying, which seem to be longevity and community input on the roadmap, I think we're saying you don't have to have walked everybody through the contributor ladder, we're saying you have to have a contributor strategy. That means, if somebody really wants to get involved in your project, they can see a path to doing that and that you would accept them if they met that if they followed that path, regardless of what vendor they came,.

M

From or yeah.

I

Absolutely absolutely and we're we're behind the uh steering committee model. We think that would work great for our particular project.

H

Colin just did have you ever had any maintenance who have left scenario.

I

um We have have.

H

They stayed on as maintainers or does that disqualify them from being maintainer.

I

Oh, no, this data.

H

Yeah so because that's actually I mean historically, that's been a good way of which maintainer diversity has increased, is for people to move somewhere else and retain their maintainership.

H

Yeah, that's.

N

It.

B

Sorry.

N

Colin, I'm sorry, colin and so part of the other thing with the nats project and cinada is. We have had folks that do have a vested interest in gnats. They have, they know nats they've learned nats, they come to us and then we hire them, and so now there is no secondary company, now they're all back to the isv.

N

So does that mean that we're not allowed to hire people that have this great vested interest in gnats and can work on that um and we have had you know people leave and then come back. So it's all a bit muddled. When it comes to the experience and intelligence it takes to maintain the nat servers.

F

All right, one of the reasons I was keen on the model that this hiring thing is just you can't prevent that it's very hard. If you stop people doing that,.

H

Oh yeah, I mean you, don't want to stop people doing that. That's kind of not the point either.

E

I I think what you're saying is that if people naturally leave that isv, they don't sort of drop their maintainership, they can choose to continue being a maintainer, even if they move to a different organization.

F

I would consider that to be a healthy thing: yeah yeah.

H

Yeah, definitely I mean it's, it's a you know. It means that people can go somewhere else and contribute with a perhaps a slightly different perspective or something but and things like that, I mean it's. It's definitely been a way in which maintenance diversity has increased in other projects.

E

All right we're very much getting up to time here. I think this has been really useful.

E

I think the key things that came out that I've noted and I'm sure we'll have more debate on this, but um those two problems that side identified. I think we should absolutely say we require projects to if they have a governance model that addresses longevity and community input to the road map.

E

Then you know any governance model that the toc believes meets that those would solve. Those problems should be acceptable. um I think we're also, I mean obviously I'm just summarizing. We haven't had a vote here, but it looks like there's a lot of support for requiring some kind of contributor ladder strategy as a graduation requirement.

E

And I think that the steering committee model- I don't think anybody right now- is suggesting we should mandate it, but that perhaps a steering command committee model could meet those.

E

Requirements did I miss anything particularly critical.

E

Awesome we are one minute over. Thank you very much, particularly alexis for um all the work that you've been putting into thinking about this and presenting it and to the governance working group. Folks for all your work on this as well.

E

Thank you.

M

Great. Thank you. Everyone.

E

Thanks everyone.

D

Bye, everyone.

A

Bye, bye.

E

Thank you bye. You.
youtube image
From YouTube: CNCF TOC Meeting 2020-09-29

Description

CNCF TOC Meeting 2020-09-29