 The speaker is Jesus Gonzalez, and he's the co-founder of Bitergia, and I'm sorry, right? That's fine. Yeah, okay. Well, I catch the name, the other one is. Which is a software development analytics company, specializing in analytics, analyzing of free and open source software projects. He also is a teacher and a researcher at the Universitat Rey Juan Carlos in Spain in the context of liberal software research group. His interests include the study of communities of software development with a focus on quantitative and empirical studies. He enjoys taking photos of the coffee he drinks around the world. Welcome, Jesus. Thank you very much. I'm using this one. Oh, yeah. I'm always using this one. Can you hear me? Can you hear me? Okay, thank you. Well, first of all, thanks for staying here. I'm going to talk a little bit about the rise, but I'm obviously not a rise developer. I would like to put some context into this before starting talking. Like, a few years ago, we started to talk with the Mozilla Foundation about how to put analytics to track the different projects that Mozilla is having. We started to do that during the last autumn, and right now we're working with some people in the community team to basically try to figure out what's happening in the different communities around Mozilla. One of those is Rust. And like two months ago, it was decided that the Rust dashboard goes public. The Rust dashboard is exactly what I'm going to present here today. And it basically tracks what the people around Rust is doing from certain points of view. So it's not only the development, but it's mostly the development. The area is quite simple. Since most of the activity is public, let's track what's happening in that public activity data. And let's produce some information with it so that the people interested in the project can know what's happening and can react to what's happening. So that the community is, let's say, more of a safer world of what's happening in it. Because when the project is large, usually just a few people know what's happening, but the rest maybe don't know. So there are several views, and in fact this is work in progress. And I'm going to skip the first part, because you should see us talking a little bit about me and something else. Let's go directly to the dashboard. So first of all, you can see that this would be live, if you want. You have the URL of the Rust, Minerals and Edits, .mozilla, .community. And it doesn't really work on the phone. So try to do that with your laptop, if you can, or with a tablet. And there is to show information from different data sources. In this case, on the top you have Git, then you have a stack of the flow, which is a part of tracking what the community is doing around Rust. Then you have GitHub issues, GitHub pull records, and there is some more information from this course as well. Each of the information there corresponds to one data source, if you look by roles. If you look by columns, on the first one you have some simple metrics summarizing. On the next, you have some metrics summarizing activity, like the number of commits or the number of pull records or stuff like that. And then you have people. You have a number of people offering commits, a number of people submitting issues or stuff like that. Here you have a lot, a very rough try to have affiliation for people. It's not very well, so any back reporter will be telling you later how you can submit it, because many people are probably not well-affiliated yet. But the area is to show how many people are working for Mozilla, how many people are working for their companies, and how many people are working as independent in the community. And you can filter that time. If you go there on the top right, there is time, but the fault is like two years ago, I guess, that you can focus on the latest activity, like the three months. And you can select any period of time and so on. Everything needs to be enabled. So you can pick almost everything. You can resize things. You can move a charter and stuff like that. And you can say, if you go there after doing any kind of filtering or something, you can go to the top right and so on. And I'm going to go to the real thing. My connection is a bit messy, so I'm not sure if I'm going to be able to do this well. But, well, and there it is. Okay, so good. We'll see a bit about it. So you have that menu on the top, where you have the different data sources. And for it, the data source you have, sorry, a panel, and in some cases you have more than one. As I said, everything is set to enable, so you can click and filter. So for instance, this is a total activity for us. And by the way, you can notice how this chart is different from the one in the main page. That's the case of lots. If you remove the filter in lots, you can see now that the activity during the last time is a bit higher. And I also have to say that this is tracking the activity in the world of the story, which means that those commits, they didn't make it to the repository yet, are not there. But maybe they're having a date from, let's say, the past. Because we're tracking half the time. So that means that if the commit was done, like, I don't know, one month ago, and maybe it's going to end in the repository next month, it's still not there. So that's why this trend at the end of the chart is somewhat usual. In any case, you can track, as I said, people like Anthony, for instance, if you're interested in who of those are working for Mozilla, you can just add the filter. And now you're seeing activity by people about Mozilla, as I said, assuming that the data is not the story. You may notice those filters over there, the red and green boxes. You can click them then, and if you look, I'm not going to enter into the retails, but you can see how you can activate them, negate them, and stuff like that. So that, for instance, you can see how the people not working for Mozilla are performing in the different data sources. You can as well go down and see more information like the number, the name of the people and their contributions, the organization, number of organizations over time. And you can also go and check the different repositories that you have. And you can, for instance, filter for one of those. So I'm going to filter in the last repository. And this is now the main activity for the last repository. By the way, this is the time zones of the people working in DigitalZero. So basically this is California and the East Coast, and the West Coast and the South, this is East Coast, and South America, this is Europe and Africa, this is Asia, and this is Australia and London. The most interesting information from my point of view is from the Github staff, where you have how you're performing and doing things like giving back reports and stuff like that. We don't have separate analysis for the different kinds of issues yet, but for now you can see how the number of issues are coming at a time and the different colors are related to whether they're still open or on the East Coast. So you can basically camp here and see through it. In this case, let's say, Coast is a ping answer, well, that's still in the spring, so you can see the number of bags that you still have closed from the path, and you can see how many people are submitting bags at a time. Again, you can click on many things like filtering the repository and stuff like that, and maybe the most important, you can come here and see who is submitting bags issues by affiliation, by the campaign. You can, again, look at the number of the names of the people doing that. If you're interested in performance, how are you really dealing with closing tickets? Some metrics are very important, like how long does it take to close 50% of the tickets, for instance. And you can see that in the issues timing. You can have, again, all the other stories, but on the bottom part, you're starting to have some information about how long does it take to close the tickets submitted by this person, for instance. These are days. So you can see for some of them it's 100 and something days, for some of them are 20 days and so on. And probably the most interesting one, of course, you can actually go directly to the tickets. Those are the latest, and those are the earliest. For instance, this ticket here has been sitting in the repository for about 7,000 days, like a couple of years. And you can look at them, and it's also an issue of going there and see why this ticket is still open. So maybe there's a reason for that to get the weapon, or maybe you can somehow assign you to somebody and close it or something. And on the right, you can see some charts related to, as I said, the median time in the closing bags. So this is how long does it take to close 50% of the bags? And the last is in days. So you can see that you have the spikes of around 150 days, but right now it's much closer. That's the month when the bag was reported or when the issue was opened. So that means that for all the tickets, the time is smaller than for certain periods in the history. This is the same for 80%. I mean 80% just at the beginning. That means that a ticket cannot be seen in the repository for longer than the time since it was opened. So that means for 80% of the tickets, most of them are, I mean, the remaining 20% are still there. So for all the months, you have probably more than 20% of the tickets are still open. That's why you have this sharp line over there. And again, you have some errors, and issues open and closed. And you can, by the way, filter, maybe for instance, only for open tickets, which is usually the most interesting view, because close is close, but you can see the same data for those tickets that are still alive. And you can see that in that case, you are still in the creation in the lab tickets. You can see the same for two requests. I'm not going to enter into details just to show you the general information, which is quite similar to tickets. But when you're talking about two requests, you can also see the timings. And the timings is basically the time from the moment somebody submits a pass to the moment somebody gets the information, sorry, gets the pass landed in a gate. So that's the way to work in metric when you are trying to attract developers, because if they are submitting data, submitting code, and the code is taken key on to be accepted, usually they give up. This is the battle. The battle is basically the staff that still needs to be done, so the things that are alive, from the point of view of our issues, and from the point of view of two requests. So again, you can see some numbers, like how many times we are dealing with this, and this is the structure by time of, in this case, issues. So these are issues still open by time. So this is, for instance, 2015. So for the last two years history, there are about a certain number, around 30 to 50 issues open. There are two requests that are different. So this is the backlog, and here you can see the completion, because in pink you have issues, and in green you have two requests. And you can see now for green requests, most of them are already closed. So you only have some green spots in some parts. You can filter them, and see exactly the structure of the two requests. And you can see now there is much more than two issues. So that means that you have some two requests which are the recent. Most of them around this time are closed, and you have some of them that are the ancient, like two years old, but just a little of them. So the structure of how people are closing two requests, or dealing with two requests, and dealing with issues is very different in this project. And another interesting view is, as I said, the structure of the flow, because the structure of the flow talks about the outreach of the players. So how many people are asking about this project? It's a big indicator, in general, of how many people are interested in this play from our development of the view. And the trend here is also very interesting. If you look only at questions, which is as we're filtering here, you can notice how the pension was going up during the 2015, at the beginning, went down, and in the beginning of 2016, and then it's going up again, maybe a bit slower, but more consistently. So this trend is basically, or this trend is probably very likely to the interest of the development community in the language, at least from the point of view of when they are willing to make questions and so on. Of course, with time, there are more questions answered, so you have also to discount that. So in many cases, you have not questions because people already have the answers inside the flow. And with respect to this course, well, you can see basically the structure of how discussions are happening. Since our discussed volumes were started to be used not that long ago, you have this very quick training, so this very quick option. Still, it's difficult to know whether this is really a trend or this is just because people are starting to use the forums now. You have, of course, a very specific place who is talking in those trades and all that. And with respect to the last week, I guess this is also going to skip a bunch of slides, which basically we're dealing with all of these. And both of them are going to talk about the software doing this. All of these is, of course, free software. And the architecture is quite simple and gives a lot of opportunities for developers to come and script and get data. We basically go to the stories with a tool called personal, that is information from it, and a story in elastic search. Then we are basically to produce the Kibana indexes because the code that we are using for the dashboard is Kibana. And all will be sourced everything with Kibana. Those indexes that Kibana uses can be also created with a language, with Python, for instance. And that means that this way is simple to get the scripts to do specific things in the data and get interesting metrics that maybe you are interested in. Or things like my activity in the work of stereo or Python, or which are my various contributions or whatever. So there is a manual for using the algorithm online. And the people living with this in Mozilla, which is basically Henry, is very interested in finding some people who could be interested in looking at metrics and providing any kind of input. Or trying to learn how to extract information from the database and so on. These are the tools, for instance, this is the tool, this is how the backend supported. And this is a very simple Python code, which is key in the activity number of commits, removing much commits from a certain byte by code. So you can see that it's not working science. It's just getting a couple of queries. And this is a standard elastic search. So there's nothing as specific for all the tools. The main lesson here is that there's a lot of data in the database with what the developers have been. If you're interested in getting any kind of idea of what's happening, or try to find reasons for things, it's very easy to go there and look for the data. And this may lead, hopefully, to more interesting discussions, because you can discuss some data on opinion. And just to finish, you can also check how many of you want, which is basically the same as that, but for analyzing any GitHub organization. So if you want, there's a new organization there, it's free, and you get the free does work with all the organizations. More simple than the one for last, but usually interesting enough for giving it a try. So it's just how to go to IO. And enjoy. The idea is go visit there. If you have any kind of comment, back report, suggestion, go over. We're happy to get it in the participation metrics for the repository for GitHub, for Mozilla. And if you want to learn more about PimoLab, do you have PimoLab.PimoLab.io? Or do you have how to run in 212 to a nice training manual where you can learn about the thing? And that's it from my point of view. Any questions coming to anything? Do you need the microphone? The question is about how we learn to have persons to organizations, right? We do it in 2 steps. First of all, we certify all the identities for the same person, which basically means trying to match the email addresses and all identifiers, GitHub identifiers, and stuff like that. And then we try to affiliate them. For affiliate, and then we have, like, some logistics, like using the email address. If you have one in Mozilla, email address is probably for Mozilla, for instance. And then we can do it manually, too. There's a file where basically we find, we try to define for every person the different periods of affiliation to them. This file is going to be served with the community so that the community can also update it. But that's not...