 Welcome everyone. So as this is a birds of a feather session, feel free to open up your camera, open up your microphone if you want to chime in. It's really an informal session. So I'm here only to facilitate, make sure that we're all adhering to the code of conduct. But this is a session for you as much as for everyone. So feel free to take part. I prepared a few things to kick off the conversation. But if you have ever been to a birds of a feather, really it's free for all. Because we are at the official starting time, I'm just going to let you know what I prepared. I have a couple of slides about the challenges that we are facing with metrics about open source projects, open source communities. I have a few things about how the chaos project is addressing these challenges and what we can learn from the chaos project. And then I have a section for open conversations and to talk about lessons learned. The lessons that we learned through the chaos project that I learned through my PhD, researching open source community health, but also your experiences. So this is why we are in an open Zoom call where we can all chime in and talk and share what we have to share. A little background to me for those who might not know me yet, I'm Georg Link. I'm originally from Germany. So it was very great, very good to see that we have some from Germany dialing in today. And I work at Biturgia, a company that provides metrics analytics about open source projects about software development projects. And I came to Biturgia because I was very involved in the chaos project. And chaos is short for community health analytics, open source software where we want to understand the health of open source communities and built a network of people who are interested in this topic and how to be used metrics to understand community health. So metrics around open source communities and the health of projects is something that I've been working with for quite a while. So thank you for joining the session today. When we talk about metrics, it is on the one hand, we're talking about the method of measuring something. And on the other hand, we're talking about the outcome, the results that we get. And so when we look at open source communities, they have project data. A lot of this data is automatically generated just because we are working in the open, we're developing in the open. All of those interactions produce footsteps or trace data that we can analyze, the Git log, the mailing list archive, the chat history on IRC. So those are the trace data, which we need some way of getting insights from. And that's where the method comes in. We can also produce our own data. If you wanted more qualitative data, we can run surveys or interviews or sometimes we don't have the data that we want. And so we have to figure out how to get it. But then we have the methods. So once we have the data, we have the method to get the insights. And in my analogy here, we're going from a cloudy day to a sunny day where the clouds clear up and we can see. So that's when I think of metrics, really what we're talking about, what I'm talking about. And I'm gonna pause throughout this session because it's a personal feather session, you're all welcome to chime in. If you want to open your microphone and add something, feel free to do so at any time. You can also raise your hand or write in the chat if you want to add something. I'll have an eye on that and make time for you. So if you wanna understand how our open source communities are doing, how the project is developing, evolving, there's several challenges that we all are facing. And those challenges, I grouped them in legal and ethical challenges, organizational challenges and technology challenges. When we talk about the legal and ethical challenges, this is where we think about laws like the European General Data Protection Regulation GDPR where the European Union has given all EU citizens autonomy over their data, which the question often is in open source. If someone participates in open source project and they're giving away their data and they know it will be publicly visible, are there any concerns with analyzing that data and would you become a data controller by the GDPR law? Which says that if you analyze the data, then you need to let the data subjects are open source community members who are whose names or email address or contributions we're analyzing. You have to let them know they need to be able to opt out. We also have data privacy issues or questions. Is it fair to expose someone? How do we do this? Are we letting everyone know that they can opt into the analysis or do we go the opposite way? And we say, hey, analyzing the open source community and project is good for the community. We do this and it's expected by the members that this is something we would be doing, but we still give away for someone to opt out. So those are legal ethical challenges. And I'm gonna pause here for a second to see if anyone wants to chime in. Again, this is a Birds of Feather session. Thank you for everyone who is here. If you joined late, also welcome. As a Birds of Feather session, we are all welcome to talk and have a dialogue. That's why we are in Zoom today, not in the main conference platform. So in the chaos project where we develop metrics for you to choose from, if you want to analyze open source projects, we recognize that these legal ethical challenges, we can give some opinions on them, but we cannot solve it specifically for you because it depends on what data you're analyzing, it depends on who's in the community, what, where you're located. So there are different laws that we need to pay attention to. Moving on to organizational challenges. When you start analyzing open source projects and you find a good tool that does that, which I have some recommendations later, then it's often like opening a fire hose, a fire hose of data. And unless you have a specific question you're trying to answer or strategy for how to analyze the data and derive meaning from it, you'll be overwhelmed. And so the challenge is what is our strategy? What do we actually want to do with the open source project, with the community? And how can we use the metrics to make meaningful decisions, to check whether we are on track and get actionable insights. If we start having data and metrics about open source communities, our communities are often very opinionated themselves and they want to be in charge or they want to be asked before we do something. So giving information to the community before creating a dashboard, a community dashboard or something is a generally good idea. We also have technological challenges. And again, feel free to jump in at any time if you want to add something, if you have an idea and you have an example that you want to bring in, please do just, you can, let me know that you want to speak or you can just unmute yourself and let me know as well. So technological challenges. One is we have to actually get the data. The data in open source project is as diverse as the different tools that we use. We have mailing lists, we have a repository on GitHub or GitLab or we hosted ourselves. We have an issue tracker, a forum, a wiki, an instant messaging service. Open source communities are all very diverse, no two communities look alike. And even if we say we all use a mailing list, which there are many communities that don't do that anymore, but even if we say we have a mailing list, there are different versions, different providers. And so getting the quality data is something that we all need to get through because we need to collect the data that we're interested in. And we have some solutions for that in the KS project. Again, I'll talk about the tools here in a little bit. Another challenge is managing identities. So one reason we might be interested in having data about our communities is because we want to give active contributors a vote at the upcoming board elections or it's something that I've seen. And being able to say, hey, this person, XYZ is the same person as YZX is really helpful just because they use work email and personal email or because they have a different username on GitHub than they have on Twitter. Being able to say, hey, this is actually the same person is really valuable because then you can see the whole picture of what they're contributing to our open source community. And then it's not just about collecting quality data, always keeping up with API changes and managing the quality of the data we have but our contributors, the identities merging. But we also need to have a way of reporting on that data and visualizing that, having dashboards, running regular reports. So maybe we have people that we need to report to, maybe we have managers that care about, hey, how is our community doing? So being able to take the raw data and make it into something meaningful. Now there are some super experts that just look at open source communities and they can tell you, hey, it's going really well. Here are the things that you can improve. But for the most part, if you're normal like me then it's really hard to do that. And this is where together we can be better, stronger, faster. And this is the second part where I have some things to share about the chaos community. And again, if this is a birds of feather, I saw new people join in. You're welcome to speak up. If you have something to share, this is a very, very open format. I just have some slides to share some thoughts that I've had and unlike being in a room where I can stare at you and ask you, hey, do you have something to add? I'm really inviting you to speak up. There's a session for all of us. So if you have any questions or thoughts or examples, let me know. So together, better, stronger, faster. This is what we're doing with the chaos community. And so going through these, let's say together is the chaos community. We've started about three years ago at the Linux Foundation. There's a metrics community that is older, but we've started at the Linux Foundation three years ago. With the goal of bringing together industry, academics, I was earning my PhD at the time. Toolmakers like Biturgia, where I work now. The practitioners, open source foundations, community members, like yourself. And we want to understand, okay, what is community health and how do we understand that through metrics, building out tools that we can use. So that's what we set out to do. And now we're becoming better. We are developing chaos practices. We're talking about how to be actually analyze communities. How do we use the metrics to scale up the work we do? How do we reduce bias in our decision-making? How do we manage our communities, our engagement with these communities through the data that we are collecting? How do we support decision-making? These are all things that we are talking about in the chaos community. And having this community of practice is really helpful. And we produce blog posts, we produce all kinds of things to share this. One thing that we are producing or creating in the chaos community are metrics. And this is where we become stronger because we are starting to have a unified language about how we are measuring our open source communities and projects. We are becoming stronger because we can use the metrics that others have already vetted and said, hey, this is how you collect the data. This is how you analyze it. Here are some thoughts on what this means. In chaos, if you go to chaos.community slash metrics, we have a list of almost 50 metrics now. And every year we keep adding more. And the way we have organized the work in the chaos communities and working groups, because different people care about different things and measuring different things, we have working groups, one is on diversity and inclusion. One working group is on risk. One working group is on evolution. You see the trend here, value and common are other working groups. And each one of them is defining metrics that they care about. So code changes here, the example I have on the screen is in the evolution working group. And code changes is our work for commit. We just chose a more neutral term, code changes. So there's a buffet of metrics that you can choose from. If you want, we can do a deep dive into the metrics. I'm just listing this here as an option of thing, something we can talk about. We also have going to faster, so together better, stronger, faster. If you want to start analyzing an open source community or project, we have some software that you can start using. And the software already solves many of the technical challenges we talked about. We collect data from many different data sources. We can present that data. We can manage identities. The Grimoire Lab project, which you see here at the top right, is being used by big Fortune 500 companies to understand their open source engagements and projects. Augur is something, is a tool that is developed by the University of Missouri as a playground where we try out new metrics and some of you on this call might have already played with this as well and found it to be useful to run queries against the data. So Grimoire Lab and Augur are the two big tools that we have in chaos that you can just start collecting data with, but they're very different philosophies. So something we can also talk about if you're interested. The G with the looking glass, that's short for, oh, that's the tool Kregat, and it's used for the kernel report and to understand basically like Git blame, who made changes to the source code, but not at the line level. With Git blame, you only see who edited the line. With Kregat, you actually can see who added this variable or who last edited this function name, which might be helpful to know who you can ask about it. So in the chaos community, we can together get better, stronger, faster in having metrics and analytics and understanding open source communities. Now is the part where I would really like to hear from you all about what have you done with metrics so far? What have you learned? I have a few more slides to spark ideas or thoughts, but if you have something you want to share with others or if you have questions, hey, this is an open format. Maybe there's someone on the call who has some ideas for you. Maybe this is one speaking. One thing I was wondering when I hear about community health is here a common understanding, at least within chaos, what the healthy project at least is. I mean, some projects maybe might be healthy if they change all the time. Some projects might be healthy if they don't change at all. So take this metric, for example. And that is something we are talking about in the community as well, that some projects are growing, some are, it's very stable and some are even declining, as you said, very stable. The definition that I like the most is to say a community has the potential to continue developing quality software because you're putting the focus on quality software, the output, but you're also putting focus on the community that it can establish that. And that's the definition that I like the most, that I'm using in my own work. Does that resonate with you, Swin? In a way, I mean, this is really pretty resultful. So, I mean, when looking at your work, you could also think about other parameters like what the people who are involved, it's maybe also interesting aspect, but I like the aspect that it's just for the result. I mean, this again comes with the question, what is actually quality software? It might have also some different layers and dimensions, but... Absolutely. And I don't have to be the only one who is answering here. So, if anyone wants to chime in and reply to Sven's question, how do you define community health? And some communities are not producing software. I know there are many open source communities that are not producing software. So, the output might be something different and or you really just have a community that is getting together. And so, the focus of your definition should be on other people getting out of the community what they want to get out of it. And is it a good experience to be part of the community? So, Bryce asked the question in the chat, how is improper data identified and managed? And Bryce, could you clarify for us, what do you mean by improper data? And do you maybe have an example in mind? No, I don't. Maybe Bryce, if you could add that in the chat or speak up, you're muted right now. Okay, so Bryce said, I apologize. I have to say I'm rather ignorant, but I imagine someone with not the best of intentions might have access and alter. So, the thoughts that come to mind listening to or reading your question is when we have open source communities, the data is often public to begin with. And there are some shady characters who do analyze the data and extract it from. One example is get everyone's email address and start direct marketing to the developers in the project. And that is something that is improper. It's unethical, but I don't know if you're talking about that kind of analysis or that kind of data use. So, if you have something else to add, please add it to the chat. I'm, oh, no worries, Bryce. I appreciate that you asked the question. I'm just trying to figure out how best to answer that. And maybe I'm just not quite understanding either. One thing that we talk about in the Chaos community is that we have different reasons for having metrics and different points in time when we want to understand what is happening in our communities and our projects. So, here on the left, you see a dashboard. When you're driving a car, you just wanna see it, how fast am I going? And do I need to apply the brake or the gas to get up or down to the speed limit? Do I need to fill up the tank again? How am I doing on gas? So, there are some things you need on a day-to-day operation spaces as you're working in open-source communities or projects that you just, the quick glance, easy to understand metric. But sometimes your car breaks down. You have smoke coming out, everything stalls, you pull over, or you just have a regular maintenance check once per year and you go to a mechanic who has the vehicle inspection report that he fills up and there are many different metrics. How are the brakes doing? How is the shocks? How are the tires? And so taking a deeper look at the car. And we can do the same thing for our open-source projects and communities where we can look at the data on a day-to-day or week-to-week basis, how are we doing? Are we growing? Is there anything that we should be paying attention to? But then occasionally we do some stepping back and think about, hey, what's our overall strategy? Are we engaging the people that we want to engage? Is there any bottlenecks that we should be focusing on? And that's when reports come in. So again, I'm opening this up. Do you have any experience with dashboard metrics or report metrics? I don't wanna call on anyone specific. I'm just opening up the floor if you have something you would like to add here. So another thing that we hear or I hear a lot in the chaos community is that people would like a baseline. Being able to say, hey, we're doing better than last year. And for that, we actually need to know how did we do last year? So we need to start collecting data early and have it ready for when we do want to use it. So part of it is to listen. And when you start the metric journey, just start collecting everything that you can. You don't know what you will use in the end, but at least you have it. Now, this is to start. You cannot always look at all the data. That's where strategy comes in, which I'll talk about next. But you want to have that baseline. Or sometimes you're not using your own history as the baseline. Sometimes you want to compare yourself to other projects. Like here in the screenshot, I compared the two chaos projects, Augur and Grimoire Lab. And I was very surprised to see that they evolve about the same, even though they have completely different development teams and there's very little overlap in the contributors. And what I think, well, I don't actually know what is happening, but I know that during Google Summer of Code, there's a lot more outside contributions or from outside the community. So I think that those are the spikes or some of the spikes. If you want to start getting visualizations like this, I can recommend, check out coldrin.io. It's a service that builds on top of the chaos Grimoire Lab technology, but you can just go to coldrin.io, put in the repositories, GitHub repositories or GitHub repositories that you want to analyze and you get information and you can compare projects, you can get metrics on multiple repositories, combine them into one project. A really useful tool. So collect everything, start listening to your community, have the metrics ready for when you do want to use the analysis. And also some metrics you can go back in history like the Git log, you have the full history that you can analyze. Other metrics, if you're interested in how your number of stars on GitHub evolves, there you have a two week time window to collect the data through the GitHub API. And so you cannot get the history of that beyond or further back through the API. So you want to start collecting that to build up your graph, your history. Again, I'm opening this up. Is there any thoughts, comments, concerns, questions? So in addition to collecting all the data, we actually need to know what we're looking for. We need to know what the needle is we're looking for in the Haystack. And in the KS project, we are proposing or advocating for using the goal question metric approach. So you start with your goals. What do you actually want to do? Let's say we want to grow contributors. Then we have some questions for how we're doing. How many new contributors did we have last month? How many active contributors do we have right now? And once we have those questions, we can figure out what data can answer those questions. So if you want to grow the contributors, our goal, you want to know how many question, how many new contributors we have, that's the question. Then we can use a metric of number of new contributors for that last month. Or for how many active contributors do we have, we can have a metric, number of active contributors. So going through the goal question metric approach gives us not just what metrics should be focused on, but also a rationale for why we look at it. And we can start to tell the story. Hey, number of new contributors is this and we are growing our contributors. Here's how we are creating value. Here's how we are having an impact. We need to start telling these stories that are larger than the individual numbers, the individual metrics. Any thoughts on metric strategy? Another thing that is interesting to look at is collaboration patterns. And here this network diagram shows our chaos community. The blue bars are repositories. If I were to zoom in in the dashboard, which you can find on chaos.biturge.io, you could actually read the label names, the repository names. And then the dots are individual contributors. The larger dots means contributors who have more commits, small dots have fewer commits. And then we draw lines between the people, the dots and the blue bars, the repositories, if a person made a commit to a specific repository. And so we can see here in the middle, we have one repository that has a lot of people who do contribute to it. And that is our governance repository. On the right, we have a cluster of a few very active contributors with a lot of repositories around them. And then outside of contributors. And that's that cluster on the right, that is our Grimoire Lab project. And the people in the middle are the Biturge employees, the company that is the main steward and maintainer of the project. So you can see, I can start to tell a story with this visualization, with this way the data is presented. And then Augur is the repository at the bottom. There's Augur being at the university, they often ask students in classes to make contributions as part of their learning experience. So we sometimes see spikes of activity because students have their assignments to. So collaboration patterns is for one, what is the map of our community? Where do people contribute to? How active are they in different parts? Collaboration patterns is also when are we contributing? Is it during work hours? Is it during weekends? Gives us an idea for what kind of community are we looking at? Is it professionals who work as part of their job on this project? Or is it volunteers working outside their regular work hours? Or what time zones are contributing? Where are the people located? Are we all in the European time zones? Are we all in Dublin? Or are we spread out? Some from India, some from North America, some from Asia. Time zone is a good or a somewhat acceptable proxy to geographic location, although we don't get the whole North versus South difference. But we get an idea for how globally distributed is our community. And I'm pausing again to see if anyone wants to chime in. Ah, Christopher messaged in the chat. Hi, Georg. I'm completely new to this field and in fact misunderstood the meaning of the title of the session. I took the term health literally as I'm interested in the social application of open source. But maybe that doesn't matter too much. Talking of stories, there is a task demystifying metrics and data to the lay people. So there are two things that you said here and thank you very much for making that comment. Health, we're not talking about medical health or the health of people here. We're talking about the community health. So how well are, how well is the community doing? And when I heard health the first time, I also only had the medical health in mind. Maybe that's because I was from Germany originally and so English was my second language. And I've not heard health being used for the health of a system, the health of a machine or health of a car or whatever. So yeah, there are different uses. And open source is being used quite a bit for, so I'm totally going off on attention. And Christopher, if you want to open up your microphone and say something, please do so. You can also stop me. There, open source. Go ahead, I see you unmuted yourself. No, no, go ahead, Georg. I just wanted to be polite. Carry on, finish your point please. Oh, I was just going to say that there are many open source projects in the medical health field. Libera Health, GNU Health are just two projects that come to mind. So yeah, that was the only thing I wanted to say here. Okay. But I, yeah, I mean, as I said, this is a first time experience for me, but I'm fascinated by what seems to be a really different mentality that perhaps is just part of open source thinking. But as a newcomer, I'm just stunned really by its, I don't know, it's potential and how different it is from the way, standard ways of thinking that the rest of us exist in. And yet, it does have applications at whatever level you're working on. And it seems so important for evolution as a planet. But yeah, so I'm grateful to all of you, but I'm also interested in how you set about, I mean, other than having an open door, how you set about sort of, yeah, telling the narrative of what you're offering to people that don't speak to you, but I'm also interested in how you set about, offering to people that don't speak your language or stop waffling. Well, thank you. And before I take the air out of the room, I'm gonna pause and see if anyone else has some thoughts and wants to reply. So as a facilitator, I need to be very comfortable with silence. But yeah, so no, it's a really great reminder that the way open source works and this collaborative first approach that we have developed in the open source projects and communities is something quite to cherish with a lot of potential. So yeah, the thing that this Birds of Feather is about is how do we understand this collaboration, this way of working together through metrics and how do we help to enhance it, take it to the next level and identify where the collaboration breaks down. Where we're losing out on the opportunities that we would have. One thing that you said, sorry, I didn't mean to interrupt you. No, no, no, go ahead. One thing that you said was, we need to tell the story of what we're doing to others who are not familiar with our work. And this is true for talking about how we, as a community, are doing about the health and the metrics. But it's also true about the work that we're doing on the software or whatever we are producing as a community and talking with the users. And this is where marketing, we can learn a lot from marketing because marketing as a profession is concerned with how do you take what you have and talk about it and involve others who are not familiar with it before who use different language, identifying what words they use. So those are things that come to mind from listening to what you said. Yeah, that's interesting. It puts marketing, which can seem quite aggressive into a different light. It's nice to think of it as a way of breaking the ice, which we probably all want to do. Yeah, as you said, marketing, we often associate with the spam that we get and the letters in the mailbox and the billboards, but that's just one form of communication. When I studied marketing, which I didn't study, study marketing. It's marketing, marketing, marketing, marketing, marketing, which I didn't study, study marketing. Marketing was part of my education. The emphasis was really about communicating. Marketing is the department in a company that works on the messaging, the communication. Yeah. So one, so moving forward, I'm happy to talk more about this, but I can also go on. I have one quick thing to add. Yeah, Don. Getting back to the comment earlier about storytelling, I think the interpretation of metrics is really important. I'm part of the chaos project. I'm a big fan of data and metrics, but it really only tells part of the story. What looks good for one project isn't necessarily good for another. And I think that there's a lot, a lot that's left for interpretation. And I think that interpretation and being able to explain the data, I think it's really important. It's an important part of thinking about project health. Yeah. Thank you, Don. Another thing to consider is avoid gaming of metrics. So if you're having metrics focused on. People and they can do certain actions to raise on a leaderboard, which maybe you recognize the image that I have here on the left. It's from our current conference. Then you get that behavior. You get what you measure. And. With the, we saw this recently or just this month with October fest, where the measurement was. Pull requests created. It was not about the quality. And so there was a big outcry at the beginning of this month. Because a lot of people started creating pull requests that were. Not that they were taking a lot of time from maintainers, but didn't add anything to the projects. If you have been following Twitter and other conversations, you would have heard about that. So. I think. Hector or fast actually changed the rules. To accommodate that. But you get the same thing in your communities. If you value. Commits over other types of contributions, then. People will start to find ways to get more commits, but it gets fixed. So just be mindful about what you do with the data. And how you reward. If there's any reward. Community members. Based on that data. So those are the things that. I had brought as. A seat. To the discussion. I want to leave you with some resources. So I'm going to leave this slide up. I have one, one more slide if you wanted to connect with me. Feel free to reach out. You can find me on Twitter and LinkedIn. You can email me. But really this is. What I wanted to give to you. And. We have a podcast where we talk about. Specific use cases experiences with metrics and measuring and community health. We have the metrics. The software. And you're also welcome to join. We have regular meetings. We have the different working groups. You have a mailing list. If you go to chaos.community slash participate. You can find a community that is talking about. Metrics and. Participating and. Don. Already. Said she was there. Which I really enjoy. Always when we are on the same zoom calls. Talking about metrics. So this my invitation to you. And. Again, opening this up. What thoughts, what questions do you have? I don't actually know how much time we have left. This again, Sven speaking. I'm still trying to grasp. What, what just covered by chaos and what is maybe not. So one thing. Or what I really like is when you were talking about this dashboard and made this. Example with the car and maybe also cut the car test. For cars. I think it's pretty easy to have a checklist of things that you want to take that type pressure. And then you're like, okay, the car is healthy or working. That you have something like those checkers for open source projects or is it impossible from your perspective. To do something like that. That's an excellent question. And ever since we started chaos as our. Community of practice where we talk about these things. The. We've been asked, hey, just give us the. The five things that we should be measuring. And tell us whether it's in a good range or not. And the. We cannot have these. Here's what a good project looks like. Here's what a. Problematic. Project looks like. Because every community. Works different and is different. And so you really need a domain expert, someone who is in the community who can say, yes, the numbers are how they are because we work in this way. So just because projects use GitHub. And they share that technology. They have different ways that they're using GitHub. Some make it very clear that you need to. Link pull requests to issues. Others are more loose about that. Where you don't need an issue. To create a pull request. Or some use. Don't even use the issue tracker in GitHub. They use the issue tracker over in. Jira. So what we can have is a checklist. Of saying, hey, you want to. Make sure your community is doing well. So you look at the activity metrics. We can't help you. Say you have 500 commits that's good or bad, but we can say, hey, number of commits is something to look at. And if there's a change in your number of commits, that is something, you know, you need to understand as a community is that. Why is that happening? And tell the story. Interpret that. So you want to look at the community. And then you want to look at the community. And then the dynamic research shows that. Code quality. Can be a sign of community health. Resources. Do we have financial support? Do we have all the tools and. Necessary. Diversity and inclusion. If you're talking about how welcoming and inclusive to people field. Are they enjoying being part of the community? Are we welcoming new people in? Are we welcoming new people in the community? Are we welcoming new people in the community? Are we welcoming new people in the community? Not our most people don't stay forever in the community. What's our bus factor? Do we have too. Few people who carry the bulk of the work. So that we do have these questions. And if you go to the chaos. Metrics. You can see them. And we are building out more and more of those. So how do you get the difference of what chaos does. And what. Does not do this. It really leads me in the right direction. I mean, there's a lot of work. Some work on. Those issues also on how to build those communities like social architecture. So it's something I would think of. So. I feel it's something in that direction. Maybe back on off my question was. I had situations where. I was thinking of new. Of open source projects or maybe starting. Projects. Then a manager would ask me, okay, why is it successful? And so the question is, okay, what is actually success. Tell me what you consider success. And I can tell you why it will be successful. And. I feel. Some are goes in the direction of community has as well. Because maybe sometimes you. There's a situation where you really want only two or three people working on the project. Or. It's. Maybe the best solution. Sometimes it's not. So. Yes. Absolutely. That's where the goal question metric approach comes in. You define what does success mean to you or your manager. And then you figure out how do we. Show that. Oh, thank you, Don, for sharing the link in the. Chat. Well, we are. Out of time. I really appreciate you all coming. To this birds of feather and. Having a conversation about how we understand community health. And how we use metrics. Again, if you were. Well, if you're interested in keeping this conversation going, join us in the chaos project. Feel free to reach out. If you have questions to me. And I wish you all a good rest of your open source summit. Europe conference. Thanks for facilitating. Thanks, Don. Thank you. Bye bye. Thanks. Bye bye. Thanks. Thank you. Christopher. Take care. Bye bye. Bye bye. Bye bye. Thanks. Thank you. Christopher. Take care.