Building Successful Online Communities

Matthew Revell: Hello and welcome to the first DevRel Book Club. My name is Matthew Revell. I work as a consultant at Hoopy doing developer relations things, and Ramon Huidobro is with me as well. Hi, Ramon. How are you doing?

Carmen Huidobro: I'm great, thanks Matt. Hey, everybody. Great to be here. And yeah, cover some books that we're going to be reading together.

Matthew Revell: Yeah. So let's just, first off, where in the world are you right now, Ramon?

Carmen Huidobro: Oh, I am tuning in from Vienna in Austria.

Matthew Revell: Awesome. And I'm in Shophire in England. So we essentially, let's introduce what we're going to do, because right now this is a live stream. Let me check that. It's going out live. It is. It's working. And we are doing the DevRel Book Club. The whole point behind this is that there are lots of different disciplined professions, areas of study that feed into developer relations. And those areas of interest often have really great books written about them that can feed into what we do as developer relations professionals. Now, there are books about derel itself, but we thought we'd take a look at some of those books that aren't necessarily obvious as Dere books, but that someone from DevRel has found useful. And we are going to have a chat with a different person each week. But the important thing as well is that there's a community aspect to this as well. So Ramon, why don't you tell us about that?

Carmen Huidobro: Absolutely. So not only is this is going out as both a podcast and a live stream. So folks, if you are on live developer relations.com, you can join in via the Discord chat that's below the stream itself. Yes, under us. And ask your questions, chime in. If you've read the book before, I want to be very clear on that when you're attending these or when you're listening to this podcast, you do not need to have read the book in advance. It helps of course, but this is also an incentive to introduce folks to those books and incentivize a conversation. So much so that we'll actually be hosting a series of conversations on the developer relations discord, again, which you see below us where we can come in and have a chat having read the book, which will take place in about a month's time from today, today being Wednesday 19th of January.

Matthew Revell: And we'll provide updates on that. And the best way to get those updates is to follow @_devrel on Twitter or myself or Ramon, or to follow the derel newsletter, which you can get at newsletter. Do developer relations.com. Should we get started with our first edition?

Carmen Huidobro: Yes,

Matthew Revell: Let's bring in our first guest.

Carmen Huidobro: Hello.

Matthew Revell: Hello. How are you doing?

Joe Nash: Hey, wonderful and excited. Thank you so much for having me. Great to see you both. I'm so glad. This is a thing.

Matthew Revell: Me too. Yeah, thanks for joining us for our first one. Where are you calling in from, Joe?

Joe Nash: I'm calling in from Amsterdam in the Netherlands, not Holland, as I insists on calling it. Yeah, it's wonderful. And rainy and wet today.

Matthew Revell: Sounds about right. Okay, cool. Well, so let's dive right in. So for this first edition of the DevRel Book Club, we are going to be looking at a book published by MIT press in about 2011. So a fair wack ago in terms of time called Building Successful Online Communities Evidence-Based Social Design. And I want to emphasise that before we do get into it, that this is a book that, as I say, it was published 11 years ago, but actually comes out of work from 2006. So that does kind of influenced some of the things that are in the book. But Joe, can you just tell us to begin with why you selected this book for the book club?

Joe Nash: Yeah, for sure. So I, in my work do a lot of things with developer communities and particularly designing and creating novel communities for particularly interesting audiences. And when you are thinking about how community serve its members, there's lots of decisions to make. There's lots of choices about that, not just in terms of online platforms, but the capabilities of the community, what the community members are doing, et cetera. This book is as close as you can get to a community recipe book as if you think of there's the O'Reilly books between Hey, here's the book that teaches you Python, and then there's the Python cookbook. It's like this is one of those cookbooks. You can just open this up, go to a section, a chapter about the problem you're currently facing, and then it would just have a bunch of what they call design claims, which we'll get into, which are statements of fact backed up by research. And you just find the one that addresses the problem you want and you have a solution. And so this book has been super useful to me throughout my time building developer communities. One thing that I know we're going to talk about is, and as you've already drawn on this book, the title is Evidence-Based Social Design. This book is with a heavy academic backing. Every claim it makes is backed up by some research. Every chapter ends with a terrifyingly long bibliography. There is nothing anecdotal about the claims in this book. So it's all backed up by things you can go and read and learn more about. So it's super useful.

Carmen Huidobro: I'd love to share a story if I may. I've shared at DevRelCon, so I'll be sharing it again. When I was starting out at my first DevRel position, Joe, you very kindly sat me down and suggested some resources for me. I was nervous about getting started in DevRel, especially as education is one of the things that I really want to focus on. And one of the books that you recommended, one of the resources you recommended was this very one, and this was about a year ago. And I've been thinking a lot about since then because coming into this podcast, which is a lot of books that are important to read as someone in dre, but also not something you would usually find at the top of a reading list per se, I find it so interesting that education, but also the research side of it is so key to this and this is what's really fascinating about it.

Matthew Revell: So I mean that's something that we touched on in our pre podcast chats were that this is not a business book as we've come to understand them. I think that's really crucial to understanding the utility of this book is that it's not taking you on a nice journey towards a conclusion that the author wants you to agree with and that you have to buy into every piece along the way. And something you said, Joe, was that it's not something where it challenges research, it basically presents some things to help your thinking. It's not trying to make you think a thing.

Joe Nash: Yes. And they actually have a section. So the first chapter is basically instructions on how to use the book or how the book works, but it's actually a really interesting section of that chapter which gets into the morality of designing a community because when we talk about a community as a sets of things that the community can engage with and we want to incentivize them to engage with and do certain things. So for example, the book looks at Wikipedia a lot and how you encourage contributions to Wikipedia, what you are kind of essentially talking about there is like, Hey, how do we design this community to manipulate people into the behaviours we want? So it gets into the morality of that, but one of the things they end that section on is like, hey, they don't, as the authors ascribe any particular morality to what you as the community designer are trying to do or how you use any of the claims, that's very much up to you. And there are some particular claims in here that I think pointing out this book is from 2011 that history has shown maybe these aren't good design choices and state of the arts moved along. But as a reader of this book, it's very much a set of tools and it's up to you to inspect how you would use those tools in your work and decide which tool is appropriate, but lacks all of the opinion and thought leadership and agenda I guess. So it's applicable to a lot of things to the extent there isn't an agenda, actually do want to brief touch on this, it was again, something they touch on. The authors have come into this very much with the goal of bringing insights from social scientists, social science into these discussions of online community. They are actively trying to merge these two disciplines in the book. And where it's interesting and why, I think even though it's quite old, it's relevant to us, the online communities of the time that were really popular, they are looking at communities that are parallels, were parallels then of communities we all rely on now. For example, they touch on Source Forge a lot. Obviously no one uses Source Forge now, but a lot of the things that are true for there are true for GitHub. They touch on q and a communities, which true things like Stack Overflow, et cetera. So there were parallels to what we're currently using that they are bringing insights to.

Matthew Revell: So Joe, I'd like to ask, what have been some of the highlights from this book that have really influenced or informed your career and your work?

Joe Nash: Yeah, so I'm going to start with some high level things, which I think the structure of this book actually in itself is really, really useful. So even if you don't have time to read this book, read chapter one, and the reason it's really useful is the way of thinking about designing a community. So they basically lay out what they call the design alternatives of the community. So the different, what they refer to as levers, the different areas of community design that you can influence as a community designer. So let's run down that list. So those are the structure of the community, the content tasks and activities, the selection, sorting and highlighting basically the curation of the content, I guess you could say the external communication, the feedback and rewards, the roles, rules, policies and procedures, access controls and the presentations and framing. And even just at a basis, communities are a complicated multifaceted thing and part of designing any system is understanding the systems inputs and outputs and just having them break that out and discuss again in the starting chapter what each of those things mean. How each of those things affects the community and what they're shaped by. That in itself I think is super influential. And then for me, some other highlights, and this is so we've all spoken about, I have this big thing that I just find fascinating, which is people in professional context absorb truisms and it's sometimes really hard to figure out where those come from. So my favourite example I always say for this is for some reason everyone knows that 30% open rate on newsletter is good. And I cannot tell you why it's good or why we've decided that figure or where that's come from. This book because of the research backing is just absolutely amazing at exposing a lot of those tourisms. You'll be reading this book and you'll be like, oh, that's something that I knew and felt obvious. I knew it to be true. I've heard it from someone, I've learned it and I've never inspected that. I've never thought about where that's come from and suddenly here's the paper that originally came from that is something that's infinitely valuable. And I know you both of you spoke to that as well.

Carmen Huidobro: Absolute. Sorry.

Matthew Revell: No, go ahead.

Carmen Huidobro: I was just going to say this is something that surprised me to sort of stay on that topic just for a second. What I love about this book is that it feels like for somebody like me, I don't read a lot of academic work.

Joe Nash: This

Carmen Huidobro: Was one of the first academic works that I've read. And it felt that it was structured in such a way that I could do that in bite-sized ways so that I could see myself, especially with this design of having the structure of having these design claims to say, Hey, these are structured parts of like you said, truisms and being able, as you said, to sort of realise, Hey, I know this. And then wonder, hold on, I don't know why I know this.

Joe Nash: And

Carmen Huidobro: Then having the research there to show why this is commonly accepted. It almost feels like a glossary that I can pick up every now and then and hop around, say if because it's divided into six chapters that go over different parts of what it's like to be in a community, be it for example, starting a new community, enforcing rules in a community, this sort of thing. You can sort of hop around there and find something that relates to that and say, this is why we're doing this the way it is.

Matthew Revell: And specifically there are these design claims that come up in the book, and maybe this is going to be awkward, but if I hold up, you can see that there are these various design claims that are in the book that Joe mentioned

Joe Nash: For the podcast. Listen, let's just quickly read out that one in particular as an example. The chapter two one. Yeah, so this is the, and again, they explain these design claims and there's a whole sciencey reason they formatted them how they have. But so they'll say like design claim 11 people will be more likely to comply with requests if they come from others who are familiar with them, similar to them are attractive or of high status or have other notable socially desirable characteristics. And so these design claims would just be a statement of, well fact, I don't think there was any design claims they state that turn out not to be true, but they are a statement and then the following section gets into the research that proves that claim.

Matthew Revell: No, I mean if we're going to talk about this one now, let's talk about this one because I think this is interesting when you say that they're not presented with any kind of morality and that design claim in 2022 is when I reread this book for the purposes of doing this, that was quite jarring because we see in our work as developer relations that developer communities that are homogenous tend to, well this send into infighting or are less effective. And actually what we are striving for is more diversity. And so you look at something like design claim 11, and this goes back to the point that this isn't a manual for how to do things. It's a reference to give you some thinking points about how you might design a community.

Joe Nash: It's also interesting in that they were like, this is a good design claim that I think will mean different things, different readers, or could be perceived differently by different readers or people. It means multiple things, right? Like hey, people are going to listen to people. Basically it's saying people are going to listen to people like them and that for one point makes the argument for Homogenity, is that how you say that word? Homogeneity or whatever. On the other hand, it's what we now know to be true, which is like, hey, you want your community to be representatives so everyone can see themselves in it. And what you're saying about the book Ascribes, nom Morality, even the example they give with this is actually kind of jarring, which is it's something like, hey, you can manipulate voters if those voters by having people who look like politicians speak for the political parties or something. So even when they give, even on the research they're drawing on, some of that research is proving harms, but it comes opinionated in this book and that has ups and downs. But again, I think the book does a very good job of addressing upfront that you are going to make moral choices in as you apply this and inspect those choices as you do it. I want to go back to something Ramon said, which was that as being a glossary, actually one of the really great things that again we come into our discussion before that I think really differentiate when we say this is not a business book. I think one of the biggest ways that comes into play is usually when I read archetypical business books, I feel like they're designed to be read front to back. And usually you'll get through 300 pages and you'll, you've got to work quite hard to ring out the core nuggets of insight.

Matthew Revell: This you've got five pages of insight out of 300 pages of

Joe Nash: Exactly. And there's a lot of pros, there's a lot of personal stories, there's some value to that kind of stuff. But what this book is really good at is really good as a random access book. Again, you hit a problem live, you're currently working in the community, a problem comes up, you flick to the chapter and you're there. You don't have to read it all in one go it, it's great and very enjoyable, but the format of the book is not really conducive to doing that. And on the glossary point in particular, one of the really great things that even now makes this book stand up is it links because it provides all that research. It has the big biography. If you want to go check how in the 10 years that have occurred, whether there's been any evolution on that research on that point, you can just go plug that paper into Google Scholar and look at the most recent citations and see how the, it's like a gateway into the social science research of online communities. And so even being an out of date book out of date, I mean I think there's some areas that's more out of date than others, but even if you think it's out of date, it equips you with the tools to go and update the knowledge where you need to

Matthew Revell: In the discord. Juan Pablo says he wonders how much things have changed for online community since 2011. So back then we were all using PHP BB forums, I remember doing it myself and now it's Slack, discord or Stack Overflow even. And does the Gathering place influence the social science behind this or is this book still applicable, do you think?

Joe Nash: I think it's very broadly still applicable, but it requires more interpretation and more in the same way that we're saying, Hey, you can't just assume these design claims are good things. You can't just assume that they will work in your format. And again, you actually mentioned the forum aspect is a really good one. Slack alikes, instant messenger things separate by channels aside from IRC and they do do some IRC communities in here, but broadly the shape of online platforms that are now really popular just didn't exist. And so one of my favourite, and this isn't from the book This's, just a general thing, one of the truisms from forums that has stuck around that I don't agree with is that when you first start a forum, you should have relatively few spaces because empty channels are bad. They make people feel like nothing's going on and they don't want to participate. I actually think that doesn't work insight like Discord because of the notification model. If you have one small channel where people don't want notifications, so they mute the whole discord, whereas if you have lots of channels divided by topic, it's easy for 'em to subscribe to the topics they want because in Discord you'll subscribe to everything by default. So that's a prime example where you absorb that truism and you're like, my Discord only needs one channel, and then your engagement drops off Cliff because it's too noisy and people can't make their notifications granular. So those are the kinds of things where because it provides the research, it also provides the reasoning and you need to follow through and think about how that reasoning applies to what might be different now. So I think it is still very applicable, but you can't just read the design claim and say, cool job done. You need to inspect why that's true and apply that to your current situation. And also, as I said, it does pretty much every platform of today. It will have looked at some equivalent. There is IOC in there, there is Source Forge in there, there is q and a platforms in there. It does have a whole chapter of reputation systems. If you want to talk about Stack Overflow for example, you just might have to work hard to find the link to what you are most looking for, what you're using.

Matthew Revell: Yes. Let's, sorry, Ramon, you go ahead.

Carmen Huidobro: Oh, sorry. I wanted to add to that because I think what's really fascinating about the time, the timeliness of that book that it was published in 2011 is the fact that a lot of things that we have now and or take for granted. For example, one of the design claims that really stood out to me in chapter four, which is about regulating behaviour in online communities. I'm just going to read it real quick, publicly contrasting examples of inappropriate behaviour in the context of a descriptive norm of appropriate behaviour, highlight the descriptive norm and increase people's adherence to it. This to me reminds me of something that's very common nowadays, which is the code of conduct. Having a code of conduct is something that is applicable to hopefully all communities and is something that we see so commonly that when we see a design claim like this, we think, well, this book doesn't make any mention of codes of conduct because codes of conduct as they exist today didn't exist back then.

Matthew Revell: Well that's interesting because I'm old, right? And if I think back when this book was originally being, the research this was being put together in 2006 was the time when certainly the open source community, it could be very hostile to nos. Anyone who dead ask a question without spending three weeks searching for the answer themselves would be flamed out of existence and never want to have anything to with that project again. And when the Ubuntu community started out, one of the first things they did was to create a code of conduct, the specific aim of which was to discourage and regulate out that kind of behaviour. And so I do think we're fortunate. I know that there were lots of people in some of the old guard in the open source community were really angry about codes of conduct and so on. But it stopped being a bunch of people who all knew each other socially and became a worldwide movement that had to take on other rules. And I think we're lucky now that we do for the most part, not entirely, but for the most part, we are able to join communities that have codes of conduct that mean that we can focus on the interactions that we're having rather than Being worried.

Joe Nash: Yeah. One thing I'll say about, which I think is actually advantageous about this book not having the language of code of conduct, is that the ubiquity of code of conduct, it's an abstraction, right? Like codified, basically we have codified all the design claims that this book is making about regulating behaviour into this one universal thing that's called a code of conduct. And one of the implications of that, which code of conduct proponents commonly struggle with is people adopting code of conduct about reading them or understanding them or thinking about enforcement thinking, Hey, I've got a code of conduct, I can apply it. And if you read through these design claims, even knowing about code of conducts, now again, it exposes the truisms. It lets you know why that tool works. What you just said about the why you saw code of conducts in this, the contrasting of behaviour is like, Hey, why does that have the psychological effect? Why does listing these things explicitly in the code of conduct help in that way? It actually explains the code of conducts that we use nowadays. So even in the absences of tools we have now, I think it serves in that way.

And I was going to say something to what you said about you. Oh yeah, the point you're making about some of the communities being harmful there. There was another design claim that you called out, which I think is a really good one to that. Do you remember which one it was? Some of these design claims, I think that'd be fun. But this one I think is a good one.

Yeah. Chapter five, design Claim 16 requiring potential members to provide referrals from existing ones, screens out some undesirable members. And I think that is a really good example of the moral choices of design. What was your first reaction to this claim when you read it, Matthew?

Matthew Revell: Well, it really concerned me because for a beginning to begin with, you're immediately marking a whole group of people as undesirable, and I think that's problematic, but also there's this idea that if you only let people in when they already know someone, you have two major effects. One is that you are reinforcing the culture that's there already, which could actually end up reinforcing the bad aspects of that culture rather than the good parts. The second is well related to that, that you are immediately cutting off anyone who isn't part of the ingroup. And so that reinforces structural access problems and so on. And so to me, again, I keep looking at these design claims through the lens of they're not making a moral judgement . They're just saying this is something and here's some research that backs it up. But I think you do have to take some of these design claims with a view of, I really need to put my own judgement on this for how it will impact what I want to do.

Joe Nash: Yeah, for sure. And again, as with the one about the sorts, the kinds of people that people listen to, the earlier claim design claim 11, this is one where again, if you apply it to the developer community at large, clearly negative consequences if you apply it to affinity groups, having known quantities and referrals and vetting is a huge aspect of safety for groups around particular disabilities or around particular identities that's really well used. But actually I think there's a modern really contemporary example of both how this works very well and how it works very poorly in Clubhouse. The theory were not Encounter Clubhouse, it was an audio, it's the app that is the reason why every app in the world has audio stages now. It was an audio only social network initially. It grew by having, you had to have a referral from someone to get into it. And it did some things really well on that regard that speak to this design claim. So again, the claim here in particular is about these referrals, screen out undesirable members and what undesirable means one thing or another. But let's pretend for the sake of our argument. So we want to get rid of the normal bad actors in the community and trolls and stuff. Clubhouse referrals had a really interesting, well, they had two really interesting mechanisms. One of them was that when you referred someone, you were visible on their profile as the referrer, which really discouraged inviting people who you thought were not going to be positive contributions to that community. If you were the person who invited a troll in, everyone can see you did that, right? And that's horrible. That's not a good feeling for anyone. If you are the person referring people, suddenly you've got a lot of calculus to do about whether you invite people. And that speaks to all the things you said, Matthew, but I would argue it worked. But here comes the core thing you said. It worked in reinforcing the community they wanted, which was primarily those centred around a certain type of VC culture in the valley, and that's the community they ended up with. The other aspect, this, which speaks for another design claim that was really interesting is it's actually the next page in the book. So it's on 2 0 5. They get into initiation rituals. And this is the other thing that Clubhouse did really well, which was like if you referred someone, you were responsible for that onboarding. You were meant to create the first chat with them, run through them how the app worked, run through the social norms with them, run through what it meant to raise your hands and ask to be on stage or this kind of thing. And I'd never seen a social network before that had that much structure around members, onboarding other members. And that was really interesting to me. And again, speaking to the morality, those are both positive decisions that would be by this book, they would be exactly as the book said, they should be used. They were effective in producing the community as designed. And that is not a community that I would be happy to participate in still. Right.

Matthew Revell: So I'm wondering if that was by design or if it was outsourcing community management to the community. It's interesting because some of this can be accidental,

Joe Nash: Which I actually also think is a design claim actually in there that I think you commented on earlier, man, that there is design claims in here about scaling community via using community activity. Yes.

Matthew Revell: So Ramon, I know that you have a lot of bookmarks or post-it notes throughout the book. What I do want to do eventually is get on to just talking about the chapter headings because I think for people who are new to this book, it'd be good to go through those. Before we do that though, Ramon, do you want to raise some of the things that caught your eye?

Carmen Huidobro: Sure, yeah. I think for me, mostly these conversations about, especially going back to what we said at the beginning, what I said, what we were talking about at the beginning about this being a glossary, that a random access book that you could come to. What I find interesting about it is that I can come to it at different stages of my community work. For example, right now in my job at code C, I'm working on building a community. So the chapter six, starting a new community from scratch really stood out to me about things that I could do. For example, how to respond to feedback, how to do that too much to, I think it was design claim. Yes, chapter five. Let me just go there real quick. Chapter five, design claim 11. Let me bring that up real quick. Sorry. What I found interesting about these is that they could be something that I could refer to at several points during my career that could still help me. Even though as we've been saying, it's something that's quite abstracted needs, placing the right context and understanding too. So here we go. Providing potential new members with an accurate and complete picture of what the member's experience will be once they join, increases the fit of those who join. And I think this is something that we were talking about before when it comes to, and here's my guess at the pronunciation of the word homogeneity and how that plays a part, because what you were saying before was that by giving everybody an idea of what to expect and then reinforcing that based on the members who join in, what happens when somebody who doesn't fit that norm joins? How much do you respond as someone who wants to provide an inclusive adaptive environment, how much do you change and how do you do that both responsibly and directly so that you don't affect the overall, let's say, health of the community is a question I found myself asking.

Joe Nash: Yeah, yeah. I think one of the things I really appreciate about some of the claims in the book is this one in particular. I think the challenge your thoughts on this kind of gets to this is I find, and I've spoken before about how I think the strongest incarnation of community, and I mean S strong as in it builds a resilient community where people return that have high engagement, it's going to have good growth, is one where everyone is aligned on the purpose of the community and the problem that community is solving. And so when you say, Hey, a community member has landed here who is not a good fit. There's lots of things that can mean, it can mean they are not fitting in with the expected etiquette of the community, or they're breaking rules or they have a problem that's not their problem, isn't the one that the community's trying to solve, but they're trying to use this as a place to address their own problems. And depending on which of those you're addressing, I think you react, your tools for reacting are very different. Obviously if they're breaking the rules, then you don't try and accommodate them of, but it's really interesting to think about, Hey, we're a community servicing X people with Y problem and someone's rocked in with Z. To what extent is this the right place for them? To what extent do we send them somewhere else? To what extent do we just say like, Hey, this isn't the place, this question. And I think that's in our profession, especially now bringing us all back to Devra, I think that's something that a lot of Devra communities really struggle with because a lot of us are employed to build communities for employers as a audience generation tool. And so we want to be maximumly inclusive to bring as many people in as we can to contact the most people. But that is contrary to often contrary to the needs of the community and is the design claims in this book shows that doesn't work for a broad s swat of cases.

Carmen Huidobro: And it kind of speaks to that, again, that question of morality, how do you apply it is up to you, it's presenting effect and sort of like now I've given you the responsibility to do with it as you see fit, which I find really strong. Could I maybe point out another one that I

Joe Nash: Found? Please? Yes. Yeah, go for it.

Carmen Huidobro: One that I faced, this was, so 2021 was my first year in DevRel, which also meant it was my first Hacktoberfest and CodeSee participated in that. And one thing that I found quite interesting was the question that came from chapter two, design claim 26, which I'll read out rewards that are task contingent, but not performance contingent lead to members gaming the system by performing the tasks with low effort. And in case you're not aware, if you're listening and you're wondering what's Hacktoberfest? Hacktoberfest is an event that takes place every year to encourage folks to get into open source, make some open source contributions, and get a free T-shirt out of it or any kind of other event. I think they're planting trees if you like now too, which is awesome. And there was a problem, I believe in 2020 or 2019, I've lost track of time where a lot of people started making, let's say less effective contributions to open source. And that started

Matthew Revell: And there were YouTube videos showing people how to game it and that kind of thing. I mean, it really became a thing.

Carmen Huidobro: And so when I read this design claim, you brought up something really, really interesting, Joe, in our preamble before this recording where you said that makes sense, but performance contingent is hard to scale equitably.

Joe Nash: And

Carmen Huidobro: I would love to give you a chance to elaborate that if I may ask.

Joe Nash: Yeah, I'm sad. We had a particular viewer who now looks after a programme, which definitely I know has struggles with this one. But yeah, I mean I have experienced this firsthand in I guess the community that got me into doing this, which was gay campus experts. We had a gap. Campus experts is a student ambassador programme essentially. And part of the allure and the benefit of ambassador programmes is some level of exclusivity. You want people in the programme to feel special and also the resources limited, so you can't let everyone in. So campus experts was fronted by a training programme, and the initial intention there was they're students, we don't want to require skills. We want them to build those skills and become the ideal candidates. So we had a really wide open, and actually I spoke about this in Dev 2017 about how all this worked, but we ran into this problem where we had this training and I did not expect to have to roll out a plagiarism checker for those exercises. I actually ended up using Harvard's open source plagiarism checker on the exercises because we had a lot of task contingent exercises in the training platform. But then we rotated this to be more performance contingent via requiring a lot of more subjective exercises. So we had students analyse their campus communities, for example, in kind of an essays format, something that was always going to be very individual and subjective, and we had other things similar to this. And we ended up in a space that was automateable where the queue for students getting their contributions checked was enormous. So it took a very long time for people to get into the programme. And this is arguably the biggest failure of my tenure as programme manager for that programme. And I think the book talks a lot about talks in the language of contributions where it just means anyone's input into a community, but it kind of talks about some of the indicators of quality here and how you detect counterfeits. But I think that's a two when we're talking about communities in the widespread of contributions that could exist, I think that's too limited. A, what does performance mean? What does high performing mean? Yeah, I think Wikipedia is actually, again, a really interesting one to look at here. Look how many editors Wikipedia has and how hard it is to how much work they put in making sure that Wikipedia isn't vandalised. Yeah, very. This is one that I think is really core to how a lot of us operate because almost all of us, again, because we're trying to grow big communities, we incentivize things, and the minute you do that, you arguably ruin them because this design claim,

Carmen Huidobro: Yeah, thank you for sharing that.

Matthew Revell: This book isn't just about developer communities by any means. Okay. No, the open source desktops in there. And

Joe Nash: So it's ravelry, the crochet community,

Matthew Revell: Right? Yeah. And you mentioned Wikipedia as well, which is kind of sort of halfway between the two.

Carmen Huidobro: I believe World of Warcraft was there too.

Matthew Revell: Yeah, yeah, absolutely. Yeah. And then there's things about online health and so on, but I often think that we have, and I say we in the loosest possible sense to mean the DevRel industry has a sense of developer exceptionalism quite often where yes, where we think, well, okay, that's fine for your World of Warcraft or your yoga community or whatever. But we are developers, we are different. We do this for a living, being online and being social in that way. So Joe, is this generally applicable to what we do in DevRel, or would you say there are some caveats where perhaps developers would behave in a way that isn't covered by this book?

Joe Nash: I'm genuinely thinking, so my gut reaction to this is like, no, of course not. Developers are people. They act like people. The whole thing this book is trying to do is bring in social science research to prove the patterns and that our ape brains ultimately the same AP brains regardless of your profession. And so that's my gut reaction, and I think that's true. I think, again, where this is going to differ or where any given community member may react differently to a certain design claim is all down to incentives and motivations. And the big one, some of those communities you listed, if we're talking about the difference between, hey, someone on Ravelry who's trying to make a crochet piece versus someone on GitHub who's contributing to open to an open source project, both of those could be a hobby. One of those could be because it's your day job and then you're going to interact with that very differently. Those things are uniform. People do crochet for a living, people write code for a hobby. The important thing is to understand the context, understand why people are engaging with your community and what incentivizes them that will influence their behaviour. And this is currently an open source in particular. This is obviously a current big discussion about the difference between corporate open source maintainers and hobbyists. But if you are, onboarding is an area where I think this is really applicable. If I'm a hobbyist and I have limited time to engage in something that I'm doing for fun versus being paid for it, I'm probably going to be less willing to jump some hurdles than I might otherwise be. And so those are the kind of things where you want to be thinking about when you're thinking about, it's not just, oh, they're a developer, they're special snowflake. It's like, okay, who is this developer? Who are they working for? What scale? Where are they in their development journey? What scale company do they work at? Why are they, what's their motivation for coming to this community? What are they hoping to get out of this community? Those are going to be the questions that are far more useful than just like, oh, they know code, therefore they're special. And they for some reason are immune to marketing for reasons no one can explain. So yeah, there we go.

Matthew Revell: Before we wrap up, Benjamin in Discord says, does the book speak to help define the difference between a support forum and a community where we think of a community being a place where members are coming back, but support forum is you drop in, you ask your question, and then you go when you've got your answer? That's a

Joe Nash: Good question. Yeah, That's a good question. I actually don't know. I couldn't think of design after my head. But what I would say, my gut reaction to that is, and I don't know if the book speaks to this, but essentially the difference that you're talking about is, again, if we think of communities and the book thinks that communities display as a vehicle for solving someone's problems in a social manner. When you talk about support communities in that way, basically you're just talking about a far shorter community lifeline cycle. And it's not necessarily support forums. People do come back, but they end up coming back as contributors to answering people's questions. And so it definitely deals with that aspect of it, like increasing in particular, there's a design claim that I really love and I can't remember the number of it, but it's one that I often quote, which is, people are more likely to contribute if you call on them for knowledge they have individually. So if you know that someone in your community knows something and someone comes in and asks about that thing, if you say, oh, who's an expert of that? Benjamin, Benjamin knows about that, go ask Benjamin and then you'd tag 'em into that conversation, they're, they're more likely to get involved. And I think those kinds of design claims are really useful for support communities. An example from my current work, I work on a game called Twilio Quest, which is a learn to code game. And we have a Discord community and we have this really fun thing that happens organically where someone will join our discord because stuck on a part of the game, and they'll get through that part. They'll get the answer they need or they'll figure it out. And then really commonly, they seem to end up taking ownership of that problem. And the minute anyone else comes into the, you won't hear from them for weeks. And then someone will come into Discord and have that problem and suddenly they'll appear as the sole expert saviour of that problem. I think that that's obviously a pattern we're very fortunate to have in that community, but it is one that is fed out by research and addressed by several design claims in here that I think might not, the book might not explicitly say this is for support communities cause it didn't have that language, but if you inspect the claims and what's happening in them, you can apply it to your situation. That was a very long answer to get to know. It probably doesn't say support, but it does address that cycle of incentives and motivations.

Matthew Revell: Yeah, and I mean what you said there about the calling people out by name is actually a really important part of one of the chapters, and I forget which part, but they go into the behavioural science research on the bystander problem and all of that where it is really a fascinating read. And I think as you described it, it's the beginning of a rabbit hole of reading.

Joe Nash: Yes.

Carmen Huidobro: It actually reminds me, I don't know if this is too off topic of something that happened organically when I used to teach children to code with something very similar where some of them were kind of competitive and wanted to finish making, we used to make games, two dimensional games, and some of them would start getting competitive and like you said, Joe, they would become the person to go to figure out why the neon cat music didn't play in their game, for example. And it's, it's funny you mentioned organic because that's exactly what it is.

Matthew Revell: Sorry, just

Carmen Huidobro: Reminded me of that.

Matthew Revell: And that feeds back into those kind of core, again, going back to behavioural science, those core motivators, intrinsic motivators of autonomy being on top of something and the other one, which for some reason my mind's gone blank, but I mean mastery of a topic or being on top of a topic is something that makes us feel good. And if we can demonstrate that and be seen, I think it is probably a harmless way of feeling good about yourself was also helping other people. We are getting up to about 48, 50 minutes now, and we said we'd do half an hour. So just before we wrap up, I guess I'd like to go through some of the chapter headings, because even that is kind of a tour de force in community management theory I guess. So you've got, let's have a look. So Joe, the ones that we've touched on are those introducing communities and incentivizing and regulating behaviour, but the ones that we have are encouraging contribution to online communities, which is something that I'm sure is really crucial to all of our work. Encouraging commitment in online communities. Another really important thing, regulating behaviour, as we said, the challenges of dealing with newcomers and then starting new online communities. And so those five chapters along with the introduction are really, if you're new to developer relations, then that's your robot. Yeah, you wouldn't go wrong in giving that book out to every new person with the caveats that we've mentioned that it's not a pure guide, but it's a reference work. And yeah,

Joe Nash: One really interesting thing just about that chapter list is that the starting new online communities is last. I just think that's very telling, very telling, and it does in particular deal with the chicken before the egg problem of you need content to engage people, you need people to create content. That's the big focus of that chapter. So it's very, actually there was some tweets this week about people seeding new forums. It's very core to that.

Matthew Revell: I'd like to thank Sue for posting nine KA in the Discord. It's a shame I don't have the audio from it, but yeah,

Joe Nash: Just a brief note on getting the book. It's made everywhere It is because it is fundamentally an academic textbook. It's an MIT press book. It can be a little bit pricey. The ebook is as in most cases, actually one of the more affordable options. And because it's a random access book, as we said, I'm a big, I really love paper books. This is one of the books where I actually own it in both ebook and paper because I find it very valuable to be able to control F my way through it. So I would highly recommend grabbing an ebook if you are struggling to get it at non textbook prices. I did have a look around various online libraries before the call and unfortunately could not find it readily available in a lot of libraries, but if you have access to a university or academic library, I imagine it'll be there.

Matthew Revell: Yeah, I was going to say, it does seem to crop up in a lot of academic university libraries or college libraries if you are a student, and that's probably something we should talk about is affordability of the materials to get into Devra. Not that there are huge costs watching things like this or so on, but yeah, that's probably a discussion for another day. So Joe, thank you so much for joining us and sharing the book, building Successful Online Communities. We should definitely do a session, and it'd be lovely if you could join us, Joe, if you have time where we do a Discord voice chat with people who've read the book. I think that'd be great.

Joe Nash: That'd be lovely.

Carmen Huidobro: Joe, before we wrap up, I would also love to give you the opportunity to please give some shout outs to stuff that you're working on or any projects that you've got that are upcoming that we should be looking into. Thank you

Joe Nash: So much. I do have one thing that I want to shout out that might be interesting to this audience. You may have heard of Papers We Love. It is also a book club, particularly for reading, classic Computer Science Academic Works. It is typically a chapter based model for different cities. It's like a meetup where you come and read a chapter, read a paper together. We are doing something a little bit different with them mixing up papers. We love for the Covid generation where we are doing a topic specific chapter that will be fully remote focused on papers about computer science education. So we're going to be looking at works about teaching and learning, computer science, current state of the art of pedagogy around teaching code, reading code, this kind of thing that is still in very early days. It's not yet publicly out there, but hopefully it'll be out there in a couple of days. The first edition will probably be in February. So if you are interested in teaching or learning computer science and you are interested in this idea of that, there's a lot of things in academia that we all have access to. We can get some real insights there. Come along if you happen to be listening to this and do you have a paper that you're a big fan of or even if you've offered a paper, I would love to hear from you to come and speak at papers. We love education. You can find me on Twitter at jh and hopefully by the time this goes out, we will be on the papers. We love website. Currently we're only in the papers. We love GitHub, but you can find that are papers we love slash edu. So yeah, I guess the thing I would love to plug,

Carmen Huidobro: Thank you. That sounds so exciting. I actually wrote my bachelor paper on this sort of thing.

Joe Nash: Oh, well, you should present your bachelor paper.

Carmen Huidobro: I mean it's in no way a good, I mean I did get the highest grade, but

Joe Nash: You're digging this hole deeper and deeper.

Carmen Huidobro: I know, but I love this topic. I am so excited.

Joe Nash: Cool. Thank you

Carmen Huidobro: So much. Thank you.

Matthew Revell: Well, Joe, thank you. It's been really great. So you said where people can find you on Twitter and I guess they can find you as well around the internet in different places. So Joe, thank you very much. We'll say goodbye to you and we've got a bit of housekeeping at the end, so

Carmen Huidobro: Thank you both for having me.

Matthew Revell: Have a good evening. Thank you.

Carmen Huidobro: Thank you, Joe.

Matthew Revell: Okay, Ramon, that was great. I really enjoyed chatting to Joe there. That was, I had a

Carmen Huidobro: Wonderful time.

Matthew Revell: I also have some things to plug and you can plug some stuff too. I just want to quickly talk if that's okay, about the dev awards. So if you go to devrelawards.com, they're being presented by Orbit, sponsored by Orbit this year we want to celebrate the best in DevRel. So go and make your [email protected] before February the 11th, 2022. And I'll leave that there for now. But we are also doing a new edition of DevRelCon Online May 24th and 25th, which is called DevRelCon Deep Dives, and talking about those academic papers and so on, we're going to aim to bring in speakers from different disciplines who have deep research or experience in a particular thing that we can apply to developer relations. So that's deep dives.devrelcon.dev.

Carmen Huidobro: I can't wait. That sounds so exciting.

Matthew Revell: Yeah, I'm looking forward to it myself. So Carmen, anything you want to talk about?

Carmen Huidobro: Oh, well, I didn't actually anticipate this, but I could talk about what I'm up to. So we are in the process of going through our second week of a free JavaScript bootcamp that we're doing in cooperation with Class Central. My friend Jessica Rose is doing one on web development, and so if you know anybody that would like to learn JavaScript or web development from scratch, we're doing this in a low key. This is quite intimidating. We've got a combined total of 12,000 registrants for these boot camps. It's a lot of responsibility, but it's also a lot of fun. So if you know of anybody who would like to learn to code from scratch, this is what we're trying to do.

Matthew Revell: And where can people find that?

Carmen Huidobro: Of course, this would be classcentral.com. There they'll find a dropdown for cohorts and there they will find one for the Web Development bootcamp and one for the JavaScript bootcamp.

Matthew Revell: Wonderful. Okay, great. Congratulations as well.

Carmen Huidobro: Thank you.

Matthew Revell: So let's talk about what we're going to do next for DevRel Book Club. So in February we will be joined by Tessa Kriesel, who will be talking to us about the book Superfans by Pat Flynn. And that will be, I think half an hour earlier than this one today, which yeah, will be, oh no, sorry, it will be an hour and a half later. So it'll be at 10 o'clock Pacific if you are in San Francisco or that side of the US and about, well, six o'clock if you're in the UK pm and then seven o'clock if you're in Austria, Germany, France, or places like that. And the way that we're going to do the time zones is we're going to assume if you're awake, then we'll give the time zone, but so people in India and Japan and so on are probably not watching live streams at the time, but that will be on, let me quickly take a look to remind myself 15th of February 10:00 AM Pacific or 1800 UTC, and that'll be with Tessa Kriesel. Then on March 15th, so the month after, we'll be joined by Suze Shardlow who will be talking about the book, the Art of Gathering by Priya Parker. And that will be, like I say, 15th of March at 10 30 in the morning, UTC or 4:00 PM in India. So we're trying to mix up the times of these sessions so that people around the world can join them live. But you'll always be able to go to developerelations.com/devrel-book-club to get the podcast or subscribe wherever you get your podcasts. That's the fancy thing that's in, is it? Like 'em Subscribe.

Carmen Huidobro: Wonderful.

Matthew Revell: Yeah. Well, it's been wonderful. Thank you so much. Have a lovely Viennese evening.

Carmen Huidobro: You a wonderful UK evening, Matt. It's been a joy and thank you so much for having me. This has been so much fun. The hour.

Matthew Revell: Yeah, thank you.

Carmen Huidobro: This past 50 or 60 minutes just flew by.

Matthew Revell: Absolutely. Yeah, it did, didn't it? Yeah. Well, the last thing to say is if you want to participate or you want to be a guest or you've got any comments or anything, at the very least, you can always drop us an email [email protected]. And if not, you can find us on Twitter or wherever we may be. So thank you and goodbye

Carmen Huidobro: You next time.