 who we will also thank for his participation as a member of the Dev Room program committee for his talk. Community data is not community metrics. One team's journey down the wrong path. This is gonna be great. Thank you, Brian. Thank you. Okay, I see that here the rowdy contingent here. So hi, welcome. Thank you very much for coming up all the way up the stairs to see some really great community content here in the Dev Room. Thanks to Laura and Leslie for helping to organize a fantastic program set and the rest of the community too. So yeah, community data. This is a topic that has come to the forefront in the last two and a half years or so as communities are really trying to figure out the value and the status of what is going on within their communities both in terms of general health of the community and also as that, you know, how does that community fit within a broader ecosystem? A lot of the free and open source software projects with which we work usually have, as Dev and Nithra pointed out earlier today, some sort of corporate environment too. And with that comes a need to sort of really quantify what's going on in the community. So a little bit about myself, that is not me in any way, shape or form, but I work with the open source and standards team within Red Hat. The nearest equivalent to that in other corporations might be called the open source program office. But since we're Red Hat, that's sort of redundant so we came up with another name. My team's responsibility is primarily to help maintain and help foster and help flourish the various upstream projects that directly and indirectly relate to our commercial offerings. We don't handle every upstream open source project that Red Hat works with. We handle quite a few and then we consult with the others. And I am very, oh, so fortunate to work with an incredibly talented set of people who help us do this. And my personal responsibility other than getting up here on stage and flashing my arms around every once in a while is working with content and also figuring out the metrics issues around our communities. This is something relatively new for us. And the story that I'm gonna tell you today is how my team tried to do this and actually didn't really make it work, at least the first time around. And so talking about data, I am a professed data nerd. If you show me a really cool infographic, I get all weepy, you know. If you show me a spreadsheet, I'm gonna be playing around with it for days. My managers usually don't expect things from me in a Word document, it's usually gonna be a spreadsheet. That is me. You too may have this problem. And if you do, it's okay to just accept it and you will be right with the world. Data can be beautiful at times. We see it all around us with information graphics and studies and because the way we can see data in a hurry, the old adage, a picture is worth a thousand words, it's certainly true. Our brains are visually geared to pick up patterns so it is easier to convey information in those kinds of patterns. If you think about that, that kind of makes sense because the first thing we learned when we were infants was a visual cue that's mom's face over there. I like her, that's dad's face over there. I like him and so forth. We learn things like language way later. Our brains are intuitively gonna go for visual patterns and cues far faster than any kind of language that issues to convey information. And that is why we typically respond positively to visually presented data. And nature kind of helps us along with this too because nature is beautiful as well. We look outside and thank goodness I have a good data actually show you this. It's a beautiful day outside. We respond positively to the cues. There's a blue sky, we've got sun, there's no wet thing falling from the sky. It's all good, okay? And there are other even more flashy examples. So hey, hello, let's say hi to the blue dragon. Now this is actually a little tiny little sea slug about yay big and it's also called a sea angel. And it's so pretty. It's like do you look at this and it's like, oh, that is an adorable little creature. Except maybe not because it actually eats man of war jellyfish, which if you don't know are pretty poisonous to most animals. And because it eats that, those jellyfish, it actually holds onto the venom. And anytime you touch one of those cute little fondy blue things, you're going to be in a lot of pain. So again, beautiful but harmful. This one over here is another one and some of you may be familiar with this. Let us not forget the man to shrimp. Now this is a pretty big crustacean about yay big and it has the ability, unlike humans and most mammals, it can see more colors than any other animal. We have about three types of rods and cones in our eyes. They have 16 and because of that, they can see colors that no other animal can see on the planet and it's certainly demonstrated in its shell. But then, and some of you might already know this punchline, it has the ability of taking those two front appendages and jerking them out with the velocity of a rifle gunshot, which adds up to about 1500 newtons of force. They can't keep these in an aquarium because basically for two problems, they pretty much kill and eat anything in the aquarium with them and they also break the glass, which can be awkward if you're a water based animal. So you're not gonna really see these in an aquarium unless it's behind some kind of bulletproof glass. And if for more information and you can get the slides online, there's an actual wonderful oatmeal comic that details this in a very charming and funny way. And I encourage you to check that out. So again, beautiful, but perhaps harmful. Data is also beautiful. And I've already touched on this a little bit. We like data, we like to see it visually represented and we automatically assume we're going to learn something when data is presented to us in a visual way. But the point of my discussion here today is to kind of dissuade you from that notion a little bit because data presented to us and just as a thing, a visual object and is not always gonna necessarily convey information. It has to be presented in a more concrete approach. You can't just throw things out there and assume, oh, this is going to magically tell me something. So we'll get to that in a little bit. So, and I apologize for this. This is gonna be a little bit better for those of you who are gonna look at the slides later. I have a couple of infographics that got a little fuzzier than I liked. But this infographic is basically two sides where we have a date line on the left side that shows the date of certain discoveries of scientific principles and inventions here in the Middle East and the Persian regions of the world and here in what is historically known as the West, so Europe. And the point of this information is that things like heliocentric, which is knowing that the sun is, the center of the solar system was figured out in the year 801 in the Middle East and you can't see it because it got cut off and that I apologize for. But it's something around 1500 in the West. And this is a very interesting chart that kind of tells the story of that. You know, we think in the West that we've figured everything out, but there's always somebody who's figured it out first. There's usually somebody who's figured it out beforehand. And this graphic tells that story well. And again, the link to that will be on the slides as well. Another link that's a little less fuzzy. And this one is interesting because it kind of gets to my broader point of telling a story and that it's not always automatic. This one is a lovely chart that shows recent data breaches and hats. I think the graph is about a year old now. And it shows how many millions of people and customers of these organizations have been, their data has been just hacked and thrown out to the winds. This graph can convey a lot of information. Obviously it's conveying numeric and factual information. I can see that Marriott hotels had a big problem, so did Yahoo and so forth. And I can look at individual companies and I can say, yeah, these companies have problems. But on a larger standpoint, the other thing that's being conveyed here is kind of twofold. If I were a security minded person, I would say, I would look at this and say, there is a lot of problems out there. If I'm an empath sec, these are, you know, this is a problem looking to be solved. If I'm a consumer of these services and I've used Marriott or Facebook or Yahoo or Twitter, I might have a different reaction. My reaction would probably be, oh my God, I'm getting offline and never leaving my house again. That's not a terribly invalid solution. Same data, different conclusions. Because the people looking at this data, and I guarantee you, a lot of you probably are gonna have some variation in between that. We all look at data differently and we take different meaning and different stories from it. And because of that, you can't just assume that if you have a treasure trove of data just magically laid at your feet, that you're going to find all the answers that you're looking for, because it's not always helpful. There are certain criteria that must be met to make sure that when you're talking about data, that it's actually communicating information. And that is the difference that we're talking about today. So for those of you who do not know, there are several metrics, platforms and packages out there that help monitor and measure community-oriented data. The one that I like really well is from a company called Beturgia. And if you're not familiar with it, Beturgia has a very talented set of engineers who know how to get into sources of information, such as GitHub or GitLab or IRC channels and mailing lists and they can reach in and pull out a whole bunch of data and they can put it in a very nice, again, it looks better in person instead of up here, but a very nice graphically-oriented dashboard with which community managers like myself can theoretically drill down and find information on what's going on in their communities. And this one is one that's actually still live. This is a project in our pantheon known as OpenShift and the OpenShift team and project still uses their Beturgia dashboard to this day. The rest of the teams that were using this within OSAS and a few outside of OSAS have stopped using it and that is actually the little story that I'm gonna tell you today because this did not go as well as planned. So about five years ago, I came on board at Red Hat and I came to Fosden for the first time and like many of the other, for other first timers, I was sort of overwhelmed by the campus, the people of so many people, the huge variety of thought and ideas that were going on at Fosden. And Red Hat is a very active participant in Fosden because for us, this is one of the main places in the world that community lives and we always try to be here. And another reason that we come is that it's a good meeting place. So one of the people that we meet with when we come here is Peturgia. They're based in Spain and this is a good place to sort of have one-on-one meetings with them. And I accompanied my then manager to meetings with Peturgia because we were trying to implement a metrics package with them and we wanted to have dashboards like the one I just showed you for all of the different projects with which we work. And long story short, they made that happen and I had a dashboard for my project which was at the time called Overt. I now work with all the projects, Overt's still there, but I work with more now but at that point I'm working with Overt and RDO had it and Project Atomic and so forth and so on. Every project had a dashboard. As the person who is involved in the discussions, I really tried to use this information. I knew what it was about, I knew what was going on in the back end, I knew how it was set up and I really, really tried to figure out things about the open source community based on this dashboard that I was being presented with. And the problem was this, I couldn't do it. I don't consider myself a reasonably dumb person but for some, you know, some may disagree. But for the most part, I couldn't really figure out anything that was going on that was meaningful from this information. I would see things like, okay, the mailing list traffic is going up and to the right. What does that mean? In some respects, you would say, oh, well then your community must be growing. You're getting more users in there, people are coming in, they're asking questions. There's more dialogue, everything's going great. Maybe, but by the same token and this happened in one of the other communities, it might also reflect that you've got a release coming up and the traffic goes up and then it goes down. So some of this is a baseline thing. You can't just look at a snapshot and figure out what's going on. You need to see patterns and cycles. Another thing that could have happened and did is that there was some contention and to be honest, some trolling going on in one of the community mailing lists and there was an active fight going on. So the messaging traffic went up and you could not tell from the dashboard what the problem was. You could not even know there was a problem unless you were in those mailing lists all the time. And to some extent, you know, you're gonna say, well, yes, but a community manager should be in the mailing list and they should have known they have a problem. And yes, you're absolutely right. But we made these graphs public. All the dashboards were presented on websites that anybody could see at any point. We might know what was going on but an outsider looking in, again, it was there, it was open, it was transparent but it might not necessarily be conveying what was actually happening within the community. And as much as I was trying to use this tool and make it work and really making a go of it, my fellow community managers were even less enthused about this thing because again, it wasn't telling them anything and they weren't as invested as I was. And by the way, I'm not throwing anybody under the bus. Here, mostly me. But everybody else was like, I'm too busy to work on this. It's not really giving me anything I need. I have to move on. Thank you. So, we stopped using it. And with the exception of OpenShift, whose community manager, and I'll throw props out to her, Diane Neeler, knew what she wanted from this, dashboard of information, this pretty set of data, all of us stopped. And currently, we are sitting in a place where none of this information is being collected or watched right now. We have backed off and we are regrouping. So, what we learned from this is relatively straightforward. We learned right away that there's no way you can really approach a situation like this and look at a bunch of data and draw conclusions from it because we did not know what we were looking for. The good news is, right about the same time this all started kind of falling apart, we started getting involved with a project in the Linux Foundation known as Project Chaos. Project Chaos is dedicated to two things. One, building a really solid set of standardized metrics that can apply to any community and look at it, look at those metrics and determine health around areas like growth, maturity and decline, risk, diversity and inclusion and several others. And Chaos, by the way, I don't have it in my slides, is C-A-C-H-A-O-S-S, so it's got two S's, Project Chaos and I look, I invite you to take a look at that. And we became involved with them and working on building the metrics and figuring out what metrics would be valued. And that was great because then suddenly, my team and I had a whole bunch of things that we could start looking at and we had a basis with which to start the conversation because number one thing that you should take out of this is questions are critical. Those of us who are nerds and I'm sure there's a whole bunch of us in the room, we read Douglas Adams, what's the answer to life, the universe and everything? Thank you very much. What's the question? Aha. Yeah, I know. There's always one of you out there. But yeah, what's the question? We don't know what the question is and that's what you have to take to the, when you're looking at a community and looking at its health, you have to have a question in mind. Think about it like this. If you're not familiar with how the scientific method works and I'm pretty sure we all are, I mean, you've got to have a hypothesis. You don't come in with a set conclusion but come in with an idea that says, I wonder if my community is doing this or I'm wondering if we're having a problem with this part of the community over here. You have a question, you have a hypothesis. Then you start looking at the data and see if it supports your hypothesis or negates your hypothesis. That is what we should be doing. We have to frame question and don't make big giant questions. Don't come in and say, is my community the healthiest community in the whole world? No, don't come in with that. Come in with smaller questions. Make your questions finite and narrow in scope so you can come in and get them answered. You're not gonna solve everything in one day. You're gonna have to look at little pieces of your community in discrete ways and figure out how things are working or not working. And then finally, the answers must tell stories. Now, I wanna be very careful here because that might sound like, well, whatever answer I get, I'm gonna make it sound good for me and I'm gonna make it look good for my community. That is not what I'm saying. What I am saying though is you have to take an honest look at what the data is telling you, what the answers to your questions are and you have to be honest in presenting them as a story. I mentioned earlier on that we as human beings tend to react to things visually. We also tend to react to stories way better than anything else. Frame the questions and the answer and tell a story about what's happening in your community even if that story makes your community look bad or you look bad, because at the end of the day, if you don't get that story out there, then nobody's gonna understand what your situation is. And a story, by the way, is not the end of it. I'm telling you a story now. I have a sneaking suspicion, some of you are gonna come to me later and wanna keep talking to me about this. I haven't told the story and said, the end, we're done. I've started a conversation with you. And that's what you really need to get going. A good story is going to start a good conversation, collaboration, because your story might be wrong. You might draw the wrong conclusion about what the data is telling you. That's okay. Because by the act of telling the story, you're gonna get more people involved and you're gonna say, oh, Brian, that's not really what that means. I think it means this. And then becomes the back and forth. And then becomes a collaboration and working towards the higher goal of the truth. So if you continue to tell those stories and if you continue to know what the questions are about your community, then maybe you will use a dashboard someday. This isn't an anti-dashboard discussion. Or maybe you'll always just have very sharp, detailed, I know what I want, I wanna see, I want that displayed and that's what I wanna see. And my good friend, Don Foster, right after me, is gonna give really good, you know, actual tips on how to set this up and build and work on community metrics. So I invite you all to stick around for that discussion later. So with that, I will say thank you. This is me and if there are any questions now, I'd be happy to take them. You're excited to hear your questions. What questions do you have? Excellent. Can you please pass that? Just in regards to obviously community data. So how do we perhaps frame it for managers versus the community? So if we're trying to source out data based on the community, how can we frame those stories to be appropriate to people who have one single-minded track? I think that you need to know your audience. And I think that that sounds very trite, but I think that knowing your audience is important to whatever story you're gonna tell. I'm talking to an audience here that is probably a majority European probably doesn't care about the Super Bowl tomorrow, although there was some guy in the back earlier. So I'm not gonna stand here and do sports metaphors here because that's just not gonna work. And I'm certainly not gonna try to do your football as an analogy because I'm gonna get it wrong, you know? So that's part of it. Humor aside, knowing your audience, but so you're gonna know what your managers are looking for. You still have to be honest. I'm at no point in ever am I gonna say try to, you know, couch things. But if managers are looking more for more business data, then those are the questions you need to frame. And that actually in some ways makes it a little bit easier when you have questions from an outside source because they're right there, okay? How, you know, a question that we like at Red Hat and is this very hard for us to answer is how does all the work in our upstream projects, how does it translate to maybe later downstream commercial use? We don't really know that because it's been hard to ask that question. But that is, thank you for helping me make that point. I should have.