 Hello everyone. Finally, we made this meeting together with GELG. Firstly, I would try to use myself and then hand it over to GELG. So my name is Yohui, and this is GELG. Hi. So sometimes when we are in open source, we hear the sentiment that, hey, we released a new version, and it was like magic. No idea how it happened. There's so much going on in open source communities and open source projects that sometimes goes unnoticed, and so many people involved that we just don't know what everyone is doing. And this is a motivation for what we want to solve and where we need to have metrics and insights for. Before we jump in, let's explain who we are. Yeah, yeah, yeah, just introduce yourself or background, right? Yeah. So firstly, I formally introduce myself again, right? So hi, my name is Yohui from China. Currently, I'm working at Huawei as a developer in the open source content center. So I'm also an active contributor in Chaos community. My focus area is about open source community health management. So I'm super interested in the metrics and the metrics model. That's why I come here together with Chaos, with GELG, sorry. Yeah, and I am Georg Ling. I'm a co-founder of the Chaos project. I currently work at the Biturgia as the director of sales. And yeah, it's really great to have Yohui working with us on a lot of the things that we'll show you today. And we come at looking at open source projects from a perspective of wanting to understand project health, which we can define as the potential to continue developing quality software. So is an open source project set up correctly with everything that it needs to continue producing the quality software that we need? And we can understand project health by looking at the people involved, the practices around the creation of software, and the performance within the procedures and processes that they have. And within the Chaos project we have several, we have had many conversations about how do we go about doing this. The fundamental idea is in open source we are working in the open. Everything we do is transparent. There's a Git log, there's a mailing list archive. Everything is public data of what we have been doing. So we can take this trace data and make sense of it. So we need some tools to create metrics and then we get the insights about project health. But before we go there, there is a word of caution because it's like drinking from a fire hose of data. There's so much. And so we have developed some recommendations before we get started. One is use the goal question metric approach. First decide on the goals for the community or why you're looking at an open source community. Then ask meaningful questions for reaching those goals and then only then look at the metrics that actually help you answer the questions you need to make meaningful decisions. Also the metrics. Don't look at metrics for the sake of metrics. Tell a story. Metrics are living in the context of a community and they can help us tell the story of the community. And they can support that story and make sure that we're telling the right story not just making things up. So think of metrics as a tool for telling stories. And then with regards to the community, be transparent about analyzing the data. Let people know that yes, we are looking at the Git log at the mailing list archive and so on so that they're not surprised. And especially with recent regulations coming out like the European General Data Regulation GDPR, that's the short. I messed up the name. We really need to be putting our contributors at the center of this and make sure that they are aware that this is happening. And healthy projects depend on people. So as we're looking at projects, think about the people and how they are feeling and make sure that they are well and okay in the project. And I'm going to hand it over to Yihui to talk more about metrics and how in the chaos project we're thinking about metrics. Yeah, yeah. Thank you. So last month, October, you know, chaos community just released the latest version, including like 17 metrics with, I guess, 14 new metrics. It's a huge number, right? So it's kind of, I mean, it's kind of hard for the people who never know chaos metrics before to get started using the metrics. So why don't we just adapt those metrics into some use case or scenarios, just like Gallup mentioned, the stories. So we describe the different scenarios in the use case as a story that happened in the open source community. But here, it's kind of like a tactical development flow that usually happened in the open source community, start from creating new issue ended by merged code. So in each of this single touch point, we could insert all the metrics into this touch point. You know, okay, who are the first, what's the first response point, and what's the average close time for the issues or PRs. So we use the stories, stories happened in the open source communities to describe our metrics usage. That's why we introduce our metrics model here in community. And metric models are really something we've just now started to put together. And I'm super excited about them because they're like use cases for metrics. It's really amazing. So for getting metrics, we also have some tooling in the chaos project. Grimoire Lab is the older one of the tools that we have. It has solved the problems of collecting data from open source projects and processing that data and making it useful and providing meaningful visualizations. And Grimoire Lab has become an industry standard for looking at open source communities. And we can go more into examples of where all Grimoire Lab is being used. But for today, we want to talk about how we can use Grimoire Lab with GTI. Yes. So as you know, GTI is a very popular code management platform in China. So that's why we are looking for some management platform to support to gather the data from the GTI and to gather with other data. So this is the basic flow to inject the data from GTI and be handling the data carrying out metrics. I mean, the metrics getting from chaos and creating visualizations using dashboard and finally, we did integrate GTI support with Grimoire Lab. So I can't explain that in the next page. Yeah. Really cool slides. Very colorful. Yeah. So as you know, the community is not just code, right? It's about people. It's about communication. And it means a lot of other things. So that's why we are looking for some management platform, not just supporting the code collection. It's also about some data sources like child platform and issue tracking platform management platform. So here you can see that Grimoire Lab already supports lots of data sources as backend like discourse like to gather with GitHub, GitHub. So that's why we choose the GTI to integrate with Grimoire Lab. Here you can see that. And of course, we are using the chaos metrics to calculate our data upon that. And based on that, we finally to display the data insights through the visualizations on the dashboard. And we'll show some examples for these visualizations here in a little bit. So stay tuned. Okay, cool. This is Grimoire Lab component for Chrome together with GTI. You can see that basically, the Grimoire Lab has several components. We can derive several steps together with data handling. The first one, we're using Perceval, the one component from Grimoire Lab to fetching and gathering the data from data sources. For example, from GitHub, from Slack, from any other data sources. And then we're just using the Grimoire, a Grimoire ERK to store our data into the database. There you can access search or any other database. Meanwhile, we also manage the identities using the sorting card. For example, if two people, if one people have two emails coming from the different data sources, we can work them together into the one people. That's quite cool. So we step into the next step. So we have to analysis our data. How to analysis? We're using chaos metrics to calculate our data to generate like merge, PR merge, average time, issue response time, something like that. And finally, we'll do some insights. Insights, we are using some very cool visualization platform and display on the dashboard as we all mentioned, we'll show it later. Yeah. This slide, I will quickly go through how to use the Grimoire to gather visibility. It's quite simple, actually. We are writing the big page on the GitHub. You can go through it. I have put the reference link in the last slide if I remember correctly. Yes, we have that. Okay, please. Okay, first, we have to set up our environment, developing the environment, like gate, Docker, and doc compose. And run the doc compose, we have put it ready for you. It's set up the database. And then you can build the Grimoire soft code and it's a really friendly user development friendly for the developers. So we can use that. Meanwhile, you can also add more features through this way. So then you can install the gate models. We put the link on the big page. And finally, you can run Grimoire with gate. And you can start writing the data you configured in the configuration file and fetching the issues, pull request, and get commit message, and the other data you can collect from the gate. That's really cool. And if you have any questions, see who is the one who built this. So open an issue or ping him on Slack. I'm sure Yui would be happy to help. Of course, of course, definitely. So let's look at some examples of visualizations from Git data. And what can we learn from them? And let's focus on the people practices and performance side. So let's start with people. This is a network diagram where each of the dots is a contributor in an open source community. In this case, it's the chaos community. And each of the blue rectangles, if you were to zoom in, we can read it's a repository name. And if there's a line between a dot and direct angle, that means a person has contributed to that repository. And we can see here the composition of the community. Where are people active? And where are... Where's the activity happening? How are they related? And who are the people that are connecting the different parts of our community? Exactly. Yeah, it makes me think of it as something like a social network in the open source community. It's connect everything together as a network. You can say if the node is larger, means this guy contributed more in this project. And you can find different connections between different communities and repositories. You can find this relationship. And you can find more interesting ideas after you set up the whole network. Yes, absolutely. One thing we can also look at is how organizations are involved in open source projects. For this information, we need to make sure each contributor we actually have an affiliation set up. So in the sorting hat module of Grimoire Lab, we can go in and say, hey, this person works for Huawei or Biturgia. And if they use the work email, we can automatically assign that. Otherwise, if they just use a generic email address like Gmail, it's harder to know. Once you know your community members, you can manage that information and then you get insights to how active are different organizations through their employees in our open source projects. Okay. For practices, one thing we might be interested in is where is the activity happening across different modules, across different repositories, and who are the most active people there. So we can identify who are the maintainers of a specific part of our community or is there a part of the community or the project that is being neglected where we haven't seen any activity in a while. So this heat map, for example, can help us understand this. Yeah, yeah. And then, yeah, go for it. And also you can find the most active project and together with the people from this heat map. It's really cool to call co-contributors from all those repos. It's kind of like style from the GitHub, right? Yeah, it is. And then finally, for performance, one thing we might be interested in is how long does it take for us to respond to issues or pull requests and how long does it take to actually close them? If you go back to the metric model, those were some of the metrics that we're looking at. Yeah, I can find a lot of metrics in the evolution focus areas. It's all about development process happening in the open-source communities like issue-related metrics, pull requests. Of course, we also call it change requests in the heat map. But it's really cool. We already use that to compare the two similar community to say, okay, your average close time is two days, my is one day. It's super cool. And it's also important for the health of the community because if you have people coming to your community and they don't get a response on their issues or pull requests, then they forget about it. They lose interest. They no longer come back. And so you lose that opportunity of engaging them. So have this in mind and keep track of how your community is doing. This brings us to the end of what we wanted to talk about. And here are some things, a gift to you. Yeah, the first two slides, Katie and the group live. We set up the organization on GitHub. It's stored everything about these integration solutions. You can get it. And the second link, it's about chaos metrics. We talk a lot in the presentation. We have 70 metrics in the chaos community. Just use it. It's very helpful. And the chaos cost, I think you may have more experiences on that. Yes, I'm the lead organizer for our podcast. And we bring people onto the podcast to talk about their experiences and their use cases with measuring open source community health. And this is where you can learn how do people in different companies, in different places, and for different use cases, use metrics and make meaningful decisions with that. So the chaos cast is really a great place to just listen to what others are doing with metrics and open source. It's really cool. I listen to a lot of episodes. I can hear many people from different organizations and communities. It's shared with us a lot of experiences happening in the community. It's really interesting. One thing we're currently in conversations about is starting up a Chinese version of our podcast. That is something that you may want to look out for. Yes, we also do some chaos cast in speaking Chinese. And in future we will provide more episodes about it. We will show it later in our chaos community. You will say that. Absolutely. And then finally, come join us. We have weekly calls. We have five weekly calls. There are many different working groups to get engaged in. Go to our website chaos.community.com. We have a calendar. The meetings are usually Tuesday, Wednesday, and Thursday. No one wants to meet on Mondays or Fridays. That's the big of a line. It's a lot of meetings. There's a lot to get involved in and join. We'd love to see you there. Summing up, concluding this conversation. Thank you so much for joining us. We have talked about what is project health and why we need to understand people, practice, and performance. We have shown Grimoire Lab and GTI support that you can use to look at your open source projects on GTI. We have shown some example metrics. So you can start looking at your data. And we have shared some best practices around using the goal question metric approach, telling stories around metrics. And, you know, just get started. There's a lot to look at. Just start slow, one metric at a time, make better sense of the community, and then you can always improve from there. That's true. Okay. Thank you, everyone. So I think we still have 10 minutes or 15 minutes like a question and answer part, right? So if you have any questions about Grimoire, about chaos, about Grimoire with GTI, you can tell us. We can try our best to answer these questions. Yes. Thank you so much for joining us. Have a good rest of your conference. Thank you. Bye-bye.