This is a part of Env and Stacks 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 Nick Coghlan (ncoghlan)

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

I came to Fedora by way of Red Hat, as I became a Fedora KDE Spin user (migrating from Kubuntu) within a few months of starting with Red Hat in June 2011.
My main volunteer involvement with Fedora development has been through the Python SIG, by helping align distro level efforts (such as the Python 3 migration) with the upstream Python community, and by ensuring that the distro perspective is taken into account in upstream design decisions (such as the way the upstream pip bundling was structured to allow for unbundling in the Fedora system package).
My main paid involvement has been aiming to better align automated QE efforts between Fedora upstream and RHEL downstream, including advocating for the establishment of the service as a path towards establishing public automated hardware integration testing in Fedora (rather than continuing to rely on Red Hat’s private Beaker instance), and helping to ensure that analysis tools like rpmgrill are designed in such a way as to be amenable to deployment in Taskotron.

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

Directly relevant to my interest in the Environments & Stacks working group is the fact that I’m a current CPython core developer, and responsible for approving new interoperability standards in the Python packaging ecosystem.
Less immediately relevant, but useful as background information, are the fact that I’m a current Director of the Python Software Foundation, have spent the last 4 years working for Red Hat on its “project to product” workflow automation (deploying internal services to RHEL and supporting RHEL and Fedora client systems), and before that spent 12 years working for Boeing Defence Australia as a software developer and system architect.

What are your Future plans ? Is there anything what you can consider as “Mission Statement” in this role?

My main objective in participating in the Environments & Stacks working group has been to help redesign Fedora’s packaging review process to not only meet the needs of operations teams that need to ensure the stability of existing services (as it already does today), but also to meet the needs of development teams that need to rapidly deliver new features and new services in order to meet the needs and expectations of their users.

What are the most pressing issues facing Fedora today? What should we do about them?

I think the most pressing issue facing Fedora is one that faces all current Linux distributions that aren’t exclusively focused on the enterprise data centre: cross-platform open source developers using any languages other than C and C++ tend to view Linux distributions as an obstacle to be worked around rather than as potential allies worth collaborating with.
For many open source developers, using a Linux distro as their personal desktop is currently no friendlier to their preferred workflow than using a proprietary POSIX-inspired operating system like Apple’s Mac OS X (or even a non-POSIX OS like Microsoft Windows), which allows the non-development related aspects of the proprietary ecosystems around the latter platforms to dominate their decision making process.
My draft Aleph proposal at represents my suggestion for a possible way forward that retains all of the benefits of the existing review process (thus continuing to meet the needs of operations teams), while introducing new aspects that better account for the interests of developers writing and maintaining rapidly evolving software and services.

What interests you from Env and Stacks, and which projects would you contribute to?

My main focus would be on figuring out how to turn the general concepts of the Aleph proposal into concrete changes to Fedora’s processes and tooling, by way of Fedora’s existing change management process. While I would aim to use the Python software distribution ecosystem as a reference example (as that is both the ecosystem I know best and the one where I have the most influence), I would also aim to ensure that any proposals appropriately accounted for the interests of other software development and distribution ecosystems (including language independent ecosystems like those around nix and conda).