 Welcome everyone. Let's start with a quick show of hands so I know if I need to go anywhere there. Do you know what Prometheus is? Okay, do you know what Grafana is? Okay, and what Grafana labs is? Probably even fuel. Okay, so just a super quick intro. Prometheus is a monitoring system. Modern word is observability, but it's basically for it. Also, can you hear me okay? Okay, good. It's a metric-based monitoring system where you can ingest numbers about your operations, about your web shop, your Kubernetes, your clusters, your whatever. It's the standard metric monitoring system within all of cloud native. Kubernetes, you've probably heard of Kubernetes? Yes, no? Okay, yeah. Is written to expose all its data in the format which Prometheus understands and they're really, really tightly coupled. Most anyone who's using Kubernetes will also be using Prometheus because that's the natural fit from the both sides of the projects. Grafana is a visualization tool which allows you to visualize data which you have in your systems. This might be monitoring data. This might be business intelligence. This might be logging. It might be due diligence. It might be finance numbers. It might be GU information. All of this can be displayed on a web page so others can see it. Others can get an overview. And Grafana Labs is the company behind Grafana. All good? Okay. Okay, so that's the rough outset. And Grafana Labs is having an open source first strategy which you might or might not be aware of. And this is about how we think about communities and by extension how we engage with the communities and how we maintain our projects and how we keep being successful. The company is worth billions and billions of dollars so it's not unsuccessful. So let's start with a few definitions and distinctions and then work through a little bit of philosophy and then we come to the actual actual things, how we do it. So first the community, what is a community? To me, to us, it's the social unit of living things who have a certain commonality and those commonalities might be different for every different community but it is usually that they have a common cause of some sense. There are also more formalistic definitions and in the, is this large enough? You can also, if you want. You can, there's also source links with further definitions in the uploaded slides. You can find them and go through them. The scientific definition of a community is that it's based on roles and values on beliefs and on shared interactions basically driven by an intrinsic motivation. If you like, I don't know, riding a bike or painting figurines or something, that's something which you want to do. Compared to a society which is usually driven by extrinsic motivation and those groups usually have to interact with each other, it's not a free choice of those people. They have to, for example, you're born in a certain country by, naturally, you have to follow the laws and everything in that country. There's a different translation of Gesellschaft from German into English, that's cooperation, and that is fundamentally the same. It is also extrinsically motivated. It has a lot of formalized roles, a lot of inherent structure, and part of why you are at a company is literally called compensation. So you are being compensated for your loss of time, of course you are at work, of course you go travel to conferences, things like these. Ideally, companies also have healthy internal communities, but again, companies and societies are driven extrinsically, by and large, there's communities are driven intrinsically. What are communities not? They're not a sales channel, they're not a marketing target group, they usually reject outside commercial interest, and they usually establish their own rules, their own how you interact within the community over time, and that becomes more and more specific to that distinct community versus other communities. So why does Grafana Labs care? Why do you care? A large part of the success of Grafana Labs is coming from this community first strategy, this open source first strategy, and we honestly try to do the right thing, we honestly try to do a right buy and for the community, and it's not pure altruism, there's also a business angle to this, so if you need to argue this with your bosses or something, this is a, the thing is, those communities, once they're happy, they repay you by having engagement, doing their own evangelism, organic adoption. In a random hacker space, if someone says, hey, why don't you try Grafana or Loki or something versus hey, why don't you try this other project or product, makes a tangible difference in our bottom line a year later. So for Grafana Labs, communities are a strategic requirement for our continued growth, and they can be part of sales and marketing, but they are not as of themselves direct target groups, so it's much more about having an eye to eye and eye level conversation and about treating people with respect, not so much just here is some marketing material, have fun with it. So Stack Overflow runs surveys every year, and in the 2021, they asked, how do you choose your tools? And by far, the most impactful ways of how developers chose how to choose tools was they can do a free trial. They don't have to pay anything, they don't have to talk to anyone, they can just get going. Second one was asking other developers which they know. Next one, Stack Overflow, which is basically just a larger group of developers, and then come other things which are more outbound focus, but the three main drivers for adoption amongst developers for new tools is basically community mechanisms. They can try it for themselves, they have an interest, they can talk to their peers, maybe their peers are happy about this, maybe their wider peer group, their hackers face their Stack Overflow, they're whatever is happy about it, and that's what's driving adoption. And as software is eating the world, and as open source is eating software, being able to be part of this adoption chain and as developers drive more and more decision making within their companies, it's not so much the economic buyers and XX anymore, it's much more the people who actually do the work. That is something which helps us just gain adoption. And again, at some point we get more money. This is a personal story. I'm Prometheus team member, again we had Prometheus earlier. And in 2015 or 2016, it was basically me who was the deciding factor to make Grafana the default dashboard and the default visualization, the officially recommended one for Prometheus. At that time I didn't know I would ever join Grafana Labs. I mean I'm standing here with a Grafana T-shirt and everything, talking for Grafana Labs, so yes that worked out, but I didn't expect any of this. I did this course, I believed in Prometheus, I believed in Grafana and I still do. And I trusted both sides and I made this happen. Like that's one of those random small things which years and years ago has an outsized impact. And something which you cannot plan, which you cannot have a marketing plan for or go-to-market plan for. This is something which happens naturally again and again and again in the wider communities or it does not happen. And if it happens for you, more bottom line. So what makes a healthy community? Again, communities, former or the common cause, they can coexist and often work together and their causes tend to remain long-term. So even if they work together, they tend to stay distinct. If you have a community, like that's a specific example again from Grafana Labs where we have this initial community of people who cared much more about graphite and another one who cared much more about Prometheus and there was almost no overlap between those two groups. They collaborated and they helped each other in everything. But even within the company we had those two distinct groups and there's basically one or two people who moved over and everyone else didn't move over and that's completely fine but that's something to be aware of. That you can't just start your own small community or a big community and just go to a different one and grab all the people and you're done and you assimilate them or something, that's not how it works. Usually people, again, they're intrinsically motivated so they come for a specific reason and they stay for the specific reason and you can't just switch out this reason for them. So another thing which is super important, humans are herd animals. We are social animals. We are optimized and optimizing for social interaction and a really good way to judge the likelihood of positive future interactions in a group is if you're being treated with respect or not. So over the years, over the thousands of years we have evolved to be really good at seeing those things like am I being treated with respect or am I not treated with respect? And if I'm treated disrespectfully, I tend to pull back from whatever interaction or group this is. If I can't trust my environment, all my social interactions or my other interactions will be with a lot more overhead. I need to second guess, okay, if I say this, will it be perceived as a negative? Do I need to rephrase it? Can I even say this? Should I say it to someone else? All of those things just incur extra cost on you, extra overhead, and it takes away from this frictionless happy community which could be happening. And this comes back to mental and emotional security. If you feel happy, if you feel secure in a group, you're much more likely to interact with this group. You're much more likely to stay with this group, to keep interacting, to come back next year, whatever. So those are super fundamental things how human works and unless you get them right in the communities which you build and which you safeguard, those communities will break apart and you don't even really know why. Of course, people just don't engage and in other situations or other communities they do engage. So another thing we are hardwired for is fight or flight. Again, just based on evolution. When we are continuously exposed to negatives, we either tend to be very confrontational, so we need to have a fight or we just, again, we flee, we pull away. And if you don't feel secure, you won't act as gentle and as friendly as you maybe would be acting otherwise. You won't be as positive towards other people in the group. But that means that group is less positive overall and that means more people feel insecure and you have this vicious cycle of just a degrading, of a degrading community and it's really, really hard to stop this once it has started. It's much easier to never let this start than to try and stop it. Another super important thing is communities tend to just live on or maybe they just wither and die at some point. That's also fine. But they usually don't change due to external factors. Like if a group decides we want to be doing acts differently or something, yes. But you cannot force this group from the outside to change or to do stuff differently. There's the iron rule of institutions. It's a little bit small, sorry, but it's a long one. Again, it's in the source. And it's one thing which you can see again and again and again in society, in communities, in human interaction that people who are in a position of power within a group would much rather see this group dwindle in overall importance and power than their own standing within this group to be diminished. Which tells you something about how to choose the leaders and that the best leaders are the ones who are happy to step away and not be the ones who are glued to their chair and never leave. So we are good at detecting things which are not right, which don't feel right. Children are really good at externalizing this. Adults learn not to do this because social pressure, social interactions, everything. But yet communities do rely on open and honest and reliable communication. And you can only safeguard those communities from within. How can you verify this? Well, one really important thing both for yourself as you are within a community, also as you lead a community, as you try to build a community, is to find your own culture canneries. To find things which you think those are good, those are bad. To find things where you say, this is something which I like about this community as of today versus this is something which has made me leave this and that other community. And to write those down. And to regularly check, did this change? Did it improve? Did it get worse? This one thing which I really liked is it's still as nice as it was two years ago. And this allows you A for your own to pull back if it's a really bad community, but if you maintain and nourish this community and you see things which you wrote down as those are good things which are happening just automatically and naturally and they stop happening. Those are things where you know that you need to be a little bit more direct, a little bit more shaping and not just shepherding in the community if things actually go wrong. And one thing which is really hard about this, you can't tell others about your culture canneries. Like I can give you generic examples, I can tell you write down a certain, like if you have a certain space or a certain forum where a certain type of communication happens regularly and this is a good sign of a healthy community, that's something which you can write down. But I can't give you my specific ones because as soon as you externalize them, it's possible to gain those specific things and that means they lose the value as an actual cannery to protect yourself and others. So formalizing communities. Most communities do have roles but they're oftentimes informalized, at least at the beginning. Which is great because it allows this chaos and this initial growth period, it can put strain on long-term growth. So as things grow, they tend to rely more and more on formalized roles and structures and everything. So if I have those structures anyway and if I need those structures over time anyway, it's much better to make them visible and to externalize them to say, okay, this is a group of maintainers and those maintainers have more say in technical decision-making than a random user. That's something which is obvious to a lot of people who are familiar with how open source communities works. It's not obvious to a lot of other people who just join new. And it makes it easier for those people to join your community or to figure out how your community structures, what formalized roles do exist. If you're being very upfront and honest about those are the structures which exist. So it's not a game of everyone needs to find out and maybe be uncertain about this and that one. I want to make this change. How can I get this one technical change made? It's a lot easier if I know who to talk to, who are the decision-makers who can drive towards making a decision, driving this change. And some structures are as much a tool in and as of themselves as there are a signal to people who are considering if they want to join your community or not. The prime example is the code of conduct. The best code of conduct are the ones which you actually don't need to use. You write them down and you, I mean, they need to be good ones and you can copy them. In the meantime, there is a wide library of available ones and they're good ones. The thing is, as long as the community is running as it should, most of the time you don't need to ever invoke the code of conduct anyway. Of course, people tend to want to treat each other with respect and nicely. Of course, that's how they want to be treated. So that's the signaling part of hey, we actually follow this and we want to do this, but also we wouldn't be having this if we were having, like if we had to invoke our code of conduct 10 times per day, it wouldn't scale so we wouldn't be having one. So just by having one, which is lived, you show that this community is healthy and secure enough. But the thing about the, if you need to enforce it or not, again, it's best to not enforce or not have to enforce it, but if you need to enforce it, it needs to be done quickly, it needs to be done visibly, there needs to be a tangible result. I don't mean to say that you have to open every last detail of every last complaint, far from it, but have an overview of how many complaints that you deal with. If someone makes a complaint, don't give them this, oh yeah, we'll handle it, but also tell them, okay, we'll handle it and we'll give you an update every X amount of time if we already made a decision. It might not always be appropriate to tell the reporter what the decision is, that depends on specifics, but at least they get the update, they get the okay, this is now solved from our perspective, and if they're really unhappy and they see that maybe this wasn't dealt with in the way they wanted, they have a way to figure out that this is not how they like it, they can try again, they can talk to you again, something, but this needs to be honest and transparent and reproducible because this is like the guardrails of your community, the absolute guardrails, you must assert that people feel secure and respected in your community as we just saw. There's also limits, communities exist within the society. Open source communities exist within the companies or the legal umbrella in which they are created in which they are legally attached to. There are limits to what communities can do. If someone at Grafana Labs wanted to completely change Grafana, the company wouldn't allow it. If someone wanted to do a fundamental change to get rid of the code of conduct in the Linux Foundation project, Linux Foundation wouldn't let them, even though the community within Linux Foundation might have made the decision. So you always exist within this context and there are limits to what communities can actually do. So how to apply all of this? From Grafana Labs perspective, most of our products are based on projects and there is a clear one-to-one mapping of this is the project, the open source project, which we are running and which most of the people are using, 95, 98% of people are using the open source project and only a tiny fraction are using the product where they actually have to pay us. But there is this clear mapping. So anyone who wants to go one way or the other knows clearly how to do this. By and large, communities don't care about the products. So we don't talk to the open source community about, hey, this and that similar feature is now in Grafana Enterprise and Grafana Cloud. Of course, they don't care. They care about what they can access what is in the open source part in the project. They don't really care about the product. Open Governments is super important because this gives you again a blueprint of how decisions are made and also how you yourself over time, if you really want to, have a chance at becoming part of whatever decision-making body or whatever you're wanting to join. With Grafana Labs, all of the Governances we have are basically the same, like details like the names of projects or people and such, but the fundamentals are the same. It's all modeled on the Promises Governance, of course, super successful project there as well. Communication by default happens on mailing this on GitHub. Yes, you always have this internal talk if you're in a company and it's sometimes hard to push stuff out of Slack and onto GitHub, but by and large, we are doing a good job of this. And this is also good because this means external people can communicate, can participate, they can give their ideas, they can maybe improve a PR, whatever, it's really important to have the majority of the communication on public channels. Membership is open to anyone, so it's not the case if you have to work with Grafana Labs or you have to work at a friendly company or something to join. This is deliberately not the case. And even full maintainer rights and everything is open to everyone. It's purely based on their own personal contributions. It's not tied to, hey, you work for company X and we have a partnership with company X and that's why you get this one seed? No. If you put in the work, you personally get that place of honor within that community. Oftentimes, it's a case of companies sponsoring your time to do this kind of thing, yes, but still it's you doing the actual work and that's what is recognized and what we really care about. Every project we have has at least one community lead which is usually also the tech lead. Of course, A, those type of people tend to be good at this kind of thing and just juggling all the interdependency of a project. But also they really deeply care about the projects. So it's a good fit. But the thing is there's a certain persona of people who like doing community style work and the vast majority of people are not those. Like they might like doing it on and off or something but not like long term. It's always the same people who show up. I've been in open source for over 20 years. It's because I'm precisely this type of persona. I like doing this kind of thing intrinsically motivated. That's why I keep returning to it, blah, blah, blah. That's why you want to identify those people and put them in the role of, hey, please shepherd this community. They will come to you and they will ask you questions. They will ask for support. They will ask for, I have this and that issue. Can you help me with this? Yes, absolutely. But from the perspective of the community, they are the face of that specific community and also they gain more confidence, more experience over time and over the years. So they can do this more and more on their own. Another thing which was in particular important the last two and a half years with COVID were our community calls. Every single project has or above a certain threshold of size has a community call. That is a monthly call, usually on Google Meet. One of them is on Zoom. Everyone can join. Everyone can bring their own topics, not only people maintaining the project or anything, anyone. The meeting notes and the agenda for the next meetings is world readable for every single one. So you can literally just write what interests you into the next agenda and just talk about this. So this is completely opened by design. And then we put the recordings on YouTube. In particular during the pandemic, it was, or why? But in the beginning it was super important because people didn't have any like meetups and everything was just cut off. You couldn't do those anymore. People still wanted to have social interaction so some of them even became a little bit of a friendship group from people who just were stuck at home. And it was a super important mechanism to get the word out and to have an interaction channel for people. But at the same time, you have to run those for a few months before the first person who regularly showed up is even comfortable speaking. Because yes, you tell them 10 times, yes, please speak up, but they're not really comfortable usually. And it takes some time to build confidence, to build this emotional security, to be confident enough to say, okay, I'm going to ask my question, which for a more seasoned open source person is like no big deal, join a call, talk, whatever. For people who are joining, that's one of the largest blockers which they have that they can't really make themselves be as bold to ask this and that question. So it takes time and it takes time and that's why we put it on YouTube so people can see, okay, those are nice people talking nicely to each other. They're having fun doing this kind of thing. Yeah, speaking of fun, the thing which I always tell our community leads is the vibe you're going for is you have a good beverage and you sit down with friends and you nerd out over that one topic. And that's the vibe those community calls are going for. We have a meetup series, Grafana and Friends. Any city where we have one or two people, usually engineers who are dedicated and who want to do this type of thing, again, it's always the same people. We support them with like paying for the meetup group, helping them find a venue, help find a few slides which they can talk about, help kickstart this thing so a group of friends can build up overtime in the local city. Public speaking, we aggressively invest in our engineers speaking at conferences about all the variety of things which they're working on. I mean, this is also me basically following this, this same basic recipe, but it's like really hard problems which have been solved within a project are usually invisible to most people unless you're really deep in the thing. So talking about how you can use your project for something is already super valuable. Of course, it gives people an incentive to try your thing. But also talking about how you solved a specific problem, a really hard problem, helps with your hiring. Of course, you showcase to the world that you're actually solving interesting problems. It also raises the profile of the person speaking about it and then when they look for the next job at some point in the future, it's also easier for them to build their own profile. And over time, again, it's always the same people. They start enjoying it, they start doing it more and they start speaking more and more and by extension, this gives your project, your company more exposure. I mean, we had this initially when I did the show of hands who knows what Grafana is. Large fraction of people didn't know. So now at least you have a little bit of an idea that this thing exists and that's why we invest so much in public speaking. Blockposts, we have a blog where every single day we have at least one new article and the majority of the technical blockposts are written by actual engineers, which takes much more time to actually teach and coach engineers on how to write blockposts, do reviews, help them over time, blah, blah, blah, blah. But the resulting blockposts are much more in depth, much more technical, much more truthful to be blunt than if marketing would be writing them and that again builds an audience and builds trust over time. And webinar is how we teach people how to do stuff. Something on resources. Engineers are expensive. They tend to be, I mean, sales gets compensated even higher usually, but engineers tend to be amongst the most highly compensated group at software companies. And it's really, really expensive to invest an engineer's time into public speaking or into writing a blockpost or into doing a community call like those things don't come for free. This is something which the company actually actively needs to make a decision. Do they want to do this or do they not want to do this? For Grafana it's relatively easy because the CEO and founder gets it and he wants this to happen. Of course he understands it and senior leadership and executives get it by and large and they want this to happen. Still it is something which comes out of the budget of someone else. Of course it's the engineers who should be writing code and all of a sudden they spend an hour on this community call and they spend an hour before preparing for this community call and half an hour after maybe talking about it and it's not only one engineer, usually three or maybe five join and when you launch a new product every last one joins so it's eight or 10 people. And this sums up like easily you've spent a whole work day of engineers just to kick start this one thing, this one community call which initially has basically zero external people even joining. But again, this is a deliberate investment and I strongly believe that this is an investment which is making sense. If you have struggles internally arguing this, A, my contact data is on the last slide and B, you can tell your finance people and your bean counters to look at Grafana Labs and how successful the company is and that is part of our core strategy. Travel is also expensive so you need to have a budget for actually flying engineers and speakers to things like I came here from Munich, Germany so this is not a short trip. Yet, if you foster this culture at your company about being able to speak at conferences, being able to travel to conferences, A is great for your hiring. Of course, the people who want to travel don't always get this chance so you have more of a selection criteria for all the really high impact, high velocity engineers but B, you also get, again, more public exposure but it is expensive and you need to argue this internally and if you only have non-engineering resources like if you only have a few marketing people who keep writing stuff for your blog or your copy edits or your announcements, people will figure this out. Of course, usually the marketing people get details wrong which an engineering type person wouldn't be getting wrong but by extension, your target audience, the engineers or the finance people like whatever your specific target audience is, they understand those nuances and they will pick up on those small mistakes, on those small emissions, on those small untruths and over time, you will lose authenticity. You will lose face in the views of your target audience and they'll just not want to engage with you anymore. So yeah, I know it's a hard thing to argue internally but one of the reasons why Grafana Labs is so successful is because we invest the time of engineers aggressively into all those public-facing roles, into all those community-facing roles and help the engineers themselves actually drive and thrive those communities over time because they care about the stuff. They are already known. They are the people the others look up to and they are the people who need to be your primary interface for the project and for the community. I should have changed that title. So yeah, to summarize, keep normal marketing and sales mechanisms away from your community. This will kill your community efforts completely because they'll see it for what it is and they'll just pull back and you will mess up. I mess up as well. Grafana Labs messed up a few times. When you mess up, don't hide it because people realize when you hide it. Be open and honest and transparent about it and talk about what you did and what you're doing to change it, blah, blah, blah, blah, but don't hide it. Be honest and be transparent about it because this goes back to this emotional security. If you're being dishonest, if you're being untrue for people, we'll figure it out and over time they will pull away. So we have five minutes for questions. Yes. Do we have a microphone for the online audience or should I repeat the question? Can you give us an example of how you mess up with the normal marketing and sales way with the community? So I didn't mess up with that. Okay, I didn't want to tie them directly like there's also other ways to mess up but one specific example is the Twitter and Facebook and LinkedIn and master don accounts of Grafana Labs are mainly handled by marketing. For example, I myself have access to the Twitter account but the main content is being driven by marketing and every now and then we have this one tweet where you're like, oh, this is so embarrassing. You don't speak like this to engineers and immediately my messengers pop up and five friends tell me this looks so embarrassing. Why is this happening? This is not the voice of Grafana. I'm like, yeah, you're right. Initially it was a little bit more for discussion with marketing but in the end it literally turned into if I don't have the time to read the copies or everything but if I find something which is just weird and which shouldn't be put out, we have a direct feedback loop into marketing and they delete it and also internally we talk about okay, this is why this is bad content, this is why it doesn't resonate with our people or our target audience. That's one, yeah. I mean, that's not a huge one where we actually mess up but when you come to the security releases, one time we had a larger gap in our release process and we didn't hide it. No, on the contrary, like we make a detailed timeline of whenever we have a security release we make a detailed timeline public about what we did when and we just pointed out directly that this was a long gap, it shouldn't have happened but it happened, we are human, we are trying to do better next time and this builds trust. Oh, maybe that's a good, yeah, just as a final, for the security stuff we had several people contact us over the years where they told us okay, I'm normally sell these for money on like dark web sites like these exploits, those, but I'm telling you, of course you're good people. Like they literally didn't sell the stuff which they found, that's how they make their living. You can argue about if it's a good thing but like whatever, they gave it to us for free, of course they like us. So how do you balance your commercial interests like your product interest and features and prioritization with interests of the community? Do you have like a model for that and also in regards to like transparency and trust and so on? We, yes, we do. So one of the relative unique features about Grafana but one which I would strongly argue is successful if you were to replicate this is we only monetize a fraction of our user base and that is a deliberate choice which sales doesn't always love but you can tell for example one story which we had is we tried to sell to a large bank and they got the CTO of that bank onto the call like the people preparing this internally and he was like, yeah, you don't need to present this. I know what Grafana is, I use this for my garage because I monitor the humidity and temperature and such for my cars in my garage. I don't need, like we can buy this done and that's a thing which you need to keep read which you must tell sales again and again and again but they also benefit directly from the strategy. So A, we monetize only a tiny fraction of our user base. That directly means that the majority of our features goes into the open source. We work upstream, we invest in open telemetry and premises and all those things which are not owned or controlled by Grafana Labs on purpose. Our sniff test and that's not a hard and fast rule but our sniff test is roughly does the intended user have more money than time or more time than money? SAML would be like different row based access control systems and automation behind it. LDAP imports, things like these are part of the commercial offerings because those tend to be what companies need and require. We can build it in open source if you want to but we won't help you because that's part of how we monetize. Time for one more question. I have one question about like a code of contact. So we have a code of contact in the community. I think that most of the people follow the code of contact. But like some communities that's for example not they don't create the code of contact but then operates for years but sometimes the problem happens. And in that case it's very difficult to enforce because we don't have a code of contact so if someone do not good thing but we don't let him go or let her go because we don't have rules. So how do you act such kind because it's easily happened for the RE stage project because we are not like a time to create the code of contact. How do you, do you have any suggestion for like past cases? There's a German saying, weret den anfangen, roughly translated as beware of the beginnings or prevent the beginnings. It's always easier to prevent than to fix it afterwards. I've been part of several communities where we had to introduce code of conduct afterwards. Of course those communities like 20 years ago or sometimes even created 30 years ago it just wasn't a thing which existed. And it was hard. Of course you did have people sometimes even relatively central to the effort to the community who just disagreed. Who didn't want to have a code of conduct at all or wanted to have a different one. In the end, there is no recipe here. It's about talking to the people who actually drive consensus and who drive opinion within that community, getting them together and finding this consensus and basing on top of it and then building slowly. At the same time, it's not always successful. And in particular if this is already an ongoing incident, like you have an ongoing incident and then someone comes with, hey, I have this idea about the code of conduct. Quite obviously everyone knows in what context you came up with this idea. And they will strongly resist this because they know it will be enforced against them or their friends. Time and effort and trust. And if it doesn't work, leave. Like I also left communities because I didn't agree with what they did.