Managing an Open Source Community of Storytellers (Part 2)
Managing an Open Source Community of Storytellers (Part 2)
In part two of Jason's interview, we focus in on his day-to-day work as a senior community architect, a hybrid role of dev community manager/product manager, for opensource.com.
Join the DZone community and get the full member experience.Join For Free
Recently, I interviewed Jason Hibbets, senior community architect at Red Hat for opensource.com. He'll be speaking at the All Things Open 2018 conference which is set to run from October 21st - 23rd at the Raleigh Convention Center in downtown Raleigh, NC.
Part one of Jason's interview covered the origins of opensource.com while pulling back the curtain on his upcoming talk, Survive and Advance: The Life of a Community Manager. In part two, we pick up where we left off, focusing in on Jason's day-to-day work as a senior community architect, a hybrid role of dev community manager/product manager, for opensource.com.
Enjoy the interview and be sure to check out part one!
Looking at your description on the All Things Open speaker page, you're described as a senior community architect at Red Hat for opensource.com—a mash-up of a community and a project manager. So can you describe a little bit of what your day to day is like, talking about how these two responsibilities differ from each other, and also how they complement each other?
Yeah, so I've got a couple things here. First, I'll just say that the way that I kind of came up with that title as community architect is I've actually built multiple communities. So anyway, when I helped launch the opensource.com publication and community that was a big learning curve. And then, after we kind of got that established, I helped build out the open organization community—which the open organization is a book written by Red Hat CEO, Jim Whitehurst... and a little spoiler alert at the end of the book, he says, to continue the conversation, head on over to opensource.com. And, in a very Red Hat kind of way, Jim didn't come to my team and say, hey, I want you to build x, y, and z. He was just like, hey, FYI, this is at the end of my book, go figure out. Those weren't the exact words. But that was the sentiment.
And so, my coworker, Brian, and I had to figure out what it would be—what does it take to build a community around this. So that was kind of the second community. Then August of last year, I started to focus a bit more on DevOps. And so I've been building out a DevOps community within the community. That's how I got to community architect.
And really, to generalize it even more, the role that I do is also just around community organizing. So, this is the person in your neighborhood or your apartment complex that wants to organize the potluck dinner or your coworker who organizes a meetup—the goal of doing community organizing is to bring people together around a common interest. So, that's how I found out my passion is bringing people together around their passion for open source.
And, to kind of drill down to the day-by-day stuff, it's all around the publication. There are certain things that I do on a daily basis like getting content. I'm focused on getting DevOps content: two articles a week. Also, I'm doing some social media work right now to make sure that we promote the great content that we get through various social media outlets. So that's the norm—it's got to get done before I can do any of the other cool stuff that I really want to do here on the community manager side. It's really about managing volunteers and managing some of the content that comes in. So, that's a mix of doing publication/editorial things and also managing volunteer expectations, as well as monitoring deadlines and making sure we've got a good pipeline of content coming in.
As an example, with the DevOps team—the opensource.com DevOps team that I'm working with—I've got about a pool of about 70 people that are "interested" in some fashion of this DevOps team that I'm building out. Of that 70, just under half of them have actually contributed a written article. And of that half, about a third of those have actually contributed multiple articles. So, you can see it's built out, I'm kind of a little bit like a pyramid where you've got a large base of interested people. You've got folks that actually make the jump to write an article; and then, you've got folks who hopefully have had a great experience that continue to write multiple articles. And so, I think that's kind of the community manager side.
On the project management side, there's a lot of different stuff that I work on, event planning being one of the primary tasks. As an example, with All Things Open, I am the organizer for the Lightning Talks on day two of the event. I curate all the speakers; I get all the content prepared. So basically, I collect all of their slides and get all of the speakers prepared for that one-hour session. I also helped organize a one-day strategy session for our community moderators—that's the day before All Things Open. That involves booking travel & lodging, planning dinners... all that type of event stuff.
Aside from that, I was an organizer for DevOpsDays in Raleigh. But really, they're in charge of their speakers and making sure that the keynotes & ignite speakers had all their details correct. And then, also my passion in my spare time, I worked on a project called NC Open Pass. Probably a little bit unique to my role as a community organizer/community architect is that I do a little bit of web development. However, I want to specify that I don't actually do any coding; I help manage our opensource.com web deployments. My role is to track any features or bugs that we want to work on, then do sprint planning around that, and then manage our two-weeks sprint with our development partner. I do a lot of QA around many of the sprints, and then I work closely with our development team to do the code deployments after we've finished the sprint. As you can see, there are a variety of things that fall under this community architect/community organizer umbrella, some of them are more people- and content-related, and some of them are more task- and project-related.
That's really interesting. And just thinking about the last thing you said there about getting involved in guiding the direction for opensource.com the product, what I think is cool about your position as a product manager is that you're a community manager—you're talking to the people who are using the site. So, do you think that gives you a unique lens into what to suggest you guys do with the site itself? You see pain points that other people don't. Your view of the site is going to be more community-centric then someone else who's trying to make the admin page work a little more user friendly, or something like that.
Yeah. Essentially, we used to give our contributors a lot more access to the backend and then found that everyone uses WYSIWYG or HTML differently. We found we were spending more time cleaning up content and we weren't getting enough content in, so we actually pivoted a couple years ago, and just said, hey, give us a draft of your article. And then our team worked out a whole workflow in the back end where our contributors don't even see it. Basically, they give us a draft of an article, and the next step for them is to log in and review it on the site. So, we try to make it really simple for our contributors and have a more efficient process on our side. This way we're not spinning cycles on cleaning up bad or misformatted HTML.
Sounds familiar to our workflow. So, as a community manager, how do you approach community disputes? How do you judge when the conversation is heated debate versus an exchange of insults or attacks? In other words, where does it cross the line? Do you guys have community standards that you enforce? And, what have you learned from your experience in setting and adjusting these standards? Lastly, if you have any particularly difficult incidents you struggled with and learned from, would you mind sharing a little bit about them?
We haven't had too many challenges around this. But I think it's really about having a good set of rules and also be prepared to enforce them. And I would just say to the developer audience, if you're going to participate in any sort of community, make sure they have a code of conduct, make sure you understand the code of conduct, and make sure you understand the ramifications of violating the code of conduct. I think that strong communities are born out of strong codes of conduct.
And going off of that, I was wondering, because you mentioned spammers, if in your unique position you've been able to kind of use the product management role to create any sort of spam filters or put anything in place that combats this behavior?
That's a very great question. We have! I am always thinking of ways to leverage our Drupal platform to fight spammers. It's actually one of my favorite things to do. And so there's a couple of standard triple-A modules that we have installed that help to prevent some of this. There's one called Honeypot which is kind of a web form thing, where it can detect bots and simply prevent them from submitting stuff, which is really neat. We actually found that we get a lot of spam registrations—fake user accounts that are being created. So one of the things that we've done is we will not display a user profile unless they've earned 10 points. And really, to earn 10 points, all you have to do is log onto the site 10 times because you get a point each time for logging in... or you can just make two comments. So, I feel it's a relatively low barrier to entry. Because the majority of the spam bots are registering user accounts to get a link on their profile page, we don't even display websites on user profiles anymore.
And also, we no longer allow them space to put this in their profile; there's no specific field for website which we used to have. So, there are just little things like that, that we've done to help prevent some of the spam stuff. Of course, we have the standard Drupal stuff to detect spam, comments, and so forth. And, we review all the stuff that gets flagged every day—our users and community moderators have ways to flag comments—so we also leverage the community aspect of it to flag anything that needs another set of eyes on it from an admin.
So, thinking specifically about your mash-up of positions, the community and project manager, can you talk about how your unique position to managing the community has paid off by giving you insights into where you should take the product for the betterment of the community? In other words, have you ever seen a specific development change—a bug or feature request—that you heard the community calling for? And if so, how did you communicate this change to the community throughout the different stages? For instance, the community is antsy for a change, you guys are trying to build out that change, and then after you've made it, you can assumedly announce it. Just kind of wondering how that works... because you're in a unique position where you can kind of push changes through, but also communicate them to the community.
Yeah, when, when we have any big changes coming out, I will usually write up an article and just kind of describe what the changes are and when they're coming. And, if there's any feedback that can be gathered, I try to get that in advance.
So, I got a couple of things I want to mention here. One, we did a big-ish redesign about two years ago. And I say big-ish, because we were changing our layout from a two column layout to a single column layout. And we had three big goals that we're trying to accomplish with that one. We wanted to make the site more mobile-friendly because we saw an increase in mobile traffic and we wanted to make the site easier to read because people are coming here to read content. So, we increased the font size and did a lot of research on the optimal width for the columns that we needed. Then, we went with a mobile-first kind of development cycle. And the last one was, we wanted to make it present better related content. So if a reader lands on a DevOps article, we wanted to give them more DevOps that they might want to read.
So, those were the three big goals. And after we launched, it got a lot of great feedback. That's a big thank you to Red Hat for sponsoring and supporting an effort like opensource.com. It's another way that Red Hat can give back to the open source community by creating this amazing storytelling platform. And because we don't have a typical publication where we need to do ad revenue, it allows us to have a much cleaner design, and really just give the readers what we think they want. We're just trying to deliver great content
In general, our philosophy on web development is that we don't need a bleeding edge website because we're not getting page views from feature development. So we just want to have the basics: keep it clean, keep it down to earth.
But there are a couple of features that get really specific that I've seen kind of playing this. For instance, one of the things that the community requested was an events calendar on the site, in which we'd allow anyone to post any sort of open source event meetup: Linux, user group, whatever they have, they can post it, and it'll earn points toward their profile. And upon approval, they'll display in our calendar. We actually had a couple folks say, "Hey, can we make an iCalendar version of this. And so, within a couple of sprint cycles, we were able to get that out and really just let people add this events calendar to their everyday calendar that they're using. So that was pretty neat.
And there was a big one that happened within the past few months here. We noticed that we had many more people who were co-authoring articles. So we were working with default Drupal here and we would just default to one user owning one piece of content. And even though we had a way to show if people had contributed to an article, but we didn't have a great way to show if it was kind of equal authorship or co-authorship. So, we figured out a way to highlight if there are multiple authors for an article, and it was one of those things where it just showed up on the site. And people kind of noticed it without noticing it, if that makes sense. They're like, Oh, that's there now. I didn't see that before. That's cool. And then, they just carry on. So, we felt that was important enough to actually put some development time against it, because we value our contributors, and we want to be able to show who was contributing to what content. I think that's a testament to our commitment to our community. And being able to turnaround a feature like that, one that's not necessarily something contributors were asking for, but more that our editors and other community managers were like, Hey, this is really important. I've got these two people who are writing a column every month on Python, it would be really great to showcase that they both contributed to the article.
So, I think that's a pretty good example.
Yeah, that's perfect. Thanks again for the interview, Jason!
All Things Open 2018
Join DZone plus thousands of other developers and technologists in Raleigh, NC for the largest open source conference on the east coast of the US. We have 10 free passes to ATO 2018 available on a first-come-first-served basis. Just enter the promo code DZonefree when registering and send me a Twitter DM to confirm you are coming! If all free passes are already claimed, then take advantage of an additional 20% off entry by entering promo code DZone20.
Hope to see you at the show!
Opinions expressed by DZone contributors are their own.