 So as I tweeted out a few minutes ago, or an hour ago, so after watching this conference for the last couple of days and participating in other things, I really think the conversation style, it just does make a huge difference. And from what I'm hearing, somebody talks for about five or 10 minutes, that's enough to keep everyone engaged and then for people's engagement to stay there and then switching to some kind of conversation or back and forth really helps. So I don't have another person to work with today. So I'm gonna find a way to work with, we'll either add people in if you wanna come in or we'll do it from the chat channel. And if after we get there, we'll see. I'm hoping that there's enough engagement for that. So there is a YouTube video and I think we can, I'll reach up there and see if I can pin it, so I can replace and pin it. So I'm gonna do that. And yeah, so feel free to check that out any time or share it with any people. It's literally the same stuff. I've given this talk a few times in different forms. I did this at Bosdom earlier this year, not directly, but just let a workshop and then a birds of feather session and a talk at scale over this year. So again, this was all just gathering momentum towards working on something. So let me go forward and I'll spend a couple of minutes talking about what this thing is and where we're at with it. So in general, we had this vision for the guide and there's some history of how we got here. And then I'll, so I won't take too long on that. I'll talk about what we are here today and then what's coming next. And I will remember to slow down. So the what here is what are we really trying to do? And it started out by wanting to create a community management best practices guide for open source practitioners. And practitioners is a nice broad term. It's not saying, oh, if you're not people whose job it is to be a community manager, air quotesy, but anybody who cares about how we practice open source software and the development of that. And then also to make sure that it's written by and from the experience of those practitioners. And this can be practitioners of many levels. Some of the, we have contributions into this process so far from people who are new to open source and their new questions pointed out the holes in our outline, for example, and created new content to be made there. So just like anybody comes along can help fix the documentation and so forth. And then in this process, we're actually creating a community of practice to maintain and grow the guide. A community of practice might be a new concept to some of you. In general, it's a way that academics and so forth has studied how corporations and organizations broadly, let's put it that way, whether a loose organization or a tight organization have developed communities of people, meaning people who get along in a friendly interpersonal manner who are focusing their community energy towards getting better at the practice of something. So this could be a loose organization like skateboarders who get together and practice skate tricks but a formal organization like lawyers who get together to take legal training and better their practices and things. And so that's a model of what we do in the open source software community. We're always trying to improve what we're doing and the practice of whatever software we're trying to create. And in this kind of meta community here is to focus in on the best practices or how to foster and maintain those communities. So these two things are happening at the same time which is something that I was always hoping was gonna happen. So going back to a little over 10 years ago, we set out to deal with the fact that we were always answering the same kinds of questions and the questions of, and those questions included not just what we should do for an open source and how you do something in terms of how you make a decision in open source or what's good governance or how do you deal with difficult situations with users and so forth, but to include the why. Like why do we think this practice versus a different practice is important. And then to write down those things that we say all the time. But in the last decade, there's been a more of an evolution in open source development practices. Lots of things are better understood and there's always a chance to improve what we're doing. So in general, we have this kind of top level guide and this gives you the viewpoint of the perspective or the opinion of the people who are working on this which is that it's always good to start by understanding what we mean when we say community and open source community. And then the belief is that the way we grow in open source community is by taking care of users. That users are the ones who are going to take the software to a new level, help you find new things about it just by the fact and just by their excitement in using it and some of them will become participants and some of them will become contributors. If you set out with this goal of just going straight to the contributors, it's a lot more of a difficult process. It's sort of for the code over the wall and hope that the contributors come along is a challenge. So the model that we promote is this one of like software wildly successful with users and the participants and the contributors will come along if you lower the barriers appropriately for them when they get there. And all of that talk about measuring success and avoiding pitfalls from mistakes. And so this is the outline of the guide that we are working on and this guide has been informed by these communication and these conversations that we've been having over the last year. I mean, as we began working on it. So there's been some evolution in that. And here I'm not really going to spend a lot of time getting talking about the outline but we have a number of chapters and we have a GitHub repository that we've been doing all the work in in terms of where the latest really is at. So I can spend a few minutes after this presentation and show that, you know, show where we are in the GitHub repo and explain why we're using all this tooling and so forth. The, but the basic outline that we've got, you know, just gets into a little bit more deeply. But one thing I wanted to highlight here is actually three different pieces, the new and to be done pieces. So out of a conversation at scale, somebody suggested that we turn all of these, this big massive guide into a quick start checklist for communities that are smaller. You know, two or three people may be starting something. Just want to make sure they're heading in the right direction. So that's an example of just a good question from an audience turning into something that's going to become a nice work output to get picked up, right? And this wasn't just a question from the audience. It was part of a communication, part of a discussion of a source and while we were doing this in a Birds of a Feather workshop. And then on the way we realized we had a, you know, we're missing some content around project communication and that came up with something that worked that was happening downstream in Red Hat and that content got upstreamed into the open source way to help form the basis of that chapter. And then the, some new content has come to us from another public, another book series, the O'Brongan Organization, and they had a chapter that didn't quite fit their outline on inclusive communities and material fit a whole that we had in terms of not discussing and not having discussed, you know, clearly discussing how we're going to handle inclusive communities and wanting to make sure that comes right up front in attracting users. If they're very beginning, you want to be, you want to be inclusive from that very beginning point so people can come and get in the project and know that it's self-suffer they can use and adopt. And that's one of our preview chapters and we're going to be doing a preview release within the next month of several chapters that are ready to go. And so you get a chance to actually see what the content looks like and actually have some useful things that come from it and help maybe possibly see yourself or somebody you know, writing one of the other chapters that we still have a writer for. So it's an open source project. We're going to hit a milestone and we're going to lease what we got and we're going to keep moving forward. So then a chapter on guiding participants and talk about, you know, what motivates people that's a preview chapter ready to go. And growing contributors, talking about what a contribution is, making sure that people really understand how we bring people into the contributors and governance and so forth. And these are all that, which is another preview chapter. So people can understand, you know, when you come into a project you can know how you get successful, how you progress forward in the project and so on. And the measuring success and so, you know, discussing metrics, what's how the community look like and then avoiding the pitfalls, you know. And in there we have some new content around community management, self-care, and then a place to talk about all these various wide stories that don't necessarily fit anywhere, that are modular, they can fit in various places. There are stories that illustrate several points and are useful to refer to from different parts of the book. So this is just really the way that this community has decided how to organize this information to get it out into the world. And we're using an ASCII Doc workflow, or ASCII Doc using a GitHub workflow. And primarily we started here, we went to GitHub because it's a place where a lot of potential contributors are and it's a tool that can allow us to do open source practice about having the discussions about the content stay with the content. So we're not having people hop all over the place, we can really have this kind of focus conversations like the way a code and patch management process might work. And our best practices as a community or what we recommend to people is, you know, taking care of being locked into platforms and so forth. And so it's something that we'll always keep on mind is, you know, it's not that we're tying ourselves to GitHub as the only way to do things, it's how we're getting this next version of the guide out. Well, as a community, everyone will, we've continued to review what tools we use and where we host and so forth. So this is just us being both pragmatic and following our own advice, which is to be pragmatic and follow our own advice. It's a recursive thing, you got to love it. I'm going to skip this, we'll go look at the GitHub repo later. And then in general, aside from what's happening in the GitHub repo, we have some meta discussions on the form and mailing list. It's pretty light right now because we're really focusing in on the book and those things are about that. But it's become pretty obvious that we're, you know, that we became obvious in the last number of months that we've really got a community of practice here. And we do have content that's come into the community that may not directly fit into this guide and we're looking at this, how we can be growing in knowledge based stories and best practices that right now, for example, where those of us in Red Hat's open source program office when we work on materials that we think could fit into the upstream or fill a hole here, we work on those materials in a way that they can go get be directly upstream so that they may be there a white paper or I don't know exactly what's the best term for it now but just some two pager that explains like the basics of open source governance may have, would have its origins in a much longer piece up in the open source way about open source governance and those things have got a direct correlation. Move content upstream and downstream, it's different than code because of the way that ideas get conveyed and style and so forth comes along. So we're trying to learn how to work with that in a sort of new way. This is a screenshot of what the mailing list is like. So where it lists dot the opensourceway.org can type all this stuff in if it really helps what we're using. We're using, so we're using mailman three which has a web interface. So you can use your email interface or the web form interface. It works really smooth. I'm super happy with it. I go back and forth all the time. Sometimes I'll type one, you know, literally in the same discussion over a time of the period. So right now what we've got is a project, project dynamic of us trying to focusing on getting the content done and then, and I'll touch upon this a little bit, but the goal is to mix up and shake up, you know, kind of blow up the governance, do something different. Do the people who've come along and created the book will decide what the governance is. But for now I'm the project lead and it's just in, I'm just keeping this thing moving. That's the main thing I do and I'm writing some stuff and I'm editing and so forth. Brian Profit is our lead editor and I'm really rely upon his expertise and focus on good pragmatic editing and definitely helps keep me in, steer on the right path. Sean McCance is our lead writer and he gets to work with writers especially in the development phase if they need somebody to work with and help think through the content and then also tooling and how to get things done. So we've got someone who's there with you while you're developing content and someone who's there with you while your content's being edited. And then the team of us all support each other in that. So I might be working with you directly as your editor slash co-writer person to help you out or it might be Sean or it might be Brian or it might be Brian or so forth. And then we've got a growing writing team. Some of the chapters I mentioned earlier Gordon Half was the author on the intrinsic value and contributions chapter and Ashley Nicholson, Ray Pike, working on content around community management self-care and metrics and so forth. So we're getting, it's a great way to track some of the answers here. Work on this chunk of something that you have some interest around and then helps, it's a great way of pulling people into the community. So we're having really good mad conversations. And just really quickly so you can have an idea of what it's like to, what it takes to, if you've got interested in working on this content, you go into GitHub and there's an issue related to each chapter and I said we can look at this in a few minutes. So each chapter is an issue assigned to it. So all the content and work just happens in that issue. And you can just, you go into that issue and you put in your suggestion for an outline. If you need to discuss bigger ideas and stuff with the mailing list is there for you as well. Once your outline is approved, one of the editors says, well, it's great. Let's go forth. Then you work on the content via the Git repo. You use your own editor and so forth working in ASCII doc. And then it moves through the process and there's basically a pull request that happens at each step. So first you get your initial outline or your initial draft just is pulled into the main branch and then as each editors move things along choosing who has the pen from draft review to developer review and subject matter review and so forth. We deal pull request process. So we've got a chance to track the discussion around that, that each step and so forth. So there's a two, I was gonna say to a large degree, to a very large degree. We are making up the process of how we are writing content and work flowing it by mapping and editorial work publishing process on top of GitHub. And it so happens that the open organization is working on a book at the same time, using the same process. We've got several people in common across this two groups. So we're sharing, doing type knowledge sharing. As a group there are farther along in terms of their experience of creating books. They've worked as a group and they're on their sixth or eighth book by now, something like that. But we're all brand new at working on the stuff in GitHub. So once we're done here, there will be something to do to help teach people about how you can use GitHub to do this. And I've got to finish up because I promised myself I wasn't gonna talk for more than 10 minutes. It looks like I might be already getting into 15. So we're working on the editing workflow. We're basically creating things a little bit as we go. September, a preview release coming 2.0, release in December. I mentioned that the governance, we're gonna be blowing that up. So as soon as we're done with the book roll, the community will decide for itself what it thinks. And I'm gonna leave this slide up for right now and I'm gonna stop tacking. And I'm looking to see if there's any questions that have come up in chat and just open up and just open up for some conversation. And I'm also gonna pull up the GitHub repo so I can show you actually, I'm gonna switch over to that. What the workflow looks like. So I have never really tried to compress all of that, that quickly in there, I might have skipped some bits. So let me know, does that make sense? What questions do folks have? What do you have interest in using content like this? Just as is like, hey, I can just point it to people and say, great, here's how you do it and why you do it. And is there any value in this content being something that you might pull into your organization and you might start like a quick primer from this content, be able to go and grab it, because we're trying to write it with a certain sense of modularity in mind, but we're definitely not there all the way. See if I can stop this screen share and switch my screen share to something else. Okay, great. I have a slightly difficult time figuring out the selecting my window and hopping to share. Which one is actually the, I guess the one just to add a title. Okay. I'm going to, I'm going to make it wide and then increase the font and it's a little bit. Yeah, okay. So what I wanted to show, which is for, which is another kind of interesting aspect of this, I think, which is really the workflow that we're doing. So we've set up a number of columns that define the stages of the workflow. So we have an outline that has a number of chapters, right? And each, yeah, I get confused with the terminology around section and chapter all the time. So I'm probably going to confuse that out. But if we look at the outline, which I can do up here in, I'll do my point of the outline itself, let's go. So each one of these areas, so introductions and tracking users, this is a chapter, I think in our parlance. I keep calling that a section, these sub things, a chapter and, or maybe they are chapters, I forget. But each one of these sub points is a unique item. Like why do people participate in open source? You know, that's a chapter basically. And when we come back over here in editorial, and this is, I'm going to go all the way to the right because that's one, a chapter that's, has been all the way through the other process and it's 100% complete. That's a good one. Let's go on today. Okay, there we go. And yeah, oh, it looks like the issue needs to be reopened. So, or maybe it's not, but the issue's closed. So there's a, what was my point with this? Yeah, so there's a direct correlation. Each one, there's an issue that's created for each of the items that's in the outline. And then that way, so the issue stays open until that, and that's why that issue is open. Or closed, excuse me, because the issue stays open until something is in, you know, is completed. Although it will close. I mean, if it closes, if the issue gets closed for any reason, we just reopen it. And then now I'm kind of using a mix of GitHub and publishing content here. So this is, I don't know how useful this is in terms of people's understanding what we're doing, but there's a piece of content that needs to be written. It's an introduction for a chapter on community fundamentals. You know, kind of the one-on-one of what a community is, right? And if I open up the full issue, pop over to it. It's a place that, it holds all the conversations in the comments and all the details about it and so forth, just like any other issue would have. We've got it marked against a milestone of 2.0 and it's got some labels. You know, it's saying that it's a chapter, saying that it's part of the editorial board and that it's introductory material as opposed to contributor-oriented material. So if we're, so this is a piece of material that's also to be assigned. So if you come in here or somebody comes in, it's fairly straightforward or clear once you decipher what's going on, that this column on the left is the material that's to be assigned. And you can look through and say, oh, here's something interesting. I'd like to write a section on guiding or a chapter on the types of participant contributions. You know, I know it's more than just code, right? So what is all of that and so forth. And it may be, and it may be that this is something that is written with several people who break it up into different parts and so forth. Excuse me, so there's a lot of opportunities to collaborate with people who are at different levels as well. Some people may, we were talking with somebody yesterday who might have some of their people who are new to open source go through and help create the content about new to open source. So that they're helping write something and contribute it into here that is from their direct experience right now with those of us who have a little more experience coming in and editing and helping fill in the blanks on it. So then once something has been assigned, there's, we have criteria for moving between each of these columns in order for a chapter, well, to move between the columns going from assigned to drafting and so forth. They're along in the way in here, there's going to be an actual file that's going to be brought in as a merger request, as a pull request by the author and this is going to be an ASCII doc file that's going to be the content of their, their first draft of their chapter. So they're in their drafting moment here. And when, so Ray, for example, is working on community metrics, that chapter is, oh, it is, I think by Monday is probably going to be ready to shift in, if not by the end of today. There was a little bit more stuff that was going to happen for it, I think, and then it'll be shifted over and that's going to be done by pull request. And when the pull request happens, you can see it's a link to pull request, which is the update for it. Once that's all done, the, it will close the issue, which will then reopen. That's just one of the side effects of this. And it'll move over to the draft review column, which means that it's ready for an editor to go in and kind of take the pen and make a draft review. And here's what, you know, here's what, does this draft got all of the basics to be a chapter? Or there are big sections that say to be written, in which case we say, you know what, this isn't really a draft, it's pre-drafting. Why don't you take it back and finish this first? Once we've confirmed that it's got the same stuff, the editor makes a pull request and it gets moved to the development edit and so forth. Development edit is really going through and saying, should this section be here? Is there a section missing? Can you do some figures to describe this? You know, it's really thinking and help develop the chapter to be at another level. We have subject matter expert reviews, which you would do in any time when we have something significant. In this case, we have two or three chapters that I think are, can really do reviews from outside of the subject matter experts that are part of this community already. Much of this content, we are the subject matter experts kind of, so we might as well just, you know, we don't have to go too far. But everything's read by a couple of editors to make sure that it all gets through that new level. And in this whole process, we really are learning about how we want to manage content and think about things as a community of practice. So just in the, for example, yesterday, we had a discussion about the metrics chapter and the Chaos Foundation, I believe is the right, C-H-A-O-S-S, is a group that's working on real details around community metrics. And we share some people who work on this project, also work in that. But there seems to be like, there must be some delineations between, obviously we have some things to say about metrics. And so our chapter here is focused on things like, the kinds of things you would do if you were going to evaluate a project and find out how you would decide what metrics to track for that project, right? And that seems to me like it might be a reasonable thing for this community as a community of practice to say, we're gonna help you with the practice of figuring out what you wanna track for your community. And once you get an idea what the five or 10 or dozen things are, this community over here really has got all the stuff to get deeper into that. Thank you, Ruth. And so these are amorphous things that are really only, when I referred earlier about the evolution in the last 10 years, these are the kinds of things that have evolved. And 10 years ago, there wasn't even a single place to have all of these discussions really. And we tried to do that and it really wasn't kind of ripe for that. We had some material there, it was good. But this clearly takes things to a different level. So these are the things that we're sort of discovering as we're creating this stuff. And we can have that, okay, great. Next year, we'll think about that. Right now, we know we're doing the right thing by writing this content. It seems to fit into our process really nicely. And another, the standard copy edit, make sure everything's really clean and to bring it out. So there are several chapters in here. I'm gonna click on the preview chapter tag. And so you can see that we have several chapters in here that we're planning to bring out in the preview release. And as long as everything, yeah, so it's just bringing those things over the, it's just like with any community, getting yourselves to the next point, making that decision and saying, okay, we're gonna do this and we're gonna push forward and make that particular thing happen. Get it over the finish line. I would like a better metaphor than that, but that's what occurs to me. So in all of this, and I just wanna refer back around to something that I think that has come up a lot that is a really strong interest to me personally and to those of us working on the project I think as well, is that we've sort of designed for ourselves to a degree what we think it was like, what we could think of as the perfect upstream community for us to place all of this, how you do open source stuff knowledge. And by perfect, it doesn't just mean perfect for everyone at Red Hat, because what we know from our experience is that working with a community that is diverse from many perspectives, the people in it come from many different backgrounds, have many different life experiences, don't look like each other, don't act like each other and they're organizationally diverse. So organizations of different types and size coming in and bringing their perspective on how we do things, it's a really important way to actually, I've had these ideas that do the best in circumstances, lift to the top, the best ideas thing. And so for us, we would know like if we just created something that was really Red Hat centric, we would be cutting off the blood supply, the oxygen for that to be able to grow to be something even bigger. And which would then benefit us even more, right? I mean, it's this perfectly selfish thing. Again, that perfect word, right? So, and part of this is because it's gonna be modular, it has to be to fit the needs of the community of folks who come along for this. And by modular, what I mean is again, referring back to what our open source program office does, we've got some materials that we could point to that are out on redhat.com that talk about like the governance is a good example that comes to mind right away. Where the source material is here in the open source way, the chapter written by several of our community architects, longstanding experience people, that same content is now that that's the upstream for this content that is put out under the redhat brand and spoken that way. And there's a direct, I don't know exactly what's the right word here, but there's a direct relationship between those particular pieces. And it may not even be that when you look at one and the other you say, oh, you know, because we don't wanna set off any plagiarism alarms or anything too, I guess, right? I don't know, we're exploring this as a whole new experience of how do you, like how do you do things right and not ruin your search engine optimization, I guess. So, and the expectation is that if we find this to be useful, you might find it to be useful. It may be that for your organization, you've got, you bring in 100 new developers every year who are brand new to open source. And if you could have, if you could create your own comic book or super tight book that just so showed the 10 things you need to know to get started and you give that to every new hire orientation and the two months later you came along with the 25 more things you need to know or whatever. And the source for all of that comes from the open source way. So you're not having to go and create the material manually yourself. You're not having to like to double check, is this really the right way to do it? Should we be doing that? And then really importantly, you've got that source of the reasons why. But because what resonates with other people, I think it bears out is having hands-on experience with something or that vicariousness like, oh, why did you do that? How did that happen? Like, oh, that was terrible. Oh, no wonder you do it that way. Yeah, let's make sure that doesn't happen again. Oh, what a wonderful outcome because you did it that way. We'll make sure we do that and learn from that. And then come back and tell you how it was and see if there's something better that comes in. So that's the best thing to me about a community of practices that it's a conversation that's ongoing. And it's a way of capturing that conversation that's meaningful to the people involved in it and meaningful potentially to people who are outside of it. I think that was all the stuff that I had in my mind that I wanted to really get out there one way or the other whether it comes up or not. What are questions and stuff do people have? Or does anybody wanna come in on Mike and ask questions or still anything in chat? If I'm not missing anything. Anything else interesting to show here? All the issues, I'm gonna stop sharing. Okay, well then that says to me that we are done with our engagement and it is time for us to move on to the next cool thing. So how about that? I will get done now and I'll hang out somewhere. I think there's somewhere I can go and hang out for a breakout session for a little bit. And I'm also in the newcomer booth, or should be, I'll make sure I'm back in the newcomer booth in the Expo hall. And we can, on my way out here, I will throw up my, I'll throw up that slides. It should be the right one, right? Yeah. No, that's not the right one. I want it, I'll throw this up so it's on the screen. Oh, I lost it, it's gone. I lost the popover, it disappeared on me. Oh well. Yeah, it's a bad hit. Well thanks everybody, have a good rest of the conference. Hope to see you at the trivia at the end of the day. And something I said today makes it into the trivia because then it'll be at least one question that get right. Bye.