This is a part of the FESCo Elections Interviews series. The voting period starts on Thursday, 28 May and closes promptly at 23:59:59 UTC on Thursday, 11 June.
Interview with Chris Murphy
- Fedora account: chrismurphy
- IRC nick: cmurf (found in #fedora-qa #fedora-devel #fedora-workstation #btrfs)
- Fedora user wiki page
Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?
I see FESCo as a technical equivalent to Mindshare. A significant mandate is outreach, within the community and beyond. And it does this by establishing technical direction, policies and infrastructure resources so that Fedora developers and projects can succeed. I tend to see choices as being less about right and wrong at face value, but more about their consequences. This means asking questions, listening, and making sure each proposal gets a fair shake, as well as clearly understanding its immediate and on-going impact.
How do you currently contribute to Fedora? How does that contribution benefit the community?
I’ve been a member of the Workstation working group for one year. And for a long time I’ve been a contributor in Fedora QA, helping discovering bugs and setting them free. I also help triage user problem reports on linux-btrfs@, and often promote and recommend Fedora there, and wherever else I get the opportunity.
Btrfs has been an active area of interest for me since the very beginning. I stumbled on it at the same time i stumbled into Fedora. While file system choice is a decision left up to the working groups, it is a prime example of a technology with mixed messaging in Fedora that FESCo should resolve. Some technologies could better use guidance, direction, have expectations and constraints set, rather than a mere thumbs up or down vote.
I also have a long track record, in and out of Fedora, bridging user and developer perspectives, a.k.a managing consternation. User frustration is a real and valid signal, but isn’t best directly experienced by developers. And users often under estimate the difficulty of fixing simple problems.
How should we handle cases where Fedora’s and Red Hat Enterprise Linux’s needs conflict in an incompatible way?
Deliberately. I expect and encourage downstreams to influence Fedora. Pre-judging an outcome is a trap and a disservice to both interests.
Modularity? Red Hat has a need, and Fedora might have a similar need but with a dissimilar implementation requirement. Or impediment. A new team has formed to evaluate and make forward progress. What will they discover and recommend? And how do we ensure the community simultaneously has the relevant information to evaluate it, without becoming overwhelmed out of the gate?
Dist-git change? I agree with the statement in FESCo ticket #2383. Specifically, I think it’s in-scope for FESCo via the change process to ensure the required functionality Fedora needs are being met. I disagree that there was a mere failure to communicate: at the start it was announced the Open Decision Framework (ODF) would be used, but then that process was abandoned midstream. A central feature of ODF is that while some folks may be disappointed by a decision, they won’t be surprised by it. And now there’s compounded surprise in the Fedora community as a consequence.
What else should community members know about you or your positions?
When I first started using Fedora, circa Fedora 12, I primarily used macOS. And now I’ve used Fedora as my primary OS since Fedora 25.
My base instinct is to be contrarian, and yet my base process is logical. This is an attempt to neutralize bias, and start evaluation from a position of knowing and assuming nothing.
I’m not a fan of “change for the sake of change” but innovation is hard work, and sometimes you have to take a chance and stick your neck out. I encourage more of the bravery and sense of adventure at which Fedora excels, and is even envied.