Recently, two separate people called something myself and other Fedora Design Team members worked on “crap” and “shit” (respectively) on devel list, the busiest and most populous mailing list in the project. ???
Actually, I’ve been around the internet a long time, and I have to say that this is an improvement in terms of the rudeness being applied towards the work specifically, and not the people!
Progress!
Yeah ok, but, we clearly still have a lot of work to do on basic decency. It’s not Fedora, it’s not the free and open source community, it’s not the internet – it’s people. Maybe people at a communication scale for which we’ve not quite evolved yet. Let’s talk about one way we can think about approaching this issue moving forward.
(* I realize I used the term “trolls” in the title of this post, and I wouldn’t consider this scenario an intentional instance of trolling. However, this post is about a framework and not this specific scenario, so I use “trolls” as a more generic term.)
What about the Code of Conduct?
Codes of conduct set a baseline for expectations, and we certainly have one in Fedora.
Well… I’m a parent, and we know well that simply having a set of rules doesn’t mean it will be followed. Nor does enforcing consequences for violations of said rules neatly and cleanly ensure future compliance.
No, what is critical is how you respond to the transgression, both as the rule-setter but importantly also as the target.
I’m not saying codes of conduct don’t work. I’m just saying that they are not the whole solution!
I’m not blaming the victim and saying they’re responsible. I’m just saying if they want to, there are things they can do and laying them out.
Alright. Cool. So…. how do you respond to the transgression? You and your team spent weeks, months working together on a project, and now it’s getting, well, ? on. What then?
Try resiliency
I have been working through a University of Pennsylvania online course on resiliency that was recently made free as in beer due to its applicability in the COVID-19 pandemic we’re all dealing with.
(Yes, internet trolls really are not as dire as some of the issues many of us are going through right now that this generous offerings was meant to try to help – death, sickness, food insecurity, job insecurity, isolation, and more. But no, there’s no reason why we couldn’t apply the framework taught in the course on something stupid like trolls as practice for the heavier things!)
The course is called Resilience Skills in a Time of Uncertainty and it is taught by Karen Reivich who is a professor at the University of Pennsylvania. She is an engaging instructor and the course materials are put together extremely well. I’m going to walk you through what I’ve learned so far, directly applying it to the devel list ? party as an example so you can see what I mean by suggesting resiliency as a piece to the puzzle of making our community a nicer place to be.
Thinking traps
So you’re facing a ? feedback situation. Someone called something you worked on “shit” on devel list! The horror!
Dr. Reivich identified five “thinking traps” you might find yourself falling into as a response to such a situation. Note that your thoughts in response to something can determine the outcome! Our language and thought become our reality! By understanding thinking traps we might fall into, we can be more self-aware when they happen and intervene so that we don’t fall into the trap (which in this case might involve blasting back on the mailing list and igniting a flamewar that could last for weeks… no, that would never happen…)
Right, so, here are those five thinking traps:
1. Mind-reading
You’re falling into the ‘mind-reading’ thinking trap when you try to read the minds of others without actually asking them what they think. You could get all caught up into a fight or flight type of confrontation over a mere conjecture over what someone might possibly be thinking – and they weren’t even thinking that, which you’d know if you’d bothered to ask…
To apply this thinking trap to the devel list ?, one could think:
“He said our work is crap! And this other guy said it’s shit! I bet they think I’m crap. I bet they think the whole design team is just a bunch of crappy people making crappy artwork.”
2. Me
This trap is about placing blame on yourself entirely for the situation. It’s all your fault. You suck, and this is what you deserve. Maybe you’re an imposter. People think you know what you’re doing, but you’re just clueless, and you’ve been found out.
To apply this thinking trap to the devel list ?, one could think:
“Yep, it is crap. It is shit. It’s my fault, because I suck. I am not good enough, just don’t have the skills to pull this off. Not only that, I sucked my teammates down my pit of incompetence and now they’ve been embarrassed unnecessarily because of me. I’m not a real designer, clearly my taste is shitty!”
3. Them
This trap is about placing blame on “them” for the situation. It’s all “their” fault. “They” sabotaged you. If it weren’t for “them,” things would have gone just fine!
To apply this thinking trap to the devel list ?, one could think:
“Clearly, they have no taste. Their mama didn’t raise them right, to say such a thing! They just come on the list and rant and complain, but did they actually get involved and help? Nope. This is their fault. You can’t just fly in like a seagull and crap all over our work and then fly away. You have to pitch in and help.”
4. Catastrophizing
This trap is about making a mountain out of a molehill, blowing the scope of the situation out of proportion ad infinitum.
To apply this thinking trap to the devel list ?, one could think:
“Yes, it’s crap, it’s shit. Everyone thinks so. Fedora 32 is going to go out, and everyone is going to assume it’s crap because the wallpaper is crap. Our number of users will drop. People won’t want to use it, because how could you use a Linux that has crappy wallpaper? It’ll cause such a drop in users that Red Hat will cancel Fedora. F32 could be the very last Fedora ever!”
5. Helplessness
This trap is about shutting down in response to the situation. Maybe you’ve tread this road before, and you’ve just got no more fight to give, so you give up. You might just walk away and refuse to resolve it. As a free / open source contributor, you might decide to never come back to that project, or even try to make a contribution to any project at all again. Nah, that’s never happened. ?
To apply this thinking trap to the devel list ?, one could think:
“They think what I worked on is crap and shit. OK. I had fun working with the design team, and I thought what we came up with was great. I guess this just isn’t the community for me, though, when they treat each other like this. There’s nothing I can do except move on.”
The danger of these thinking traps
Your thoughts build your reality. Some potential realities born from the above thinking:
- Flamewar: You start thinking these dudes called your whole team and their work crappy, you start reacting as if they actually did – when they never did.
- Underemployment: You start believing that you suck and have poor or no skills, and start acting that out – and miss out on opportunities!
- Blind Hate: You blame others in your head, you act out that thinking – then you make enemies and miss the opportunity to better yourself by digesting any of the validity to the feedback they gave.
- Stress City: You stress yourself out needlessly, cortisone coursing through your veins over extreme scenarios that are not likely to play out.
- Run Out of Town: You get driven away from a community, which not only hurts you from being able to participate in it, but hurts the community from not being able to retain great people like you.
What good does this do me?
You probably are familiar with at least some of these thinking traps. Cool. But how does knowing what they are help with the whole ? issue?
It’s very useful to be able to identify these thinking traps as you find yourself starting to fall into them. You can catch yourself, and be a little more conscious about your thinking. If they were literal traps, being able to identify them as you start approaching them means you’ll be able to sidestep them and avoid mauling an appendage!
Sounds good. So how do you side step all this ??
Real-time resilience
Dr. Reivich calls the three techniques to “side step” these thinking traps “real-time resilience.” These techniques are (with applications towards the ? scenario:)
1. Evidence
Examine the data you have around the situation and yourself.
For example:
- Mind-reading: They didn’t actually call me and the other members of my team who worked on this crap or shit. They called the work itself crap and shit. While that’s not the best or most productive language, they didn’t make it personal.
- Me: This isn’t my fault and I don’t suck. I have a graduate level degree in HCI and an undergraduate degree in digital art. I have over 15 years of experience. This is the 32nd release, and I’ve had a hand in the wallpaper for 26 releases.
- Them: Not everyone has the skills or training necessary to contribute design work, but everyone certainly has an opinion. While this is late in the game, they are providing feedback, and we ask users to test things like the wallpaper pre-release to give us feedback. No, it’s not the most productive feedback, but it is feedback, and we do ask for that.
- Catastrophize: If the wallpaper being unpopular caused Fedora as a project to fail, we would have failed a long time ago since this isn’t the first wallpaper that was unpopular with some people.
- Helplessness: These two people do not represent the entire project.
2. Reframing
Think of a more helpful way to interpret the situation.
For example:
- Mind-reading: Just because they don’t like the wallpaper doesn’t mean they don’t like me and my team. They probably wouldn’t have used that language if they actually even thought of us.
- Me: Can I flip this situation into an opportunity to practice graceful reaction to harshly-worded feedback, something I’ve been working on personally to better myself?
- Them: They don’t like the wallpaper – but maybe they weren’t capable of expressing it an appropriate way. They cared enough about it to post it where it would get some attention instead of keeping it to themselves, and you could hope that would be because they wanted it to be addressed and not that they wanted to publicly flog anyone.
- Catastrophizing: The opinions of two people on a mailing list are not a representative sample, so even if the imagined catastrophe were feasible, there’s just not enough – in quantity and forcefulness – feedback to indicate the reception would be such a disaster.
- Helplessness: People on the list called those two posts out for being against the code of conduct. There are people who care.
3. Plan
Come up with a plan for what you’ll do or what will happen if your thinking is true.
For example:
- Mind-reading: If I’m right and they do think I and my team suck, I will start (maybe should have done this anyway) a “we rock” file that collates all of the amazingly positive feedback the team has gotten for the wallpaper and other design work over the years. What is the big deal if two humans think we suck, anyway?
- Me: If it really is me, and I really do suck at what I do, I’ll find someone skilled that I trust and ask them for honest feedback and mentorship. I might run through a few tutorials or take a class to brush up.
- Them: If the problem really proves out to be them, then I can take steps to distance myself, including setting up filters and blocks.
- Catastrophizing: If the wallpaper really threatens to cause the end of Fedora, we could release an update that forcefully changes the wallpaper, and/or put together some simple tutorials that show how you can pick and choose your very own wallpaper and set it as your background.
- Helplessness: If I really am not welcome in the project, there’s tons of other ones looking for design help and I could definitely find one. It wouldn’t be the same, but getting driven out of one project doesn’t mean I can’t participate in any.
Reset your thinking
- Examine the evidence.
- Reframe the situation.
- Make a plan.
It’s only three steps, and you don’t even have to do all of them – just one can help reset your thinking and save you from falling into a trap. You can then keep a cooler head and handle the situation more gracefully and avoid some of the unpleasant realities that could be borne from trapped thinking.
Conclusion
I do think this resilience framework is a useful tool for dealing with conflict in an free & open source community setting. I might even suggest that maybe training contributors in this methodology and/or socializing it within the community could help us better respond to issues as they arise.
It certainly helped me handle a ? party!
I haven’t finished Dr. Reivich’s course yet (I just completed the week 2 coursework today with this blog post, haha, as I trickily used a homework assignment prompt to write this all), but if more comes up that applies and I can work it into an assignment I’ll blog more on it. I definitely recommend it thus far.
To Fedora and Mairin Duffy-
From: Peter V Daniels
In the Midst of the current social situation regarding the Pandemic and the Leadership role Linux is currently maintaining in the World I’d say the beautiful Graphic Arts work is to the contrary and will be recognized throughout history as a catapult to the Linux World and Free software community. May I run on sentences with this note all, the hatefulness is only a reflection of the successful work.
Sincerely Peter V. Daniels
Thank You and Linux, Fedora, for such a professional OS thats Just Unbelievable…………..
Thank you for sharing and your work on Fedora. Stay strong and healthy.
There is an issue that needs addressing: the Fedora Design Team should really step up and deliver the *final* artwork in a *timely* fashion *well before* each and every deadline. Late delivery (even after being called out) has happened for several Fedora releases now. And that is bad and must change.
It’s not ok for an “artwork is done, please submit package” email to sit in someone’s inbox for weeks without any action in spite of a looming and well known deadline. When the non-delivery was pointed out in a BZ, I found the reaction of said person lackluster and void of any sense of urgency. I’m happy that there are some real blocker bugs holding up the release of F32 because it would have been extremely emberassing if F32 had to be delayed because someone didn’t read his email…
Now I don’t know the people in the Fedora Design Team so I can’t tell what’s really going on and why. From my outsider perspective I’m disappointed this happened (again) and would urge the FDT to do some introspection, learn and improve. And if that means we get a timely-delivered black background with F33 than that’s fine with me.
The artwork is *not* late. The artwork was late *once* several releases ago for a pre-release. You are making an upsetting and completely false claim that my team is habitually late with our work and we absolutely are not. I do not know where you got this misinformation from, but you need to stop spreading it.
Let me step in and clarify a few things here:
1. We wouldn’t have delayed F32 release for the wallpaper. Until the go/no-go meeting we were planning to accept the bug as a blocker, but waive it under the “late blocker” policy that says we can waive blockers proposed very late in the process under various circumstances (see https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases ).
2. We have had issues with the timing of the backgrounds *package* several times, as opposed to the *artwork* itself. The final images were delivered some time ago (Pagure is not giving me the exact date, but the approximate one is “a month ago”: https://pagure.io/design/issue/669#comment-637176 ), but the first update with the final images was not submitted until 2020-04-10, which is pretty late. It is true to say we’ve had issues with the packaging not being lined up until very late in several releases, and this does frustrate me a bit, if I’m honest. There are two problems I see with this part of the process:
i) there’s just one person doing all the packaging work, and he’s a volunteer who has a full-time job to handle as well
ii) the packaging process for backgrounds is way too complicated. Updating the backgrounds involves touching three different source packages and both comps and kickstarts. It all seems way over-engineered. (It also doesn’t appear to be scripted/automated at all, it’s all done by hand). But because of i), the process hasn’t been overhauled for a long time.
“Updating the backgrounds involves touching three different source packages and both comps and kickstarts.”
Whoops, not to mention the “upstream” project that backs one of the packages! That has to get bumped and branched and tagged too…https://github.com/fedoradesign/backgrounds
Also previous issued with packaging of the artwork + timing were pre-release, not final.
To me “artwork” is a package in the Fedora(+1) repository. Perhaps it has a different meaning to you i.e. the non-packaged artwork. In that case we are talking about different things. All I have to go on is if and when the packaged artwork is present in the repository. From Adam’s comments it’s clear that quite a lot is involved before the packaged artwork shows up. So that probably needs fixing/automating.
I recall that for various releases some prodding was required for the artwork to show up in the repository. The earliest (2016) I could quickly find is BZ 1379459 were artwork not being present in the image needed a Freeze Exception. That makes 3 times and that may or may not be “habitually late” depending on who you ask but 3 times certainly is not “misinformation”.
You’ve come here to a blog post about the actual *artwork*, not the package, to tell me that my entire team working on the artwork is responsible for not just this one single instance of a packaging snafu in a final shipping Fedora (which as far as I have been able to tell, and yes I have looked into it based on your comment because I take such feedback seriously, and from my 15 years in the project didn’t recall such a thing being the case) is actually a habitual lateness in my team’s assets being delivered and that it has blocked multiple final releases.
We have had some packaging issues that have been restricted to pre-release versions. The one time I am aware of that is confirmable that the artwork was late was for an alpha release some years ago. We have not had an alpha release in some years and go straight to beta. That will help you understand how long ago this issue was.
I have spent time off I could have been with my family, time when I was on medical leaves with newborn babies making sure that the *artwork* for Fedora was delivered on time. Understand when you come here to my space to inform me that my team’s deliverables are habitually and consistently late in the face of that, let’s say causes just a little bit of cognitive dissonance.
As Adam has already explained, packaging something as simple as a set of PNGs is unnecessarily difficult in Fedora, this is an ongoing problem that I am sure you would agree a team of artists is ill-equipped to fix, and we have pleaded for help with this on multiple occasions but have not gotten any support. If you could offer that support, we would gratefully appreciate it.
And yes, saying that my team has blocked multiple final releases of Fedora is, in fact, MISINFORMATION. Backing down from your claim with qualifications that certainly do not apply to final releases and did not cause ANY Fedora release, final or otherwise to be late DOES NOT change the facts.
Hi Màirìn, thank you a lot for this post! Though I’m still new to the Fedora project, I’ve been using Fedora since ~24/25, and I loved each one of the backgrounds so far, and I really like this one ! In several instances, I loved some of them so much, that I downloaded them before their release ! My favorite being 26.
I silently watched the whole thing unfold in the list, and I think that it really was unfair, to the art and to yourself. The new background is great, the noise doesn’t bother me, actually, I think it adds a lot to the art and these shades of blue, especially the twilight one, are perfect in my opinion.
And, the beauty of art is, at the end, only an opinion. It is perfectly normal for people to express different feeling about an artwork. For example, some in the mailing list expressed their preference to Ubuntu’s wallpapers, while I personally hate it.
Also, in order to avoid this sort of “? party” again, releasing the artwork for rawhide releases (=> when Fedora n-1 is released, example, releasing a new background for 33 when 32 is released) could be a good idea, so the maintainer of the package has more time and fellow grumpy devel-list writers could engage and give feedback to the process (because changing the background now is practically impossible) ! So, the ideation-creation phase could stretch the whole rawhide 6-month period by releasing several beta-backgrounds/snapshots and then be fixed on a final version the day of the release… But that would ask a lot of work…
Also, please make the “””secret””” artwork name… well… less secret ! I didn’t know either that it was a thing, and it HAS to be made more widely known (maybe as a return to release name) !
With that, I hope I have landed in the «we rock» file ♥ ! You have been excellent at the Design Team all these years !
Thank you for the kind comment 🙂 Your idea is actually exactly what we have in mind for F33 and we’ve already started on it. 🙂 We were meant to much earlier but had to delay a bit since I was on medical leave for almost a full release cycle.
You are doing God’s work and I need You to continue. And the people who say this to You? Fuck the whole lot of em
Interesting post. I’m not a Fedora user; I simply happen to stumble across here while reading about riot.im IRC bridge. 🙂
A lot of problems in this world can be solved when people stop blaming one another, and start taking responsibility for their own feelings. I’ve written a similar article (describing my own approach) here: https://www.srid.ca/1930301.html
I’m not convinced that’s an entirely neutral way of expressing the opinion, which gets to the root of how it’s not quite so simple to put into practice.
Congratulations on your post. In my country, I still see this type of behavior with users who are contributing to the community. I’m happy to see how you deal with it and also share the experience. Thank you.