 Hello everybody, thank you all for coming to see our talk today. I think there was a miscommunication This is where we talk about the mean comments. You're not going to throw them at us Okay No, really thanks so much for joining us today. I hope this week has been as much fun for you as it has for me so far Hi, my nickname is dims. I work with Tim in the communities community. So There was this thing that I started a while ago and that turned it into this talk So let's see what we have in store for you About a year and a half ago dims and I started Sending each other our favorite comments from various forums You know as sort of a wait event to each other We've we've both often spoken about Kubernetes and how awesome our community is And I can hear you all now saying oh, no, it's another big community hugfest. I promise I'm going somewhere with this Our users you all are incredible. You're passionate and you are creative emphasis on passionate Every week we hear about somebody who's doing something with Kubernetes that we never would have thought about That we never could have predicted that we don't really understand Which often means that those people find bugs or corner cases or things that we didn't plan for or design for The reality is nobody uses every feature, but every feature is used by somebody in fact Many of the bugs in Kubernetes have come to be relied upon has anybody heard of Hiram's law It's a it's a little saying that says basically Every observable aspect of your system will eventually become part of your API. You can't change things and it gets to be Frustrating time anybody knows how many open bugs Kubernetes has We said that The answer is about two thousand Now I can oh I was my cheater So reasonable people might ask what is wrong with you people like Don't you care I mean of course we care we are all working on this system all the time Right, how many people in this room have submitted a pull request to Kubernetes? Thank you. Thank you. Thank you. How many people here have submitted an issue against Kubernetes? That's a lot more. That's even more And how many of you hit a bug and went? Effing Kubernetes So, you know huge amount of the work that we do day-to-day is not just adding features or fixing bugs So please trust us when we say we hate those bugs as much as you There is nothing There is no feeling like when you do something and it just works right but when it doesn't it can be incredibly Frustrating and hopefully you all file the bug so that we can help to understand the problems But sometimes you file a bug and you don't get the answer you wanted which can result in what my kids would call big feel big feelings Sometimes we get rather strong passionate interactions on our issues and PRs and social media. So I Want to remind everybody here that everybody who's working on Kubernetes to build and maintain the system our volunteers Some of us have been around a long time and have developed a thick skin But some of us have not and they just want to help people to be successful and to participate Behind all those github avatars are people We really really want to help you fix those bugs, but we need your help So when it comes to engaging the project and the volunteers behind it There are let's say more effective and less effective ways to engage So we thought today we would talk about how to engage effectively Illustrated by counter examples So Let's see the usual scenarios usual scenarios for friction, right? so You are running something in production. You have an issue you you see something you Copy you know and an error message you come to github you search and then you what do you see? Two years ago somebody else had the same problem, right? Then the question is like Why right? So Some of this Somebody do something It might look simple, but it might it's probably not simple We have a large user base You know, we are probably gonna break somebody Hiram's law going back to Hiram's law We can't always Accept like a quick dirty hack to do stuff like we are still recovering from things with it 10 years ago We are trying to unwind those things so Even if it is technically simple Sometimes we are not able to do it because of some other reasons We do try to write things down. There is a lot of discussions in Slack channels and in meetings sig meetings and things like that Sometimes we are not able to reflect that back in the github issue that you're looking at but I promise you We've definitely gone through some of these before Sorry about that that we didn't reflect it back where you're looking and not finding the answer that you need So many years of past It's easy to ask a question, you know, it's definitely harder to come up with a solution now Look at the phrasing itself right like they Right like who is they it's all us right like there is no day here. We are all a community We all have to do this together. We are all in the same boat, you know If production fails for somebody it's gonna fail for somebody else too. So, you know, we do have a really good thing called the Cubinators enhancements process Please search for it and take a look and see how we can, you know, make it easier better for you all The next one is We have bots when you come to cubinators We have a lot of bots and they bought contract with you because we are not able to go talk to everybody For every issue all the time, right? So some of the bots go around like cleaning up old issues and like there's no comments from people for a very long time And like why is a bot closing my issue, right? So sometimes it is more about Hey, it's not in our backlog, but it is there as an issue So there is a difference between a backlog where okay, we are probably gonna work on it at some point But you know There is issues like this there are we also have issues from Vendor issues and things like that too But mostly cubinators cubinators is for Development of cubinators itself. So please be cognizant of that and use other support channels when you can So we get these all the time the easy response here is PRs are welcome But that's a little dismissive the deeper responses. Sometimes it's hard few of us on the project are a hundred percent Doing this project. We all have Carved out as much time as we can but most of us have other commitments professional and family real life We may not be able to get to as many things as we'd like to Dims mentioned the KEP process the enhancement proposal process. This is how we can move an idea forward But it's not as daunting as it might sound if you have an idea a proposal You can write a simple doc Google doc and share it around with your SIG or the SIG that owns that problem area It's a great way to get feedback or use the mailing lists and slack to collect feedback and help Understand why an issue is important and why a solution is appropriate One of the primary reasons why open source is so powerful is because people can scratch their own itch Right, they can do their own solve their own problems do their own work Convert energy into action Don't just harvest but invest We need to keep this project vibrant over time. We're here at the 10-year anniversary Let's all pat ourselves on the back and then what is the next 10 years mean for us? I love this one Reminder every flag we add Approximately doubles the amount of testing we have to do we have hundreds of flags We can't just add a flag and run away Last year we spent about four million dollars on Continuous testing and binary serving four million dollars and that number is only going up every year month over month. It goes up When you get that waiting for tests or Have to run slash retest because something flaked. That's a bad thing right that costs real money So please don't mistake your convenience with our convenience So If you have a workaround Just make sure that as many people know about it right like so go to the issue and say hey I found you know, not just you found the issue, but also I found a solution Here is how you do it. Here is a workaround here is something that will tide you over until there is a better fix that is available We have a lot of extensions in Kubernetes, right? You know document your solutions share them widely and if you Want to go a little bit further than you can say hey do a prototype file a PRC which Issue which tests pass or which tissue the test fail, right? So that is another way you can help us right like we don't know like we started started by saying We don't know all the things awesome things that you all do, right? So we don't so it it will only help us if we know more about the scenarios adding more test cases More in adding more integration tests You know there's a backside bad side to it too because it raises our cost, but we would rather have it than not have it Okay How's this one? Have you all seen this in your own open source projects? Yes Okay, at least a few people so I mean you can't appeal to shame, right? Saying real world and things like that, right? So not everything is built into Kubernetes itself, right? That's for a reason How much code can we add into the core Kubernetes? That's why we have extensions. That's why The the sick architecture and all the six work together to make sure that there are enough extension mechanisms for For you all to do the things that you do that you want to do, right? And that is the reason why you are all here. We built up a really good big Ecosystem around this But if you really need something which is not there, we'll figure out a way to work with you on it, right? Just please, you know, we don't want to say no to everything all the time either, right? Once we understand your scenarios once you engage with us a little bit more Then we'll get to know more about your scenarios and then we'll work with you on those things Extensibility has to be definitely number one or our agenda, you know for the foreseeable future So I'll let you read this for a second I think the biggest thing here is like Just resetting this one number in one place. Do you think it's really hard? Right That's a question and the number of times that programmatic Complexity has stopped us from doing something, you know is zero We're not afraid of writing more code, but When we are saying that we can't do something there are some really deep technical reasons for not doing something We do want to fix your problem, but not everything can be fixed. We have to make some hard calls We have to figure out like what can't change right now. It doesn't mean that they can't change forever, right? Like we'll find a better way somebody else will come up with a better way to do it sometime later But it's not the right time to make the change, you know, we might break somebody or you know some other scenarios might break and But this is not the way you should engage in a open-source project to try to change the mind of some of the maintainers You know the the worst part about this one is that up the thread several maintainers had responded but But but OP just didn't like the answers Like please don't go shopping for approvals, right? We we kind of talk to each other We know when this is happening and it doesn't work, right? We have an approval process We have a consensus building process within the community and you know, you're part of the community But you're not allowed to yell at us. That's not okay. We do have a code of conduct We do use it more than occasionally And if you're not respectful, you won't be able to engage with us. We want you here, but let's keep it kind, please I Like this one really they had me in the first half, right? I can understand that you're all loaded awesome rate commiseration right empathy That that acknowledgement is nice, but if it's really a big issue I imagine it's affecting a large number of people. Where are those other people? Can we have a conversation that talks about the magnitude of a problem, right? I like this one Tim's pulled this quote out from from me. So I feel weird quoting myself here, but there's always a cost I've had to post this message many times. There's always a cost I know it seems like something should be cheap and easy, but there's always a cost It might not be paid by you But it does exist and remember that you know open source is made of people and people's time is how we feed it Here is another one right like it feels like you're yelling into the void Nobody is listening to you right like you go there and like you go look at your guitar issue Day after day and like nothing is happening. Nobody is acknowledging and like you're screaming to the wind But the thing here is like we can't go watch all the 2000 issues well 2000 plus Until the bot starts closing stuff The reason is we do have a release cadence you you all know how many times we release in a year How many Three three times okay three times a year what that means is we have a calendar So we have a feature fees we have a code freeze and then we have a test freeze and then we make Release candidates and things like that right so we can't be paying attention to the incoming issues Incoming PRs all the time right so there is a cadence in the community. There is a rhythm in the community There is you know, for example, when we are fixing deep flakes And like making sure that all the jobs are green before making the release We might not have time to go look at a big PR that you just logged right or a cap that you just wrote so if you understand the rhythm of the community then it becomes easier for you to participate and then The karma that you get out of like understanding the process and understanding the what the people are doing and when Will help you make friends and you know, it'll make it easier for you in the long run so The other thing here is like you can ask again So if you don't you can escalate right like you if it doesn't work on GitHub issue If you're not hearing anything from people come to slack, right? We have a mailing list All the six have the same pattern. They have a slack. They have mailing lists come to our meetings We have you know meeting notes throw it on our agenda, you know, make the case Right and be vocal about what and when you bring with you data, right? Like in the end, it's the engagement that we are looking for from you, right? So we know what you want so we can do the right things for you and not guess what you want us to do Right, so you are all part of the Kubernetes team So you're part of the solution essentially And it's not just Kubernetes like all our sister projects face these things to right like Look at this one from for the hell maintenance. What are we exactly accusing people of being busy? right Does it help right and literally I write at the beginning it says it's a plea for help right and the person is Escalating essentially So usually we are our own harshest critics, right? We look at what we've built and we see all the problems and and it coming to cube con is wonderful because I hear people say good things for once But when I look at Kubernetes, I just see a pile of two thousand plus bugs plus the two thousand that got closed by the bot and But sometimes we are pretty nice to ourselves by comparison There's not a whole lot of room for interpretation on this one And to be fair Nobody's really in charge right so you can throw the blame at Google if you like but not really our fault and people do and they do And that's okay We have community governance We have a process that ensures that other points of views are considered and that we build consensus around our decisions and our designs Right, so I don't know what value you get out of posting this in a public forum, but okay This is another fun one. I'm not sure that a raspberry pi is the right yardstick to be measuring Kubernetes I mean I Like that raspberry pi runs kubernetes, but it's not part of our test suite Do we have bugs oh maybe you should sure somebody wants to donate a million dollars worth of raspberry pies we'll be happy to We have bugs yes, do we have terrible code? Yes, I probably wrote it. Sorry But I don't know what you expect here like 11 nines And as far as bug reports go here's one Somewhat lacking in detail Does anybody know what this is really about Can anybody guess what this is about? Good bug reports are worth their weight in gold right good bug report is focused It tells us what happened where and when on what version what symptoms do you see what? Platforms where you're running it against don't just open a bug to vent, please All right Kubernetes has escaped the lab. I'm sorry to tell you all If you hate it, that's perfectly fine. Well, there is also I did want to say this other thing Also, we are not actually using tweets which you can see meme and meme net us and other other things on Twitter We're just using the things that you know hurt us more because you are here You're part of the community and you are engaging with us You know, that's why it hurts more you see So as but on a different note as long as people are complaining about it. We know they are using it, right? That's ever Tell me more It's again, it's not given it is that gets beat up It's Your classic send patches But in truth the only code bases that are not a mess is that doesn't have any users back here So not every bug is about the code. Sometimes the bugs are about the way the project operates to Perhaps we should open an issue tracker that lets you file bugs against people I'm pretty sure I need a bot to close mine But again, I Don't know what the expected outcome here was like do people really think that we enjoy that? Or enjoy that we are going out of our way to prioritize flagellating people A little empathy goes a long way, you know, here's a place where The commenters sort of working against their own goals. I'm a good man They acknowledge the reason for the decision good But rather than arguing why those reasons are incorrect. They impugn our intentions, right? We're doing this on purpose because we enjoy hurting you Nobody's trying to make you look crazy. You're doing that on your own This one I liked it's a little bit long is fairly polite in its wording But it clearly comes from a place of frustration The highlighted text caps exist primarily to prevent improvements from being made without sufficiently flagellating the people who dared to be so brazen as to ask for that improvement Like I like it. I would read a book that this person wrote But you know we said earlier it seems simple, but it's really not I know it feels like caps are there to slow you down and to throw roadblocks in your way I get that but kubernetes is not a toy anymore Right look around kubecon and see all the things people are doing with it A lot of companies and people and livelihoods depend on us not screwing up And now even lives depend on it as kubernetes makes its way into really truly mission critical I'm not talking about your web store went down. I'm talking about people died Caps are how we communicate. That's how we share ideas and how we get feedback on them You know, of course, it's a process every process could be improved and and processes are there to serve people not vice versa But let's hear constructive criticism And for what it's worth we all follow the rules I have to write caps dims has to write caps and it's a living document So we continue to iterate over it as as things progress and I look around I see lots of kubernetes community people here You all have to write caps too. I know, you know, it's not like we're beating people up just because they're outside This one is one of my all-time favorites Oh, it's a little tight to read We have a cap which is the vehicle for discussing the policy design blah blah blah You forwarded me to a cap. I posted comments, but nothing happens. You forwarded me to dev null Someone else's kept PR that should cover this You all don't do anything to address the feedback drawbacks on top. You come here and close my issue I want this issue to be open as umbrella blah blah blah. If you close this issue one more time, I will report you So Believe it or not, it's okay to disagree with closing an issue and go ahead and reopen it. Please tell me why This maybe is taking things a bit too far Okay, so having endured all this and you know, thanks for being a sport and you know Listening to us. So let's do the pull out opposite If you don't like a decision ask about it. We talked about this a little bit Earlier too if you're not getting an answer again, ask about it And then lastly People go out of their way to just to say thank you I mean, we're not asking all of you to go around opening issues Saying thanks, but we'll be you know When it happens organically, it does make us feel better Uh The kind folks, you know, you run kind clusters on all your laptops So they were so happy when they saw this right like it was totally unexpected out of the blue and they were The really good people does anyone in the room use kind There you go That was almost everybody. Can can we just have a quick round of applause for the kind maintainers Antonio Get up stand up. Thank you Find him up after the talk and give him a pat on the back um, so To end on the kind note be kind please. Thank you We'll be happy to take questions or more insults if you'd like And thank you to everybody who uses kubernetes and files wonderful bugs for us because that's how We know what we did wrong