This is a part of FESCo Elections interviews series.
Voting is open to all Fedora contributors. The elections started on June 22nd and closes promptly at 23:59 UTC on June 28th.
Please read the responses from candidates and make your choices carefully.
Feel free to ask questions of the candidates here or elsewhere!

Interview with Stephen Gallagher (sgallagh)

What is your background in Fedora? What have you worked on and what are you doing now?

I’ve been using Fedora since Fedora Core 2 (and prior to that, Red Hat Linux since 5 or 6). I joined as a contributor in 2008 when I was hired by Red Hat. I was one of the original developers of the System Security Services Daemon and worked on that for several years.
I have served on FESCo off and on since 2011 and have worked on several projects in that time, including SSSD, FreeIPA, rolekit, Cockpit and others. I am a member of the Fedora Server Working Group and its current FESCo liaison.

Do you think Fedora should be time based or more feature driven distribution? Or compromise?

We’ve tried both in recent memory and neither approach has shown itself to be substantially more beneficial than the other in terms of the quality of what we deliver.
That said, When we switched to a feature-based schedule, we ended up slipping more than we historically had, resulting in disappointment from our users (as we were stuck with many older packages for longer).
Given Fedora’s “First” Foundation, I’m somewhat more in favour of aiming for a time-based schedule in order to try to deliver new functionality to our users faster. I think also it aids in our planning, as if we hold ourselves to our stated time (like we did in Fedora 23), people trust our schedules more and will naturally align with them.
So, I suppose I’m in favour of continuing in Fedora 23 and 24 what we got back to in Fedora 22: a tightly-held time-based schedule and a willingness to defer features that aren’t ready rather than slipping to accommodate them.

What are the most pressing issues facing Fedora today (from engineering POV)? What should we do about them?

I think our biggest issue in Fedora is being able to adapt quickly to changes. Fortunately, I think we’ve made some great strides in that over the last eighteen months. A lot of the rel-eng and QA tooling work that was done alongside the Fedora.next effort has gotten us closer to an environment where we can make quick course corrections. I think we need to continue to focus on that, especially in the rel-eng space (thinking about Fedora Atomic in particular).

What are your interests and experience outside of Fedora? What of those things will help you in this role?

My primary interests outside of Fedora (in all its wide and varied meanings) are spending time with my family and reading a good science-fiction or fantasy novel or playing video games. None of these things directly assist me in my FESCo role, but they provide a necessary counter-balance that keeps me mostly sane.

Anything else voters should know?

People often believe that FESCo is a committee of decision-makers, which is true to a point. But it’s also a committee of advocates; people who are representing the needs of the developer community in Fedora. I think it’s important to have representation of all of the “doers” as our former FPL would have called you.

How can FESCo do a better job communicating with the rest of the Fedora community, or do you feel that FESCo is already doing well here?

Communication needs to be a two-way street. I think FESCo generally does a pretty reasonable job of communicating the decisions it makes to the wider community, but I think sometimes that communication is one-sided. Fedorans need to feel more comfortable bringing topics directly to our attention (vs. hoping that we see their valid complaint amidst a flamewar on devel@). I’d like to see more of our community attending the FESCo meetings and piping up (at least during the Open Floor section).

What can you accomplish as part of FESCo that you couldn’t accomplish as a contributor to Fedora without sitting on FESCo?

FESCo is ultimately where the technical direction of Fedora is set. Without having been on FESCo (and having access to the pulpit that implies), I doubt I could have gotten very far with my original suggestions about delivering Cloud, Server and Workstation Editions. I’m not suggesting that I’m planning to propose anything that drastic again soon, but being on FESCo gives me a certain platform from which to raise big questions and have them given due consideration.
Furthermore, a seat on FESCo will help me accomplish my duties for the Fedora Council, as I am the steward of the three-edition effort there.

With the advent of Fedora Council now, what do you see as the significance of FESCO in Fedora project?

As with any good organization, I think the Council and FESCo form excellent divisions between strategy and tactics. The Council defines the overall strategy of the Fedora Project, but it is not the right body to define the tactics taken to accomplish that strategy. While there may be some overlap of membership, I think it makes complete sense to have them act as separate units.
In short, the Council decides both that we should do something and why we should do it, while it’s FESCo’s job to figure out how and when.

Do you think FESCo can help with the reduction of the backlog of >400 packages awaiting review?

Well, there are many ways to define “reduction”. Certainly, FESCo could wave its collective hands and declare that all packages were [granted|denied], but I assume the question really being asked is “Do you have any ideas for how to streamline the package review process?” (or possibly, “How can we get more people to perform reviews?”)
The first question there is getting better all the time; With tools like fedora-review and fresque in the works, we may be able to get to a point very soon where we may be able to reduce the review requirement to little more than a license check with an automated review. (This is an over-simplification, but I believe that a great deal of review is automatable).
The second question is far more difficult, and it’s a side-effect of having a purely volunteer review group. Obviously, packages that are being produced by Red Hat and other corporate entities tend to get into the package collection faster because those organizations can sponsor the reviews (in one way or another). This is a great deal harder for individual contributors outside of a corporate environment. We probably need to be able to incentivize potential reviewers better; maybe we can take advantage of Badges and fedmsg in some way. Perhaps guarantee the top N reviewers over the last year funding to travel to Flock? Just an idea.