Delivering Bad News: Helping your community through a rough patch
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 39 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/67206 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSS Backstage 202238 / 39
2
9
11
15
26
30
36
37
00:00
Source codeBeta functionOpen sourceProjective planeOpen sourceComputer programmingData managementIncidence algebraWeb pageShared memoryConnected spaceProcess (computing)BitLecture/ConferenceMeeting/InterviewComputer animation
01:41
Open setGraphical user interfaceStreaming mediaNumberData managementMultiplication signPosition operatorProjective planeEndliche ModelltheorieDifferent (Kate Ryan album)View (database)MathematicsWindowEnterprise architectureOpen sourceMedical imagingDecision theoryQuicksortWordBitDependent and independent variablesSelf-organizationBlogEuler anglesRevision controlDistribution (mathematics)Video gameUtility softwareWeb browserMereologyOrder (biology)Fiber bundleSoftwareComputer animationJSON
06:16
EmulationProcess (computing)WhiteboardProjective planeDecision theoryPoint (geometry)Data managementRight angleObject (grammar)DiagramOpen sourceMereologyDependent and independent variablesInsertion lossQuicksortFlagWordEmailBitBuildingMultiplication signLevel (video gaming)Distribution (mathematics)Speech synthesisMessage passingTelecommunicationNumberMathematicsJSONComputer animationXML
14:34
Position operatorCASE <Informatik>1 (number)Revision controlProjective planeSpeech synthesisOpen sourceDependent and independent variablesLie groupSelf-organizationBitDressing (medical)Rule of inferenceWindowMessage passingDifferent (Kate Ryan album)Process (computing)HypermediaFeedbackMathematicsTwitterMultiplication signTrailChecklistEmailStatement (computer science)Right angleBackdoor (computing)Traffic reportingWave packetDisk read-and-write headMoment (mathematics)Point (geometry)Data managementComputer animation
22:52
Open sourceWhiteboardExpected valueProcess (computing)Multiplication signDecision theoryDependent and independent variablesData managementElectronic mailing listEmailLattice (order)Chemical equationCausalityTwitterBuildingInformationMereologyEmbargoShared memoryAddress spaceFormal languageBus (computing)CASE <Informatik>Mechanism designBitOpen setData conversionNumberPoint (geometry)MathematicsMoment (mathematics)Group actionWordProjective planeDemosceneQuicksortView (database)WritingValidity (statistics)Perspective (visual)Computer animation
31:10
Right anglePattern languageVideo gameProjective planeOpen sourceArchaeological field surveyConfidence intervalData managementFamilyExpected valueRevision controlSoftware bugLatent heatType theoryMathematicsAttribute grammarSoftwareMereologyDependent and independent variablesCASE <Informatik>Commitment schemePoint (geometry)PlanningMultiplication signLecture/Conference
36:10
Source codeComputer animation
Transcript: English(auto-generated)
00:04
So, thank you all for your patience, and I'm going to be talking about making your open source project angry, which is something that I'm very good at. Until two weeks ago, I was the community manager for the CentOS project, and I made
00:25
my community angry. So, I'm going to talk a little bit about that. A disclaimer up front, I am no longer the CentOS community manager. I didn't lose my job because I made the project angry, so there's no connection there. But I have moved on to AWS since the incidents that I'll be talking about in this talk.
00:47
So I'll start by telling you a short story. Back in 2013, I was working for another company you may have heard of, SourceForge,
01:01
and I was the community manager for SourceForge. And while I was employed there, my employer announced a new program that would be a way that open source projects that were hosted on SourceForge could get some of the profit that SourceForge was making from those projects.
01:23
And the way that this would work is projects on SourceForge would get a small share of the ad revenue that came from those pages that were hosted on SourceForge. Now, some of you may remember this incident. This wasn't so terribly long ago.
01:42
Unfortunately, this was really badly received by the community because of the way that it was implemented. In particular, what SourceForge did in order to cover some of this revenue was bundle third party software in with your open source project when people downloaded it.
02:00
And this may be the part that you remember if you can think back 10 years. You would download something from SourceForge, and then all of a sudden you would have new toolbars in your browser or you would have some utility running in the background. And this was very poorly received. Yeah, that's putting it lightly.
02:22
Now, as the community manager at that time, I was the recipient of much of this displeasure from the community. I wasn't the one that made the decision. I wasn't the one that implemented it, but I was the face of the decision. So when you are working in an organization like that and
02:41
you are the public face of something, that response comes to you and perhaps the company can hide behind you a little bit. So that may not be the story you were expecting to hear. Let me tell you a different story. In December of 2020, I posted this to the Sentos Project blog.
03:07
And again, some of you may have seen this in the news. The Sentos Project is a Linux distribution that is 19 years old. And it is a rebuild of Red Hat Enterprise Linux.
03:20
So you get the Red Hat Enterprise Linux, they strip out all of the branding and rebuild that and release that for free with a ten year support window. What we announced was that the project was going to be changing its model so that it was no longer downstream from Red Hat Enterprise Linux but was an upstream. The support window was dropped from ten years to five years.
03:44
And the existing Sentos Linux 8 was going to be end of life, eight years earlier than was anticipated due to the change of various timelines. This was extremely jarring to the community, and they were exceedingly angry.
04:02
So once again, I want to remind you that I'm not here to talk about that decision. I'm not here to talk about why we made that decision. I'm not here to defend it, and I don't speak for the project anymore, despite my wardrobe saying otherwise. I even have the Sentos socks, but I no longer speak for the project.
04:26
I notice that none of my images are loading, and I have very clever images. Take my word for this. Some of my images are loading. Anyway, so here are some tips. If you are in any sort of leadership position in a project,
04:44
if you represent a company that sponsors a project, if you are some way seen as the spokesperson for a project, here are some things that I recommend if you make your community angry. And the very first thing, and I'm gonna repeat this a million times because this
05:01
is the most important one, is remember what hat you're wearing. Remember what role you are playing. Now, as a community manager for a project, there's a number of different models for being a community manager. The way that I have always viewed the community manager position is that I represent the community first, that the views of the community are foremost.
05:28
And when the views of the community conflict with the views of corporations involved, the community is right. And that attitude has implications.
05:40
When you speak to your management, that has implications. You may be telling your manager that they are wrong, and that can have implications. So it's very important to think through this before you get into the situation. So that when you are in the situation, you already know what you're going to say. You already know whose side you're going to take.
06:15
Sorry, I'm looking for my speaker notes. Shoot, I'm looking for my speaker notes and they're not showing up.
06:21
But that was the main point here, is remember which hat you're wearing. Another aspect of this is to remember whose side you're on. Now this is subtly different from what I was just talking about. And it's important that you are not confused as to whose side you're going to
06:40
take. Remembering which hat you're wearing is about which voice you are using in public communication. Whether you are speaking for the project, or if you're speaking for your employer, or if you're speaking as a private individual. And remembering whose side you're going to take
07:03
is a bit of a conundrum. Because if you ever get yourself in a situation where you're presenting an us versus them, then there's something broken about your relationship with the project. If your company ever views the open source community as the adversary,
07:23
then there is something broken about your company's relationship with the project. And that's going to be a red flag that you need to watch for when you hear those kinds of words in internal conversations. So one of my favorite words that I've heard over the last 20 years
07:43
is when a company has an open source offering, and they refer to the non-customer users as the freeloaders. That's one of my favorite words. Because that indicates that these are people who are less important than our customers. So that's one example of a red flag that you might look for.
08:04
There are many others. One of the things that I observed when we made the Sentos community legitimately angry for a number of reasons, they had a good reason to be angry. And we have this notion in psychology of the stages of grief.
08:25
When there is a grief experienced, and that's not necessarily just a death. It can be a loss of a job. It can be the loss of a beloved open source project. The first thing that we saw was people saying, clearly this is a poorly timed joke.
08:42
Is this an April Fool's joke? Is this somebody trying to make fun of us? This can't really be happening. And when it is recognized that, yes, this is actually happening, the next response is anger. And I was sort of the lightning rod for that anger.
09:03
My company was also a place where that anger was placed. It results in a loss of trust. It results in people saying they're going to switch to some other distribution. All of these are legitimate responses.
09:21
And as the recipient of some of that, it's very easy to just dismiss those responses. Clearly they didn't understand, I need to explain it better. But acknowledging that the anger is justified is an important step in dealing with the anger of your community. If you start by assuming that the anger is unjustified and
09:44
it's just because they're too dumb to understand, then you are taking a, you're guaranteed that you're going to make the community even angrier. We also had a lot of bargaining where they were saying, well, can you change this?
10:01
And I'll talk about that in just a minute as well. And this lovely diagram of how the stages of grief work is obviously oversimplified. Real human emotion is much more complicated than that. It's very, very important to not get defensive.
10:26
And when you make what you believe to be the right technical decision in your open source project, and it's received poorly, you need to listen. You need to listen to the objections. You need to take those objections seriously.
10:43
And you need to assume that people's experience is legitimate. It's not just that they're wrong or that they're stupid. That is their experience. That is what they are going through. It's also important to remember that if you stick to your decision,
11:05
those people may never accept that it was the right one, because to them it wasn't. So again, this is part of accepting people's experience as being legitimate.
11:23
So referencing my first point, once you start getting defensive and saying, I'm right, you're stupid, I'm right, you're wrong. Then you're violating that first principle. You're forgetting whose side you're on. And as a community manager, it is your job to be the voice of the community.
11:45
Not necessarily just your job to say, these are the decisions of my leadership, of the board, of the company. It is your job, even when you don't necessarily agree, to be the voice of the community.
12:01
And to take that voice of the community and advocate for them. That's your job. So being a community manager can be very conflicting, because sometimes you find yourself carrying a message that is not your own. That not necessarily one that you agree with, but you have to advocate strongly for that.
12:23
And of course, listen, spend most of your time listening. I spent most of last year listening to grievances. And then taking those grievances to management and saying, this is what the community is saying. And this is what the community believes that we need to do about this.
12:49
Acknowledging grievances does not necessarily mean that you are agreeing with them, but it does mean that you are listening enough to understand them.
13:00
And that's the critical part here. You're not just saying, parroting back, copy pasting comments from Reddit. It's actually understanding what is behind those grievances, and this relates back to those stages of grief. A lot of the responses that we got in the Sentis community were rage and
13:22
betrayal, and you had to sit with that and listen and eventually understand what exactly the objections were beyond the initial anger. And that takes time, it takes listening and patience, and it takes trust building.
13:47
Now, when you're a community manager, when you are a board of directors member, when you are representing the community in some way, it's important to remember and remind yourself frequently,
14:05
particularly when you have really angered the community with a decision. It's important to remember that their anger is not personal against you. Even when you receive those emails calling you terrible names and worse, it's important to remember that their anger is not directed at you personally.
14:24
And this is part of trust building. If you have established trust in the community, then people will eventually come back after that angry response. And this happened to me again and again. People would come back and they would say, I'm not angry at you personally.
14:41
But in the moment, it feels very personal. It is personal, open source is very personal. It's a thing that we do out of passion, large percentages of the time. And so it does feel very personal when a project that you believe in makes a change that you passionately disagree with.
15:01
It feels very personal. So the next thing you wanna do is look at my extensive checklist about how to talk to the press. Now, hopefully, if you are in a public facing position at a company,
15:22
you have received your company's best press training, and you know how to talk to the press. But this is always the first rule in talking to the press. Now, I say this a little bit tongue in cheek, but, and I should note that almost everyone in the press that I have ever dealt with has been
15:42
ethical and reported well and truly and tried to understand the situation and report it accurately, but there are people in the press who just like a splashy headline, and there are people in the press who have
16:00
a particular vendetta against a particular organization. And so there were people that I encountered that would say, here's a chance to get back at Red Hat for that thing that they did ten years ago. And there are people like that out there. And so, depending on what corporation you work for, there's somebody out there that is in the press that hates you and
16:22
is looking for ways to undermine you, and they'll twist what you say. That is tiny minority of the press, but that time that that happens to you, it can be very damaging to your project, to your company, to your personal reputation. So if possible, when you are approached by the press,
16:45
make sure that you talk with your publicity department, that you make sure that your response is truthful, is accurate, and that you don't respond in anger.
17:00
Now, we have this illusion about social media that it's a different thing. If I say something on my personal social media, that's different from the thing that I say on my official social media, right? Those are completely separate things. And the fact is that you don't get to choose how your message is received.
17:24
And so you have to remember which hat you're wearing. And you have to remember that your audience doesn't know which hat you're wearing. So that's a critical distinction there. You may think, I am speaking with my official project voice, or
17:42
I'm speaking as an individual, and that your audience can tell the difference. And that's a myth. So this is the philosopher Socrates who famously said, there is honor in the tweet not sent. This is closely related to the famous quote from Confucius who said,
18:04
there is honor in the email not sent. There are so many times when I have written a tweet and then not sent it. And this can be cathartic, as long as you remember not to press that button.
18:22
And there is also times when I've gone ahead and said the thing, and then you have to deal with the fallout from that. Because people take what you say as an official statement from your company, however you intended it yourself. You're always wearing all of your hats. You may think that you have been clear about what hat you're wearing, but
18:44
you weren't. There is no way that your audience knows what hat you think you're wearing. Now, I said this on Twitter, you're always wearing all of your hats. And one of my friends and
19:02
former colleagues, Theo Schlossnagle, responded with this, which is basically, if there is a difference between how you talk with your different hats on, then maybe you should consider getting a different job. If there is such a disconnect between your different hats,
19:22
then that may be an unsupportable cognitive dissonance that you might want to deal with, rather than trying to differentiate your two opinions. This is my opinion when I'm at work, but when I'm at home, I think the opposite. Chances are you're gonna slip up and send a tweet from the wrong account sometime.
19:42
And I assume you've all done that at some point. I'll also quote this other theologian, wait, no. Always tell the truth. Now, this may feel like it's in conflict with some of the other things
20:05
that I've said, and all of these things are held in tension. But when you speak to your community, it is critical that you tell the truth. And there are many reasons for this. The most obvious of them is that you should always tell the truth.
20:21
The less obvious ones are that your community is smarter than you are. There are people in your community who know more about your technology than you do. There are people in your community that understand more about your company than you do. There are many cases in which your community is smarter than you are.
20:44
And they're not fooled. If you try to mislead, if you try to shade the truth slightly, they're not fooled. And they will fact check, and they will show you, and more importantly, show the press and your competitors and the rest of the community,
21:02
that you're trying to mislead them. When you're a community manager, your only asset is trust. When you are an open source project, your only asset is trust. If people cannot trust you, then everything else is just window dressing. And so it is important to tell the truth.
21:23
Now there are cases when you cannot tell the whole truth, either because you don't know it or because there's some reason that something is confidential. So first of all, if you don't know the answer, don't pretend that you know the answer. Don't just give whatever answer comes off the top of your head.
21:43
Because, again, that will be perceived as an intentional lie. This can also be difficult when the story changes. We received community feedback. We've changed the message, was what I said before a lie?
22:01
No, you need to be able to communicate. This is why we changed the story. And also understand that some people will still perceive that as intentionally misleading, and it's just your job to be honest. The other path of this is if you don't know the answer and
22:23
you just say, I don't know, that's not the end of the story. It's your job to go find the answer and then communicate that in a way that addresses the concern of your community. I've kind of lost track of how much time I have left. Okay, now the other place where you cannot tell the truth
22:46
is when you have been instructed for some reason not to tell the truth. I don't mean mislead, I mean there are facts that you cannot share. Either because maybe there's a CVE that's under embargo, or maybe because part of the story is confidential company information.
23:04
And in those cases, you have to say so. You have to say, I can't answer that question, and here are the reasons that I can't answer that question. Or maybe I can't even give you the reasons. I've seen, so in American English, there is this notion of throwing
23:21
someone under the bus, which is a way of saying, I am going to blame someone else so that this situation doesn't land on me. And I've seen a lot of community managers, rather than taking responsibility for a situation, they'll blame someone else.
23:43
They'll blame their company. They'll blame their bad management. They'll blame the faraway CEO who is disconnected from the situation. And that doesn't solve any problem. It may remove the blame from you a little bit, but that in turn causes other problems. It shows that you're not willing to take responsibility.
24:01
It shows that you yourself are not trustworthy and are going to betray a co-worker. And the most important thing is that it doesn't actually solve the customer's problem, the end user's problem, the community's problem. It's just blame. Blame does not solve things.
24:22
So it is critical to be able to take that responsibility and to be able to say, I'm sorry, I simply can't answer that question. It's not something that I am able to do, and there are always valid reasons for that, and people understand that, I think.
24:42
I spent last year rebuilding trust. Because of the decision that we made in December of 2020, we burned a lot of community trust. And it was my job to reestablish that trust. Now some of the things that I did to reestablish that trust were open up our
25:01
community governance to a larger, to make it more public. Open our board meetings to public attendance. Open up our board mailing list to public view. These sorts of things were intended to show that what we're saying is in fact what is happening behind the scenes.
25:22
But when you burn trust, then even that is in question. Because they're saying, well, maybe you're having that conversation yet another place, and maybe you're being the puppets of whoever. So building trust is not something that you can just say, trust me,
25:40
I'm telling you the truth. No, it's something that you build over time by demonstrating that your words coincide with your actions. That takes an enormous amount of time, and it is just so easy to lose. You can lose trust in a moment, but building trust takes years.
26:03
Here was an interesting one. Early on, after we made this decision, people would come to me and say, well, can't you just change that back? And there's a temptation in that moment to say, well, let me talk to management. Let me take your concerns to management.
26:21
I'm sure I can convince them to change it. And the reality is that if you promise a change that you cannot deliver on, then you have increased your broken trust. And so this can feel, and a number of people told me this all the way at the beginning of this conversation, it can feel very harsh
26:45
when someone says, can't you reverse that decision? And you say, there is 0% chance that that decision is going to be reversed. That feels very harsh, to be that honest. Maybe there's a more tactful way to say that, and I did try to say that more tactfully.
27:02
But don't promise things that you don't think you can deliver. Because that does not rebuild the trust in any meaningful way. And then finally, I would encourage you not to get fired.
27:21
And I've thought a lot about this point here, because the last time I gave this talk, I had somebody from the audience saying, well, sometimes there are things that are worth getting fired over. And you have to think about what those things are before they happen.
27:41
Because there are things that are worth getting fired over. There are things that you should take a stand on. So I encourage you not to get fired though, if you can avoid it. Don't send that angry response before you've had time to think about it.
28:04
Write the angry response. I do this all the time, this is a coping mechanism for me. I write the angry response and then I don't send it. I encourage you though, if you write the angry response, don't put the to address in the to field until you're actually ready to send it, because that does not end well.
28:25
But I process by writing. I think by writing, and so writing those responses. And then going back and reading them and thinking, how would I read this if I was the one receiving it?
28:41
Wow, that sounds really, really harsh. How would I read this if English was not my first language? Well, that sounds really harsh. And then really taking the time to ensure that your response is truthful, and constructive, and isn't about working out your anger.
29:03
It's not about you, it's about community building. When you're the voice of a community, you cannot afford to make your responses personal. You cannot afford to send that sarcastic tweet
29:22
that just feels so good to make that nasty joke in the minute. And then people remind you of years later, you said this awful thing. So it's always this, like I say here, it's always this balancing act between ensuring you understand what your priorities are, ensuring you know what hat you're wearing,
29:43
ensuring you know whose side you're on, and balancing that with your personality. Because as a community manager, as a community advocate, your personality is, of course, a large portion of your trust. People trusted me in that role because of who I was,
30:02
not because I was wearing a red fedora. And so that balancing act is something that you constantly have to go back on and think through, and don't get fired by saying dumb things. So that's kind of my perspective on what you should do when you make your
30:23
community angry. I hope that none of you make your communities angry in quite the elaborate ways that I have. But there's going to be a decision that your project, your employer is going to make that is not well received because we don't see deeply into the minds of all of our users all of the time.
30:44
And so, yeah, I think I might have a minute for questions. Yeah, sure, we have a minute for Q&A, and there's some of you who want to ask a question, I'll start in the front.
31:00
Isn't that also just expectation management? Like people having really sometimes wrong expectations towards open source projects, especially, they kind of believe that the project owes them something. Yeah. Even though the project is just a bunch of volunteers doing stuff on a voluntary base, so maybe we should start from that expectation management.
31:21
Yeah, that's a really good point. And creating transparency over who's behind it, how do they earn their money, how much time do they have for that, are they being paid for that, and why are they being paid for that? And then taking that as a starting point for whatever explanations or journey or changes that you want to promote. So in the case of the Sentos project,
31:44
We had been aware for many years that the community believed that there was a ten year promise on every release. That promise was never made, it's never stated anywhere. But that's sophistry, we knew that the community believed that.
32:03
And we allowed the community to keep believing that. So this is expectation management, you've got to clearly communicate what your promises are. And when people believe something to be a promise, when people believe that their bugs will be fixed in 15 minutes or less, then you have to say, this is not something that we promised.
32:22
So that when that situation happens, people aren't suddenly shocked. So yeah, expectation management is a pretty critical part of this, definitely. So there was another two questions, right? How do you distinguish the people who are just vocal and against and
32:44
angry from the people who actually accept the change? Is there any way to approach those people who are actually supporting your change and maybe make them more influential in the situation when things go wrong? Because those people who are angry are always the loudest, I think.
33:03
That's true, and so when a community responds in anger, it can be easy to be confused as to whether that's the whole community or whether it's two loud people. In the specific scenario I'm talking about, it was the whole community, and
33:20
I'm confident of that, but yeah, it can be very easy to hear a few loud people that are signal amplifying and think that it's the whole community. And that's difficult because surveys in open source are notoriously terrible because the people that are happy don't respond. The people that are not happy respond loudly and
33:42
get their friends to join in on the message, and that's difficult. And I'm not sure how to do that unless you are deeply connected with the community. And so part of being a community manager has to be daily deep commitment with the community so that you know who the real voices are and
34:02
you know who are the people that are just agitators. Just a small follow up, wasn't that a good idea to prepare for that and prepare the agents of change? Because that's something that you could foresee. Yeah, and there's certainly things that I would do differently if I had this
34:21
to do over, that was not an option. But yeah, if you are expecting a change, telegraph intent is one of the phrases that I've heard. Make sure that you talk about your intent far in advance. And so you can judge from that what the response will be. Even if you don't change your plan, that you know what's coming.
34:46
When I heard the talk, I thought isn't basically every situation in life kind of community management? I mean, I've seen all those patterns, for example, with my kids, right? Expectations, and anger, and all that other stuff.
35:01
So, and I would say your talk was excellent, but could be applied to basically every situation in life where people conflict. Do you think there's something very special to open source projects with distinction to, for example, conflicts with colleagues, or conflict with family, or something? Is there something really open source project specific you would highlight?
35:22
No, I don't think that this is specific to open source. I think that's very insightful. I've been reading a book recently called The Art of Community by Charles Vogel. And one of the most compelling things about the book is that it's not about software, it's not about technology, it's about community, and
35:40
the attributes of community that are universal. And so, yeah, when I make my daughter angry, we go through all these same things, you gotta tell the truth. You've got to not pretend that you're going to give her the birthday cake at bedtime.
36:03
So yeah, I think you're exactly right. All of these things apply to any type of community.