On Jono Bacon’s discussion of Reddit karma

Last week, Jono Bacon published a YouTube video discussing the karma system used by Reddit. It’s worth 28 minutes of your time if you’re thinking about a reputation system for your community. I don’t have any disagreements, but there are a few “yes, and”s that popped up as I watched it.

What’s karma for?

A fundamental problem with karma is that it applies to posts/comments, not to accounts. Yes, Reddit displays a net karma score on account profiles, but it doesn’t do anything with it. A large number of upvotes will move a post or comment toward the top. A large number of downvotes will hide a comment behind a “wow, do you really want to see this crap?” (my words) link. But apart from removing a posting frequency speedbump for new accounts, the account’s karma doesn’t actually mean much.

Karma is non-specific

Another big issue with Reddit karma is that it’s the same across the entire site. Jono talked about using karma as a metric of credibility. If you narrowly define “credibility” as “knows what the community likes”, then that works. But I might earn a bazillion points for my insightful open source posts. When I go to post in an small engine repair subreddit, my karma comes along with me.

Just because I can successfully participate in one subreddit, that doesn’t mean I can in another. And it’s certainly not a measure of expertise on a topic. Jono alludes to this by talking about how karma doesn’t distinguish between funny and helpful, for example.

Brigading

You can’t buy karma. That’s one of the benefits of Reddit karma. But you can buy accounts to apply karma. Whether you pay money to a bot farm or just wield your influence on another platform, you can drive upvotes or downvotes to an account of your choosing. Since karma is mostly meaningless at the account level, the direct harm of this is fairly small. But brigading is always a concern in online communities.

Okay, so then what?

Reddit karma has its downsides. But it is very simple, which is a huge benefit. I tend to favor the more account-centric systems like Discourse trust levels and StackExchange reputation. Sites like ArsTechnica have an up/down vote systems with an optional tag to explain why you’re giving the vote. If Reddit’s karma was per-subreddit, it would be more useful as a measure of credibility.

Setting boundaries when working in communities

Kat Cosgrove recently had a tweet that hit home:

I haven’t taken any meaningful time off of work in the last 14 months because it feels kinda pointless. I’m just going to be sitting at home thinking about work so I might as well be doing work. Invariably, what I fear is happening while I’m not at work is much worse than what is actually happening. Yay, anxiety!

But also, there’s some guilt when you’re paid to work in a community where a lot of people are volunteering. I don’t feel like I can say “hey, it’s after my work hours” because many in my community only participate outside of their work hours. Add to that the global nature of open source communities and that means that there’s always something to devote my time to.

I think it would be easier to come in as an outsider who is just doing the job for a paycheck. But working in a community where you previously volunteered makes the urge to be around all the time so much stronger. It can be really hard to set boundaries because it feels like you’re devaluing the donated time of others.

It’s a blessing and a curse. I happen to think I’m pretty good at my job (and the fact that I’m anything other than a failure should tell you something) and I know that’s because it’s more than a paycheck to me. But that’s also what makes it so hard to draw boundaries.

My manager (who is very good at reminding me to take care of myself) recently compared it to working for a startup. Everyone pitches in wherever they can, even when it’s not on the job description. That’s incredibly true in open source projects, except there’s no exit. It’s not like you’re working hard now so you’ll get a stupid-large pile of cash when a big company acquires you or you have an IPO. If the project is successful it…keeps being a startup forever.

For now, I’m holding up pretty well. I’m balancing working too much with non-work interests (even if a lot of them look like work to the outside observer). But I wonder how long that can hold. And I wonder how others in a similar position make it work over the long term.

Book review: People Powered

Jono Bacon knows something about communities. He wrote the book on it, in fact. And now he has written another book. People Powered is a guide for how companies can create and curate communities.

I often see companies try to start what they call “communities”. In reality, they are ways for the company to get free labor that provide no real benefit to the the participants. But it doesn’t have to be that way. A community that doesn’t benefit the sponsoring company is not likely to continue receiving sponsorship. But if there’s no benefit to the community members, the community will not thrive. Only when everyone involved gets value from the community will the community be vibrant.

A community mission is different than your business vision, but tightly wound around it.

All too often, books like this prescribe the One True Way™. Bacon does not do that. He fills the book with many things the reader should do, but he also makes it clear that there are many right ways to run a community, just as there are many wrong ways.

People Powered is a starting point, not an answer. As I was reading it, I thought “this is a good set of recipes”. Further on, Bacon used the same metaphor. Curse you, Jono! But it’s an apt metaphor. The book presents advice and knowledge based on Bacon’s 20 years of community management. But each community has specific needs, so the reader is encouraged to selectively apply the most relevant parts. And in the tradition of open source, plans should be iterative and evolve to meet the changing needs of communities. Like any good cook, the recipe provides a starting point; the cook makes adjustments to taste.

If I could sum up People Powered in two words, I would pick “be intentional.” Given two more words, I’d add “be selective.” People are often tempted to do all the things, to be all things to all people. And while that may be in the future of a community, getting started requires a more specific focus on what will (and more importantly, what won’t) be done.

People Powered is full of practical advice (including a lot of calls-to-action to find resources on jonobacon.com). But it also contains more philosophical views. Bacon is not a psychologist, but he has made a study of psychology and sociology over the years. This informs the theoretical explanations behind his practical steps. It also guides the conceptual models for communities that he lays out over the course of the book. And to prove that it’s a Jono Bacon book, it includes a few references to behavioral economics and several to Iron Maiden.

I really enjoyed this book. Some of it was obvious to me, given my community leadership experience (admittedly, I’m not the target audience), but I still got a lot of value from it. Chapter 9 (Cyberspace and Meatspace: Better Together) particularly spoke to me in light of some conversations I’ve had at work recently. People Powered is an excellent book for anyone who is currently leading or planning to lead a community as part of a corporate effort.

People Powered (affiliate link) is published by HarperCollins Leadership and was released yesterday.

Disclosures: 1. I received a pre-release digital review copy of People Powered. I received no other consideration for this post (unless you purchased it from the affiliate link above). 2. Jono Bacon is a personal friend, but I would tell him if his book was awful.

If you want a diverse community, you have to stand up for marginalized members

On Monday, The Perl Conference’s Standards of Conduct Committee published an incident report. In a talk at the conference, a speaker deadnamed and misgendered a member of the community. As a result, they took down the YouTube video of that talk.

The speaker in question happens to be a keynote speaker at PerlCon. The PerlCon organizers wrote a pretty awful post (that they have since edited) that essentially dismissed the concerns of the transgender members of the Perl community. They went on to mock the pain that deadnaming causes.

I did not think to save their post in the Wayback Machine before they edited it down to a brief and meaningless statement. “We are preparing a great conference and do not want to break the festival and trash our year-long hard work we did for preparing the confernece, the program and the entertainment program.”

What they don’t say is “we value the marginalized members of our community.” And they make that very clear. Editing out the insulting part of their post does not ,mean much, as VM Brasseur pointed out.

https://twitter.com/vmbrasseur/status/1148674272350494720

If you value an inclusive community, you have to stand up for the marginalized members when they are excluded. If you don’t, you make it very clear that you’re only giving lip service to the idea. As it is, the PerlCon organizers don’t even apologize. They’re more concerned about the bad publicity than the bad effect on the community.

Don’t give gatekeepers a foothold

Gatekeepers are a problem in communities. They decide — often arbitrarily — who can and cannot be members of a community. Are you a true Scotsman? A gatekeeper will tell you. And if there’s something they don’t like about you, or they’re feeling particularly ornery, they’ll keep you away from the community.

Gatekeeping is a problem in open source communities. More experienced (or just louder) contributors set a bar that new contributors cannot meet. This is bad for folks who want to contribute to the project, and it’s bad for the project’s sustainability.

A recent Opensource.com article asked “What is a Linux user?“. In the initial version, it left open the possibility that if you’ve only used a Linux desktop that doesn’t require a ton of tinkering, then you’re not a real Linux user. Fortunately, the comments called this out quickly. And the author, to his credit, did not hold this view. He quickly updated the article.

The revised article does a much better job of closing the door on gatekeeping, but I would rather it have never run at all. By engaging in debate on the question, you give it validity. It’s best to deal with gatekeeping by not even acknowledging that the question is valid.

Picking communication tools for your community

Communication is key to the success of any project. The tools we use to communicate play a part in how effective our communication is. Recent discussions in Fedora and other projects have made me consider what tool selection looks like. Should Discourse replace mailing lists? Should Telegram replace IRC? I’m not going to answer those questions.

There’s no one right tool, just a set of considerations to think about in selecting communications tooling. Each community needs to arrive at a consensus about what works best for their workflow and culture, and keep in mind that the decision may attract some contributors while driving others away.

In this post, I’m going to broadly lump tools into two categories: synchronous and asynchronous. Many tools can be used for both to a decent approximation, but most will pretty obviously fall into one category or the other. Picking one tool to rule them all is a valid option, but be aware that it immediately favors one category of communication over the other. And keep in mind that for large projects, some sub-teams may choose different platforms. That’s fine so long as people who want to participate know where to look.

Considerations for all tools

Self-hosted or externally-hosted. Do you have the resources to maintain the tool? If you do, that’s a way to save money and maintain control, but it’s also time that your community members can’t spend working on whatever your community is doing. Externally-hosted tooling (either free or paid) might give you less flexibility, but it can also be more isolated from internal infrastructure outages.

Open source or proprietary. This is entirely a value judgement for your community. For some communities, anything that’s not open source is a non-starter. Others might not care at all one way or another. Most will fall somewhere on the spectrum between.

Federated or centralized. Can the community connect their own tools together (e.g. like with email) or is it a centralized system (like most social media platforms)? The trend is definitely toward centralized systems these days, so you may have to work harder to find a federated system that meets your needs.

Public or private. Can outsiders see what you’re saying? For many open source projects, public visibility is important. But even in those communities, some conversations may need to take place in private or semi-private.

Archived or ephemeral. Do you want to be able to go back and see what was said last month, last year, or last decade? Some conversations aren’t worth keeping, but records of important decisions probably are. Does your tool allow you to meet your archival needs?

Considerations for synchronous tools

Sometimes you really need to talk to people in real time.

Mobile experience. It’s 2019. People do a lot on their phones, especially if their contribution to your community happens during their workday or if they travel frequently. What is the mobile experience like for the tools you’re evaluating? It’s not just a matter of if clients exist, but what’s the whole experience. If they disconnect while on an airplane, do they lose all the messages that were sent in their absence?

Status and alerting. What happens if someone stays logged in and goes away for a little bit? Do they have the ability to suppress notifications? Is there any way to let others know “I’m away or busy, don’t expect an immediate reply”?

Audio, video, and screen sharing. Sometimes you need the high-bandwidth modes of communication in order to get your full message across (or just shortcut a lot of back-and-forth). Does the tool you’re looking at provide this? Is it usable for those who can’t participate due to bandwidth or other constraints?

Integrations. Can you display GIFs? The ability to speak entirely in animated images can be either a feature or a bug, depending on the community’s culture. But if it’s important one way or another, you’ll want to make sure your tool matches your needs. Of course, there are other integrations that might matter to. Can your build system post alerts? Does the tool automatically recognize certain links and display them in an particular manner?

Considerations for asynchronous tools

Of course, you’re not all going to be sitting at your computer at the same time. People go on vacation. They live in different time zones. They step away for 10 minutes to get a cup of coffee. Whatever the reason, you’ll need to communicate asynchronously sometimes.

Push or pull. Email is a push mechanism. Your message arrives in my inbox whether I’ve asked it to or not. Web fora are a pull mechanism. I have to go check them (yes, some forum tools provide an email interface). Which works better for your workflow and community? Pull mechanisms are easier to ignore when you want to step away for a little while, but they also mean you might forget to check when you do want to pay attention.

Is it a ticket system? I haven’t really talked about ticket systems/issue trackers because I don’t consider them a general communication tool. But for some projects, all the discussion that needs to happen happens in GitHub issues or another ticket tracker. If that works for you, there’s no point in adding a new tool to the mix.

The resurgence of the web forum

I saw an interesting thread on Twitter recently. The Ghost community shut down their Slack instance in favor of a forum. Yes, those mainstays of mid-aughts online socialization seem to be making a comeback. And I get it. As much as I appreciate Slack for work chat, it’s kind of a pain to use socially when you have a lot of groups.

I’ve written before about the downsides of Slack for communities. But in that, I was thinking more of the individual perspective. John’s thread brings the group perspective to mind.

As communities grow, it’s harder for people to feel a sense of belonging. Slack’s fast pace and emphasis on the moment make it hard to step away. Indeed, in a large community using the free version, you lose history pretty quickly. This is true of other group instant messaging, too, of course. But there’s a reason you don’t see a lot of thousand-person chat rooms (or dozen-person group texts). Many-to-many communication gets noisy quickly.

If a community’s messages are largely of the question-and-answer variety, forums make a lot of sense. Keeping the answers near the questions makes it easier for future visitors. Both the questions and answers become easier to find. Of course fora have their own issues. You have to remember to go to the website and check for new messages (or else get a barrage of emails that you’ll ignore anyway). But it goes to show that technology is cyclical. And even good products can fade as the newness wears off.

Twitter’s public roadmap: I’ll believe it when I see it

Full disclosure: I own a small number of shares in Twitter.

Trello is a very important tool in my workflow, so I read their blog for tips and news. I started reading a recent post by Leah Rider and everything was fine until I saw this:

As one of the most dialed-in companies to the pulse of the people, Twitter…

I’m sorry, what? Twitter is notoriously bad at knowing what people want, be they users (an edit button and less harassment), developers (the ability to develop apps), or investors (I’d settle for breaking even at this point). Twitter may be where the pulse of the people is expressed, but that doesn’t mean the company has a clue.

The post goes on to say

Through a simple public Trello board, Twitter is redefining their relationship with the developer community and setting a precedent for other platforms.

If Twitter wants to define a relationship with the developer community, they could start by having one. The only reason I maintain a Twitter client is because Twitter drove away the original developer. Twitter’s rise was due in part to the ecosystem of great (and not-so-great) third-party applications. Twitter was a platform that people could build off of.

That’s no longer the case. Many features are not available via the API. Polls and GIF searches are two that come right to mind. It takes more than a public Trello board to have a community. And the Trello board isn’t even impressive. It is publicly visible, but not editable. What’s worse, the last update was almost a month ago. The last activity before that was over two months ago.

So if Twitter is ready to develop a robust third-party app ecosystem again, that’s great. It can only benefit the platform. But you’ll forgive me if I wait to see some evidence before I believe it.

The tradeoffs of Slack for community projects

When my employer adopted Slack, we saw benefit immediately. Conversations are searchable, file sharing is easy, and oh how I ? /giphy. It’s a great tool, but I don’t like it for open communities.

Slack was designed to be a company’s internal communication system. For that purpose, it’s great. It was not designed to be an open platform. For example, it is basically impossible for users to manage harassment.

Most people have one employer at a time. That’s not the case for hobby and interest communities. I have five unrelated rooms on Freenode IRC that I’m regularly in. For the most part, I manage that in one place. But each Slack instance I’m in might as well be a separate universe.

That’s not to say Slack is all bad. It is much easier to learn and use than most IRC clients. This is a significant benefit to non-technical communities. Creative Commons, for example, saw a large uptick in community participation after moving to Slack. Slack allows for a richness of community culture to develop in ways that text-only formats don’t.

But for me, particularly with open source communities, the less-than-public nature of Slack teams is a negative. People can’t join the communities they don’t know about. And if they can’t lurk quietly (by reading transcripts or joining the server anonymously), will they feel safe jumping in? There are lock-in considerations as well (my free software readers have probably been waiting for me to get to this point) that I think I’ll address in a later post.

Each community has to decide what is best for them. Like any other technology, Slack has pros and cons. The important thing is to weigh them before making a decision.

What counts more for community: labels or actions?

I was recently in an argument on Twitter (I know, I know). The summary is that there was disagreement on whether stated party affiliation or cast votes were more indicative of the state of the body politic. We didn’t arrive at a consensus, but it got me thinking about open source communities.

Communities are notoriously difficult to pin down. Where are the boundaries? Is a person a member of a community when they (or someone else) decides to apply that label to them? Are they a member when they make some overt participation effort? Is it a mix of both?

In general, I tend to think that if it looks like a duck and quacks like a duck, there’s a pretty good chance it’s a duck. That is to say a person is a member of a community if they participate in the community, even if they don’t self-assign the label. For example, if someone considers themselves a political independent but they vote for Democratic candidates 80% of the time, they’re probably a Democrat. Similarly, someone who frequently answers questions in an open source project’s IRC channel or mailing list is a member of the contributor community, even if they don’t think they are (perhaps because they’ve never contributed code).

This isn’t to say that communities shouldn’t welcome people willing to self-assign membership. Unless someone has behaved in a way to warrant exclusion, they should be welcomed and encouraged to become active participants. That doesn’t necessarily mean giving them full access, though. I still consider myself a contributor to Fedora Documentation, even though I haven’t really made a contribution in a while. I still have commit access to the repo, but if someone decided to suspend that, I’d understand.

There’s not a good answer here. How a you define community is largely context-dependent. It’s worth considering how we define the boundary.