We often talk about "The Perl Community", but I don't think it exists. Instead what we have is a loose, and at times fraught, federation of communities. Over the last few weeks I've been thinking and talking about this a lot, so I wanted to share some of those thoughts, and hear what others think. This is not me trying to tell you how things are, but how I see things, and also to outline some things that I think might help us be less fraught.
A community is two or more people who come together, typically because they have something in common. This may be a belief, a common purpose or goal, an activity, pastime, or a shared characteristic. A group of people with something in common, that they might use as a label for themselves, or a shared identity.
This can happen organically. Let's say you get into knitting, and you bump into someone who's not only another knitter, but feels like a kindred spirit. You start hanging out at the pub, knitting together. Other people notice and ask if they can join in. This is great: you feel part of something, and it's boosting something that already gave you pleasure (knitting). Slowly you accrete more members, and it becomes a key part of your life. You're emotionally invested. Then someone joins your circle, but they're a bit different. They start telling everybody what they're doing wrong, scoffing at crochet, and getting right in your needles. "Hey, we'll all be better knitters if we're honest with each other – I'm trying to help you, and you should push me too!". Some people look to you to "do something!", but others like the new member, finding them a breath of fresh air. Suddenly your happy place has become a cause of stress. There's no malice intended, but unless dealt with, the tension will build up, lead to conflict, and worse.
When we join a community that feels like a good fit, it's easy to assume that we all share the same values, but that's almost never the case. It's also tempting to think that because you're "with your tribe", that you should like everyone, and everyone should like you. But for a community of any size, that just won't be true, and hoping for it can only lead to disappointment.
Similarly we're not going to agree with everyone else's ideas and opinions. We need to run our communities in a way that lets us work through our differences and reach consensus. Most of the time that won't mean unanimity, but that the right people had an opportunity for input, and an appropriate process was followed to produce a decision that people can live with. While doing that, we have to be mindful of Popper's Paradox: to maintain tolerant communities, we must be intolerant of intolerance.
One Perl community is "The Toolchain". These are the people who work on PAUSE, MetaCPAN, and other parts of the CPAN ecosystem that we all rely on. Over the years there have been a number of areas of tension, resulting in charged emails and stressful discussions. Working through two of these ultimately resulted in the River of CPAN model and PAUSE Operating Model. Having shared mental models has made it easier — and less fraught — to talk about what we're doing together. Conflict can sometimes be an indicator that you're missing a shared model.
We need a shared model for our communities: what are they, how do they fit together, how do they work individually, and what happens when they overlap. I suspect that individual communities will find that they would benefit from their own internal models as well, as Toolchain has.
We've all heard about situations where our communities seem to be dysfunctional. In many of those cases, I don't believe there was malicious intent, but a mismatch in one or more of expectations, values, principles, priorities, mental models, and more. And while we've gradually been introducing codes of conduct, and other standards, over the last 25 or 30 years we've essentially accumulated community debt.
In addition to shared models, our communities need standards of behaviour, which have to include processes for dealing with someone who violates those standards. That may be as simple as "if you're a jerk, we'll kick you off", but larger communities need a range of tools at their disposal, including a quiet chat, warnings, time-limited bans, and then ultimately a lifetime ban ("permaban"). There are situations where a permaban is an appropriate first response (sexual assault or physical violence, for example), but in most cases, a permaban should be the tool of last resort, used only when all other avenues have been exhausted. Sometimes people just aren't for your community, but there should be a respectful and transparent process for getting to that decision, that doesn't feel arbitrary and capricious.
Communities of any size are going to be heterogeneous, and that's a good thing, but presents challenges. People need to find their place, and healthy communities work out how to play to their members' strengths. Being more explicit about the nature of each of our communities, and how they work, could help this, I think.
We need the people who quietly beaver away, building things that we all rely on, whether that's Perl itself, the toolchain, CPAN modules, or tools like ack. We need the people who write documentation, publish books, and weekly newsletters. We need the people who organise events and meetups, and who bring us together in myriad other ways, including those who provide and run infrastructure that our online communities rely on. We also need organisations like TPF, Les Mongeurs de Perl, and the EPO, to handle things like trademarks, provide bank accounts, channel sponsorship, and many other behind-the-scenes activities required for a large family of communities.
When these people and communities come together (at conferences, on mailing lists, IRC, Twitter, Facebook, meetups, etc), differences in values, behaviours, and norms, come into play. This is one of the reasons why these places benefit from an explicit code of conduct. Many conference organisers don't think of it as "their conference", but as something that they do "for the community". In that context, organisers can feel uneasy about specifying the rules, but ultimately it will make life better for all of us if they do. Saying "this conference has no code of conduct" is a code of conduct, and lets people make decisions about whether they're happy to attend.
Our IRC channels and perl.org mailing lists are similar but different. Lists and channels are individual communities, and can create their own culture, but have to do so within the constraints of the operators rules (e.g. the irc.perl.org house rules).
One example list, perl5-porters or "p5p", has a clear governance structure, with a Steering Council (PSC). The council's job is to build a shared vision, not to impose one. We've seen this over the last year when trying to create a definition for Perl 7. A perennial tension in p5p, and elsewhere, is to find the balance point along the spectrum from "change nothing", through "aim for backwards compatibility", and "forward motion", ending somewhere near "move fast and break things". Imposing a vision top-down didn't work; once we started talking to lots of people, and listening, the "right answer" seemed to crystallise out. Sure, some people knew that right answer "all along", but as a community we had to work through to get to that point together.
I don't think we should talk about "The Perl Community", but rather "The Perl Communities". They're complex, messy, and diverse (in many ways, nowhere near enough). We've built up significant community debt over the last 30+ years. We have a lot of pieces in place, but I think we need a shared model for talking about these communities, so we can decide how we want them to work, and what to do when they collide, or overlap. I think we need to build that together.
One thing that would help us is a map, so that we all have the same picture of our communities, and how they fit together. What house rules do we have already, and who gets to define them? Creating this sort of map will probably produce a lot of "oh, I didn't know that” moments. I suspect the best way to come up with the map is for various people to have a go, and then we patch them together until we have something that feels right.
At the same time, we can talk about communities and how they work, sharing stories and resources, and looking at what other communities beyond Perl have done. There are many wheels here that we do not need to reinvent. Hopefully these things will prompt individual communities to start defining their cultures, and where appropriate, governance structures. In a grassroots community of volunteers, like ours, I think that culture has to "bubble up": not be imposed in a top-down fashion, and leadership should be seen in terms of service to your community.
We'll then start thinking about the boundaries between communities, and the meta communities where we come together, and how best to define them. I hope the process will naturally bubble up, as we factor out common pieces.
In working this stuff out, we may find communities that don't want to be labelled "a Perl community", and we need to respect that. They could still appear on our map, but labelled "here be dragons".
Almost none of this came from me: it's assembled from bits and pieces I've picked up from others over the years, and then percolated through my brain.
Thank you to John Anderson, Rik Signes, Chris Prather, and others who commented on drafts of this and shared their ideas, which have been further weaved in.
It was John Anderson ("genehack") who first said to me "There is no #Perl community", and while I didn't really agree with him at the time (this was 2014, in response to another blog post I wrote on community), it planted a seed.
I'd read about the concept, but it was Rik Signes who introduced me to Popper's Paradox.
comments powered by Disqus