{{admon/important|The nomination period is CLOSED. The nomination period ended at 23:59:59 UTC on May 15, 2012.}}

+

−

For the last election, see [https://fedoraproject.org/w/index.php?title=Development/SteeringCommittee/Nominations&oldid=268106 NominationsNovember2011]

+

These members were elected in the [https://admin.fedoraproject.org/voting/results/fescof18? last elections]:

−

In the May 2012 election, there are 5 seats open. Open seats are currently held by: [[Development/SteeringCommittee/Nominations#Kevin_Fenzi_.28nirik.29|Kevin Fenzi]], [[Development/SteeringCommittee/Nominations#Bill_Nottingham_.28notting.29|Bill Nottingham]], [[Development/SteeringCommittee/Nominations#Peter_Jones_.28pjones.29|Peter Jones]], [[Development/SteeringCommittee/Nominations#Stephen_Gallagher_.28sgallagh.29|Stephen Gallagher]], and [[Development/SteeringCommittee/Nominations#Tom.C3.A1.C5.A1_Mr.C3.A1z_.28t8m.29|Tomáš Mráz]].

+

* [[User:Kevin| Kevin Fenzi]] (nirik)

+

* [[User:Notting| Bill Nottingham]] (notting)

+

* [[User:Pjones|Peter Jones]] (pjones)

+

* [[User:jwboyer|Josh Boyer]] (jwb)

+

* [[User:Tmraz|Tomáš Mráz]] (t8m)

−

== Introductions ==

+

+

As per the [[FESCo_election_policy|FESCo election policy]], the following finish their terms, and the seats are up for re-election:

+

* [[User:Mitr| Miloslav Trmač]] (mitr)

+

* [[User:Limb| Jon Ciesla]] (limburgher)

+

* [[User:Mjg59| Matthew Garrett]] (mjg59)

+

* [[User:Mmaslano|Marcela Mašláňová]] (mmaslano)

+

+

More information at the FESCo [[Fedora_Engineering_Steering_Committee|wiki page]].

+

+

<!--{{admon/important|The nomination period is CLOSED. The nomination period ended at 23:59:59 UTC on May 15, 2012.}}-->

+

+

For the last election, see [https://fedoraproject.org/w/index.php?title=Development/SteeringCommittee/Nominations&oldid=290360 NominationsMayJune2012]

+

+

{{admon/note|Eligible Voters|Voting eligibility is determined by a community member's Fedora Account System ([https://admin.fedoraproject.org/accounts/ FAS]) memberships.<br/> <br/>To vote for [[Fedora_Engineering_Steering_Committee|FESCo]] you must have cla_done + one other "non-cla" group in FAS.}}

+

+

== Candidate template ==

+

=== Introductions ===

* '''Mission Statement:'''

* '''Mission Statement:'''

Line 23:

Line 46:

* '''Future plans:'''

* '''Future plans:'''

−

== Questionnaire ==

+

=== Questionnaire ===

−

The community has submitted the questions that it wants you to answer. The list of questions is here: [[F18_elections_questionnaire#Fedora_Engineering_Steering_Committee_.28FESCo.29|F18_elections_questionnaire#Fedora_Engineering_Steering_Committee_.28FESCo.29]]

'''Please do not answer them on the wiki'''. Please email your answers to [[User:ankursinha|Ankur Sinha "FranciscoD"]] at '''ankursinha AT fedoraproject.org by May 22 2012'''. All the candidates' answers will be collected and put up together before the town halls.

+

<!--{{admon/warning|CLOSED|The questions have not been posted. Please wait for the questionnaire wrangler to contact you!}}-->

+

<!--{{admon/important|Questions are up!|The community has submitted the questions that it wants you to answer}}-->

+

<!--{{admon/important|Emails sent!|The election wrangler has sent out emails with the questions. Please contact him/her if you haven't received an email yet!}}-->

+

<!--{{admon/warning|Candiates, don't post your answers yet|Once the questionnaire period is over, the Elections Wrangler will collect the answers and post them at the same time. This attempts to make things more even and fair for candidates to be open with their answers and not copy from earlier responses.}}-->

+

{{admon/warning|CLOSED|The answering period is now closed (after November 18 2359 UTC). Received responses are below:}}

−

The answering period has expired. The responses have been put up below:

+

* What skills do you bring for FESCo?

−

+

* Where do you see Fedora in the next year?

−

* '''What will you be able to accomplish if elected, that you couldn't as an unelected coontributor? Why this post?'''

+

* Where do you see the Fedora Project in five years?

−

* '''What can be done to get more features and make more progress? Have you participated in any features before?'''

+

* What is your priority for Fedora?

−

* '''What do you think about spins? Do we still need them or will they become obsolete once we have a new anaconda with better package selection?'''

+

* What are your thoughts on the Feature process?

−

* '''Do you think the issues FESCo discusses and the decisions FESCo makes are effectively and efficiently communicated throughout the Fedora community? If you believe communication between FESCo and the Fedora community can be enhanced, what first steps or ideas would you propose?'''

+

* What will you be able to accomplish if elected, that you couldn't as an unelected contributor?

= Candidates =

= Candidates =

−

== [[User:Pjones|Peter Jones]] (pjones) ==

+

== [[User:Sgallagh|Stephen Gallagher]] (sgallagh) ==

=== Introduction ===

=== Introduction ===

* '''Mission Statement:'''

* '''Mission Statement:'''

−

** I'll continue to work to maintain a high level of technical feasibility and avoid micromanagement in decisions made by FESCo. I'll try to streamline our processes for developers, and to avoid processes that result in unnecessary work, or in duplication of effort. As I've shown in the past, I'll continue to try to guide our policy decisions to put the power and responsibility in developers hands rather than requiring FESCo's or other committee's intervention and participation at every level.

+

** Make Fedora THE platform for rapidly developing the next generation of free, open-source software.

−

* '''Past Work Summary:'''

+

* '''Past work summary:'''

−

** I've worked on Linux for Red Hat for more than a decade in various roles including technical support and engineering. I'm one of the anaconda maintainers as well as the maintainer of (thankfully now deprecated) mkinitrd, and am or have been maintainer Fedora's packages for booty, cdparanoia, dumpet, gnu-efi, grub, python-pyblock, syslinux, and others. I've worked on many levels of our software stack, including implementing installation and boot support for iSCSI, UEFI, dmraid, from the kernel all the way up through userspace. I'm currently a member of FESCo seeking re-election, and have been serving in this capacity since the winter election of 2009.

+

** Red Hat employee since 2008, developed the System Security Services Daemon, participant in the FreeIPA project. Currently advising the OpenLMI project and working on packaging Node.JS and its dependencies. Fedora Hosted admin maintaining ReviewBoard. Working with the OpenShift developers to host tools for use with Fedora such as Gerrit. Former FESCo member from June 2011 - 2012. Currently employed as the BaseOS Architect at Red Hat.

−

* '''Future Plans:'''

+

* '''Future plans:'''

−

** I'm currently focused on implementing and impoving UEFI support throughout Fedora, as well as supporting various storage technologies. As a FESCo member I'll continue to help ensure that developers have what they need to implement their features and bug fixes with as little hindrance as possible, and at the same time avoid unnecessary and wasted effort.

+

** Continue to drive Fedora to become the best platform for developing exciting new technologies for the desktop and datacenter.

=== Questionnaire ===

=== Questionnaire ===

+

* ''' What skills do you bring for FESCo?'''

−

* '''What will you be able to accomplish if elected, that you couldn't as an unelected coontributor? Why this post?:'''

+

I am currently employed as the BaseOS architect for Red Hat. My full-time job at this time is to facilitate collaboration between different open-source projects and help them avoid duplication of effort as well as resolving disputes between projects with competing technologies or goals.

−

** Being on FESCo presents a different kind of involvement than just being a contributor does. It's an opportunity to help set direction and get directly involved with broader decisions, and to ensure that Fedora is headed in the right direction on a technical level.

+

−

* '''What can be done to get more features and make more progress? Have you participated in any features before?:'''

+

* ''' Where do you see Fedora in the next year?'''

−

** I've participated in the "Feature" process as an end user, as a feature owner, as somebody working on features others own, as a FESCo member approving (or dis-approving) features, as an agent provocateur attempting to affect change in the process, and probably some other roles. I think our biggest obstacles to more and better features are generally with the mechanisms we use to capture information from developers; we're heavy on demanding feedback, and light on doing so sensibly. In fact, the current feature process is still largely centered on "50000-foot" style progress reporting, with little room for nuance or understanding from whoever is receiving that feedback. It's a show, and it's discouraging to developers.

+

−

* '''What do you think about spins? Do we still need them or will they become obsolete once we have a new anaconda with better package selection?:'''

+

In the next year, I anticipate that we're going to see a significant shift in Fedora. The technology ecosystem is shifting from its classic development model of reinvent-the-wheel compiled languages into the more dynamic world of web applications built atop dynamic infrastructures

−

** I think they're a neat idea, but right now there's not a lot of attention that's been paid to how they're implemented. We definitely need more people looking at this.

+

such as Django or Node.JS. Fedora has always represented the "will of the people" and will be adapting to these new development styles.

−

* '''Do you think the issues FESCo discusses and the decisions FESCo makes are effectively and efficiently communicated throughout the Fedora community? If you believe communication between FESCo and the Fedora community can be enhanced, what first steps or ideas would you propose?:'''

+

* ''' Where do you see the Fedora Project in five years?'''

−

** FESCo makes an effort to assure that not just our decisions but also our deliberations and rationale are accessable to everyone inside and outside of Fedora, but at the same time, I think there's always room for improvement on things of this nature.

+

+

I see Fedora refocusing on its core strengths over the next five years. We've spent a long time being everything for everyone, and it's become clear over the last several months of devel@ mailing list discussions that this isn't working for us and is not sustainable. My view of the five-year future is that Fedora is going to simplify its plans and shift back towards being a platform distribution as opposed to a software distribution.

−

== [[User:Sgallagh|Stephen Gallagher]] (sgallagh) ==

+

* ''' What is your priority for Fedora?'''

−

=== Introduction ===

+

I have two primary goals in mind for Fedora:

+

# I want Fedora to be the distribution that software developers are *excited* to use for the development of the Next Big Thing.

+

# I want Fedora to provide a powerful and extensible platform for doing that development.

−

* '''Mission Statement:'''

+

* ''' What are your thoughts on the Feature process?'''

−

** Make Fedora THE platform for rapidly developing the next generation of free, open-source software.

+

−

* '''Past work summary:'''

+

The Feature process is too bureaucratic in some instances while being simultaneously toothless in other situations. For example, there are many Features that come in that are simply rubber-stamped into the distribution because they were raised as Features simply to be added to the Release Notes and Talking Points. I think we should have a separate process for these additions that should be handled by FAmSCo instead, since this is more an evangelizing task. The purpose of Features should be constricted to dealing with those changes that have impact throughout the Fedora Project; it should address those tasks that require coordination among multiple projects or those whose slippage could delay releases.

−

** Red Hat employee since 2008, Lead developer of the System Security Services Daemon, participant in the FreeIPA project. Fedora Hosted admin maintaining ReviewBoard. FESCo member since June 2011

+

+

Additionally, there are Features that are approved without a sufficient understanding (or communication) of the risks involved. Features such as the recent Anaconda mass changes that have significant likelihood of slipping the release should be communicated out to the community very carefully ahead of time. Such enormous changes should be communicated throughout the community and effort made to involve the whole community *early on* to do what they can to facilitate the Feature so that we minimize the risks of slippage.

+

+

* '''What will you be able to accomplish if elected, that you couldn't as an unelected contributor?'''

+

+

In my role as a facilitator, my efforts will carry more weight if I am part of a team whose job it is to enable the creation of a unified product. I can negotiate between teams with the additional influence that a position on FESCo can provide.

+

+

== [[User:Limb|Jon Ciesla]] (limb) ==

+

+

=== Introduction ===

+

+

* '''Mission Statement:''' To further the goals of the project and Free Software in general by helping enable contributors to bring the highest quality and most diverse collection of software to the distribution. I'm fully committed to the goals of Free Software, for ideological, but also primarily technical reasons.

+

* '''Past work summary:''' I've been a Fedora user since RHL 7.1, and an active packager since 2007, as well as a sponsor and member of FESCO and the FPC. I initially focused on games and php applications, but have expanded to other things over time. I also encounter and deal with many of the issues we encounter as a project in the course of my day job.

+

* '''Future plans:''' Ideally, I'd like to find ways to encourage and educate new contributors. I've sponsored a few new packagers, but would like to help shorten the time from first interest to active packager, and can only do so much on my own. I also have ideas and opinions on many areas FESCO addresses, including the Feature process, and would like to continue to contribute what experience I have to those conversations. I'm also very much interested in helping ARM achieve Primary architecture status, and have been doing a bit of work towards that goal.

−

* '''Future plans:'''

−

** Continue to drive Fedora to become the best platform for developing exciting new technologies for the desktop and datacenter.

=== Questionnaire ===

=== Questionnaire ===

+

* '''What skills do you bring for FESCo?'''

−

* '''What will you be able to accomplish if elected, that you couldn't as an unelected coontributor? Why this post?:'''

+

Many years of Linux use and administration experience, several years experience as a Fedora packager and developer, and both work and Fedora leadership experience.

−

** Having a voice in making FESCo policy decisions will allow me to act on my stated goal of making Fedora into a powerful platform for the development of open-source software.

+

−

* '''What can be done to get more features and make more progress? Have you participated in any features before?:'''

+

* '''Where do you see Fedora in the next year?'''

−

** I have participated in the development of multiple features (including two for the forthcoming Fedora 18). I think the best way to encourage more features is for Fedora as a whole to pay close attention to upstream work and call it out in the Features list when those deliverable dates line up with Fedora Feature Freeze. Progress is made when we are proactive about incorporating upstream enhancements and collaborating with those upstreams to take it one step further.

+

−

* '''What do you think about spins? Do we still need them or will they become obsolete once we have a new anaconda with better package selection?:'''

+

I think we'll see ARM become a primary architecture, and continue to advance the progress of free software with the latest and best software. We'll work out the kinks in our feature process, and grow the community.

−

** I think spins will still have value in the form of live-media creation. There will always be groups who will want to produce a live Games or Disaster Recovery disk, and I think we should continue to provide them with the tools to do so.

+

−

* '''Do you think the issues FESCo discusses and the decisions FESCo makes are effectively and efficiently communicated throughout the Fedora community? If you believe communication between FESCo and the Fedora community can be enhanced, what first steps or ideas would you propose?:'''

+

* '''Where do you see the Fedora Project in five years?'''

−

** I think FESCo does a pretty good job of explaining its actions and decisions. Our primary communication method is the devel@lists.fedoraproject.org mailing list, which is read by the vast majority of our contibutors (and is searchable publicly for those who don't read it regularly). Our meetings are held in public and are announced in advance for those who want to attend and our meeting agenda is built from our Trac instance for those who want to add something to it.

+

+

We'll be a technical, if not numerical, leader on the desktop, in the server room, on mobile, in the cloud, and making serious inroads in at least one place that doesn't exist today.

−

== [[User:jdulaney|John Dulaney]] (j_dulaney) ==

+

* '''What is your priority for Fedora?'''

+

+

My day-to-day priorities are fixing FTBFS bugs and updating versions on software important to me. Most of my energy outside of my direct packages has been on ARM FTBFS and SCM maintenance.

+

+

* '''What are your thoughts on the Feature process?'''

+

+

There needs to be a closer relationship between FESCO and feature owners, and the feature submission process needs to begin and end sooner in the cycle. Ideally, I'd like to see each feature assigned to a FESCO member whose responsibility is to act as a patron, or sub-feature-wrangler for that feature, making sure the status page matches reality, that the feature is progressing, and assisting if needed.

+

+

* '''What will you be able to accomplish if elected, that you couldn't as an unelected contributor?'''

+

+

Being a part of FESCO, in my view, gives me greater insight into the technical direction of the Fedora project as a whole, and I'd like to continue that, particularly with regard to me ideas around the feature process.

+

+

== [[User:mjg59|Matthew Garrett]] (mjg59) ==

=== Introduction ===

=== Introduction ===

−

* '''Mission statement:'''

−

** To promote Fedora in my role as an ambassador; to continue to develop test criteria for new features coming into Fedora and evolve the QA process as needed to fit with the evolution of Fedora. I will also strive to make sure that Fedora remains at the forefront of technology and to be the best Free distribution of Linux.

−

* '''Past work summary:'''

+

* '''Mission Statement:''' To help Fedora developers get their work done in such a way that we ship a distribution that benefits our users.

−

** I am a member of the Fedora Quality Assurance team. I help write test cases for new features, I am a proven tester (testing critical path software updates), I test new releases starting prior to branching, and I help establish release criteria. I am also a Fedora Ambassador, especially within the Fayetteville region. I spread knowledge of Linux in general and Fedora in particular and inform people that they do have a choice for Freedom.

+

* '''Past work summary:''' I'm a former Red Hat employee keen on continuing to contribute to Fedora. I've worked on various power management and ACPI features, and have been leading the Secure Boot implementation that's been adopted by most significant Linux distributions. I've recently been spending time on helping with the remaining Anaconda and upgrade issues for Fedora 18.

+

* '''Future plans:''' FESCo exists to enable Fedora contributors to get their work done, providing that that work doesn't adversely affect other contributions or the goals of the distribution. That isn't how it's always been treated recently. I want to focus on returning FESCo to being an enabling group, while simultaneously engaging the community in discussions to fix the various infrastructural and policy flaws that stand in the way of developers.

−

* '''Future plans:'''

−

** Strive to improve the testing of Fedora; both personally and collectively throughout the QA team, to continue to educate people on the advantages of Linux and Free Software, and to continue to test Fedora.

=== Questionnaire ===

=== Questionnaire ===

+

* '''What skills do you bring for FESCo?'''

−

* '''What will you be able to accomplish if elected, that you couldn't as an unelected contributor? Why this post?''':'''

+

I'm an experienced developer with detailed knowledge of how most system components fit together. I've worked on the kernel, and I've worked on desktop applications. I've worked on pretty much everything in between, too. I've also been involved in the development of other distributions, so I don't approach issues with the inherent assumption that the existing Fedora solution is necessarily the best.

−

** As a member of the Engineering Steering Committee, I am able to more directly influence future technologies that make their way into Fedora. I will also be able to add a different and new perspective to the Steering Committee, having not served on it before.

+

−

* '''What can be done to get more features and make more progress?''':'''

+

* '''Where do you see Fedora in the next year?'''

−

** We should actively search for new technologies that make good candidates for inclusion in Fedora, as long as they meet our guidelines. On the other hand, why not be the originator of some of these ideas? Fedora's contributors offer a wealth of knowledge that could be tapped to develop new technologies to meet emerging needs within the computing world.

+

−

* '''Have you participated in any features before?:'''

+

With luck, back to regular release cycles that can benefit from the infrastructural work that's been carried out this cycle. I don't imagine

−

** Probably the most I've been heavily involved with is btrfs. I have helped write test cases and guide feature owners through the process of getting their features QAed.

+

that there'll be massive changes. ARM may have reached the point of being a primary architecture.

−

* '''What do you think about spins? Do we still need them or will they become obsolete once we have a new anaconda with better package selection?:'''

+

* '''Where do you see the Fedora Project in five years?'''

−

** Spins are exceedingly useful pre-compiled collections of packages. I do not think that they will become obsolete considering that there isn't room on the standard install DVD.

+

−

* '''Do you think the issues FESCo discusses and the decisions FESCo makes are effectively and efficiently communicated throughout the Fedora community? If you believe communication between FESCo and the Fedora community can be enhanced, what first steps or ideas would you propose?:'''

+

Where I'd *like* to see the project in five years is a place where people spend more time developing and less time arguing, but that might be a fundamental outcome of our community model. There'll probably be even more focus on cloud than there is now, and I expect that ARM will have been a primary architecture for a significant period of time. I'd hope for less infrastructural churn in the lower levels of the distribution - we'll have rewritten everything enough by then that we should finally have got it right.

−

** I really do not think the problem is in the system in place. The system that already exists allows fairly easy and painless communication between the community and FESCo. Just because the easy communication exists, however, does not mean that it is used effectively by either party. There is also the consideration that the committee may not decide in a way that the community member wants.

+

+

* '''What is your priority for Fedora?'''

−

== [[User:Kevin|Kevin Fenzi]] (nirik) ==

+

Pragmatic technical excellence.

−

=== Introduction ===

+

* '''What are your thoughts on the Feature process?'''

−

* '''Mission Statement:'''

+

It's currently mostly pointless. There's no way to mandate that development goes through the feature process, and most of what does is doing so purely so a box can be ticked somewhere. Our failures to communicate development aren't helped by getting people to fill out forms.

−

** To make sure Fedora continues to lead the way.

+

−

* '''Past work summary:'''

−

** Have been on FESCo a long time. Red Hat employee for 1 year. Currently head of Fedora Infrastructure. Active in many parts of Fedora to assist others and reduce roadblocks to getting things done and having fun.

−

* '''Future plans:'''

+

* '''What will you be able to accomplish if elected, that you couldn't as an unelected contributor?'''

−

** I'd like to make sure we have a smooth on-ramp for bringing ARM folks into the fold. I'll work on adding more Fun back into Fedora and see if we can streamline some of our processes.

+

+

Vote in FESCo decisions. If you trust my judgement, elect me. If you don't, don't.

+

+

+

== [[Miloslav Trmač]] (mitr) ==

+

=== Introduction ===

+

+

* '''Mission Statement:''' Make Fedora work better for its primary purpose as a distribution - to turn various differing upstreams into a consistent and well-integrated whole.

+

* '''Past work summary:''' Contributor since RHL times, worked on many things including a tcsh internals rewrite, initscripts, pyrpm, switch from MD5 to SHA-256 hashes in RPM and other places, audit work from the kernel to GUI layers, volume_key, encrypted disk support in libvirt, kernel's crypto interface, and the Fedora signing server. Used to be a heavy-duty translator into Czech.

+

* '''Future plans:''' Fedora is often the place where packages affected by changes other packages first interact, and handling this well is critical for fulfilling the above-mentioned primary purpose of a distribution. To that end, I plan to work on improving the Feature process, and otherwise improving the handling of changes that affect other packages and ensuring distribution-wide consistency - while making it possible to make successful transitions faster, not slowing change down in bureaucracy. I also generally favor policies that allow quick bug->fix turnaround time and allow more enhancements into released versions of Fedora. Outside of FESCo my interest is in improving security of Fedora.

+

=== Questionnaire ===

=== Questionnaire ===

+

* '''What skills do you bring for FESCo?'''

−

* '''What will you be able to accomplish if elected, that you couldn't as an unelected coontributor?:'''

+

From the technical point of view, probably an above-average understanding of most of the major functional areas of the distribution: For example, I've been doing kernel programming, GUI programming, web programming, I've worked on the old init/network scripts. This was directly relevant to FESCo - looking at the FESCo tickets, I think I've been one of the more active people in researching the technical status/issues/interactions of various proposals.

−

** I think I can provide direction for the various issues that come before FESCo, balancing history (I have been involved in Fedora a long time) vs new advancements (I love the fast pace of Fedora).

+

−

* '''Why this post?:'''

+

From the organizational point of view, I've been on FESCo for the past year, and thus have some understanding of what the pain points are and what the

−

** I'm a technical person, so providing technical direction to the project is right where I want to be.

+

possible solutions might be - certainly more than I had when I started in FESCo.

−

* '''What can be done to get more features and make more progress?:'''

+

* '''Where do you see Fedora in the next year?'''

−

** Gain more contributors. Make sure we keep our focus as the place that Features appear first. Strive to take more credit for the excellent work our contributors do.

+

−

* '''Have you participated in any features before?:'''

+

I want to help with, and have some proposals for:

−

** Yes, I even have one currently for Fedora 18: Xfce 4.10.

+

** More cooperation between maintainers of various packages, resulting in more complete and less painful integration of new features.

+

** Improved processes that "scale" with the task, getting out of the way for simple cases and handling the larger cases better. (See the "Feature process" question for some details.)

−

* '''What do you think about spins? Do we still need them or will they become obsolete once we have a new anaconda with better package selection?:'''

+

I also want to start moving Fedora toward:

−

** I would like to see some way to allow users to install a package collection + configuration (like a spin) via any install method. I think having the seperate images and installs weakens our testing efforts, but I absolutely want to have a way to get our users tested collections of stuff.

+

** Better QA (more automated testing, more involvement of testers in planning of updates and feature integration); in my experience doing such work upfront pays off in the future, especially when a component is faced with a large magnitude of "external" changes, like it is often the case within Fedora.

+

** More agreement on who the primary users and expected uses are, to establish a better common ground for the more controversial technical discussions and decisions that are often primarily disagreements about the users/uses. I don't think these things can happen within a year, but we can make some progress.

−

* '''Do you think the issues FESCo discusses and the decisions FESCo makes are effectively and efficiently communicated throughout the Fedora community?:'''

+

* '''Where do you see the Fedora Project in five years?'''

−

** Sometimes they are, sometimes they aren't. I think we could do a better job of collecting input and announcing decisions.

+

−

* '''If you believe communication between FESCo and the Fedora community can be enhanced, what first steps or ideas would you propose?:'''

−

** A few things that I think would be great:

−

*** Start trying to get someone to summarize devel list threads, including any actions needed.

−

*** Make sure we send email announcements when we decide something.

+

The basics should not change: integrating upstream open-source software into

+

a distribution in a collaborative way, quickly adopting new technologies.

−

== [[User:Affix|Keiran Smith]] (Affix) ==

+

We should get better at it, though - integrating the new things quicker, better and more completely, with fewer surprises and less unexpected breakage.

−

=== Introduction ===

+

Currently a better feature process, and better QA seem to offer the most effective ways to improve. The better QA will take some time to develop, and

+

we will certainly encounter and have to overcome other, currently unexpected, hurdles towards the goal.

−

* '''Mission Statement:'''

+

* '''What is your priority for Fedora?'''

−

** Make fedora The distrobution of choice for aspiring developers and systems administrators

+

−

* '''Past work summary:'''

+

Short-term it is clearly improving the "feature process"/communication mechanisms (see the "five years" question for rationale).

−

** I am currently a Fedora Packager and Ambassador. I Maintain NginX[EPEL], Amarok[EPEL], ZNC, Nagios and more. Was also a member Zikula Insights Team and FES

+

−

* '''Future plans:'''

+

* '''What are your thoughts on the Feature process?'''

−

** I would like to bring forward the effort to make fedora available on more platforms such as ARM and MIPSEL. I would like to see a world where fedora becomes the distro of choice, Where we can run fedora on a wide range of devices such as Routers, Phones, Televisions and alot more.

+

−

=== Questionnaire ===

+

It mostly works well as a marketing device. For technical coordination, there's certainly room for improvement

−

* '''What will you be able to accomplish if elected, that you couldn't as an unelected coontributor? Why this post?'''

+

As a possible immediate improvement, Marcela Mašláňová, Tomáš Mráz, Jaroslav Řezník and me have prepared a [[User:Mmaslano/Feature_process|specific proposal]] that will:

−

* '''What can be done to get more features and make more progress? Have you participated in any features before?'''

+

** significantly improve feature visibility, which alone should make coordination easier and avoid some surprises

−

* '''What do you think about spins? Do we still need them or will they become obsolete once we have a new anaconda with better package selection?'''

* '''Do you think the issues FESCo discusses and the decisions FESCo makes are effectively and efficiently communicated throughout the Fedora community? If you believe communication between FESCo and the Fedora community can be enhanced, what first steps or ideas would you propose?'''

+

** get FESCo more involvement in the integration and quality of more risky features.

+

Over time, I would like Fedora to move towards somewhat higher expectations from package maintainers, at least for the most important packages (at least packages shipped in the default spin, or perhaps in any spin?):

+

** Setting up "release goals" for each Fedora release, where every maintainer is expected to update their own package for some change.

−

== [[User:tmraz|Tomáš Mráz]] (t8m) ==

+

The problematic sysv->systemd conversion is a current example. We can expect similar migration necessary for GTK+ 2->3, Python 2->3 in a

+

not-too-far future.

−

=== Introduction ===

+

Ability to distribute such work across all package maintainers - and to really get it done for the next release - is critical to Fedora's ability

+

to quickly integrate new technologies.

−

* '''Mission Statement:'''

+

** Puting more focus on the already existing package maintainer responsibilities (dealing with bugs, notify others about changes) - perhaps making it easier to become a comaintainer of "problematic" packages.

−

** Keeping balance between contributors making changes and stability and usability of Fedora as a distribution.

+

−

* '''Past work summary:'''

+

* '''What will you be able to accomplish if elected, that you couldn't as an unelected contributor?'''

−

** I've been Red Hat employee and Fedora contributor for more than seven years working on packages related to security (PAM, OpenSSL, libgcrypt, GNUTLS, ...) in both Fedora and Red Hat Enterprise Linux. I am one of the upstream maintainers of PAM. I was FESCo member for the past year.

+

+

Many contributors express opinions on policies, processes and distribution-wide technical decisions decided by FESCo. All of them are heard, but ultimately they are effective through a representative on FESCo, and I'd like to serve as a representative for people who agree with [[Development/SteeringCommittee/Nominations#Miloslav_Trma.C4.8D_.28mitr.29|my mission statement and plans.]]

* '''Past work summary:''' I've contributed to Fedora since the fedora.us days and was a member of FESCo during the merge of Core and Extras. Recently I've been an active member of the Fedora Infrastructure Team working on FAS, PackageDB, and general scripting and bugfixing, worked on Packaging Guidelines as a member of the Fedora Packaging Committee, and have just returned from a stint on the Board. Around alpha release, I can often be seen to step in to get python packages building or work on bugs that have hit the community's radar but aren't important enough to hit a blocker list.

+

* '''Future plans:''' Past FESCo's have streamlined many policies including the updates policy, a fast track for nonresponsive maintainers, and how FPC guidelines are approved. The current and next FESCo are likely going to be tackling an update of the Feature Process. There's been a lot of work around this already. Many packagers have contributed to the [[Fixing_features]] wiki page. FESCo has been discussing issues on the [https://fedorahosted.org/fesco/ticket/896| Refining Features] ticket. I'd like to help organize the identified problems and suggested solutions and incrementally improve pieces of the policy. If we finish that work, it may be time to take another look at improving the non-responsive maintainer policy.

−

* '''Future plans:'''

−

** Fedora must not stagnate and that means substantial changes in the core packages are always happening however we need to keep balance between those disruptive changes and the usability of Fedora as an operating system of choice for software developers and server related work (experimental servers, special servers where the latest software versions are required etc.).

=== Questionnaire ===

=== Questionnaire ===

+

* '''What skills do you bring for FESCo?'''

−

* '''What will you be able to accomplish if elected, that you couldn't as an unelected coontributor? Why this post?:'''

+

** Experience working in groups that are striving to reach consensus (FPC, Fedora Board)

−

** Obviously as the policy decisions and Fedora features are voted on by FESCo to be able to have a direct vote in FESCo will give me better ability to achieve my mission statement.

+

** Large amount of experience with packaging for Fedora. I've been around since the fedora.us days and served on the Fedora Packaging Committee since its inception.

+

** Good python programmer, okay shell scripter, rusty C programmer, for those times when FESCo will need to provide manpower to work on blocker bugs.

−

* '''What can be done to get more features and make more progress? Have you participated in any features before?:'''

+

* '''Where do you see Fedora in the next year?'''

−

** I quite do not think that there are not enough features in recent Fedora releases. Rather I'd like to see the features to be more polished in the final Fedora releases and to be included in rawhide as soon as possible during the release development cycle.

+

−

* '''What do you think about spins? Do we still need them or will they become obsolete once we have a new anaconda with better package selection?:'''

+

There will be incremental changes in the next year. But we'll have started talking about some new, far reaching changes to how we create the distribution. We'll be tossing around ideas like every other release being more like an update release with minimal changes to the core platform and what level of support we want to offer to people creating copr addon repositories for Fedora.

−

** I don't have a strict opinion on spins. I do not use them personally as I am quite advanced user/developer/sysadmin so I can customize the installation on my own. However I can see their usefulness for less experienced users. We should decide based on statistics of spins download/use and also - and that is most important - based on interest of individual spins maintainers to keep developing them.

+

−

* '''Do you think the issues FESCo discusses and the decisions FESCo makes are effectively and efficiently communicated throughout the Fedora community? If you believe communication between FESCo and the Fedora community can be enhanced, what first steps or ideas would you propose?:'''

+

* '''Where do you see the Fedora Project in five years?'''

−

** I think the communication between FESCo and the Fedora community is quite good - the FESCo meetings are public, nobody is denied access to the meetings, also FESCo in case of substantial decisions almost always postpones the final decision after the subject was reasonably discussed on the Fedora devel mailing list (see f.e. the recent discussion about promoting ARM to primary architecture).

+

+

There will have been a few major changes to Fedora by the time we get five years down the road. We have accumulated a lot of processes that aren't working very well (and contrariwise, a lot of things that are working well). I think that similar to no-frozen-rawide, the core and extras merge, and Fedora Core 1, we're closing in on a place of re-evaluation where we're ready to make some changes to how we produce the distribution. I think those changes are going to be evolutionary rather than revolutionary but they aren't going to be small either. The changes that will inevitably come to the Feature Process in the next year are just the first of several of these large changes that we will see.

−

== [[User:notting|Bill Nottingham]] (notting) ==

+

Although it's hard to spot things that are barely on the radar, I think that once the Copr buildservers become available in the next couple years we'll go through several phases of integrating what they offer into our universe of offerings. I would hope that we could get to the place where we offer people who care to work on the side repos some measure of support for providing some sort of full-service to the people who use them. Issue trackers, hosting for them. An automatic way to install repositories, perhaps some way to hook into the Fedora release schedule. However, watching the various secondary arch efforts, I'm not sure that this is where the project will go and if it does, whether it will be able to go there in the next 5 years.

−

=== Introduction ===

−

* '''Mission Statement:'''

+

* '''What is your priority for Fedora?'''

−

** I plan to represent the Fedora community in FESCo with an eye towards maintaining the quality and standards of the Fedora distribution, including features, testing, stability, release engineering, and so on.

+

−

* '''Past work summary:'''

+

Changing the Feature Process. Working on the AWOL maintainers process. Attempting to change the culture of package ownership to be more open to letting people work on things that they are not the owner of.

It was a good first try but it's in need of some revisions. Some of the things that we have been kicking around for a while that I don't think are very controversial to implemment:

+

+

** Make the feature process easier for things that just need documentation and more structured for things that need coordination by making separate processes and templates for each.

+

** Give more power to the Feature Wrangler to approve things that fall into the documentation only set.

+

*** Probably want to get more people to do Feature Wrangling so that approvals at this level don't become a single-point-of-failure

+

*** Write some guidance about how to tell the difference between a feature that is docs only and a feature that needs coordination.

+

+

Those changes will help keep fesco free to deal with and focus on things that may be a problem within a release cycle instead of spreading themselves out looking at many things that merely require an entry in the Release notes if they get done. They'll also clear up some longstanding confusion and maintainer issues where various parts of the feature process don't map well to the particular type of feature that's proposed (Release notes for upgrading the boost library, for instance; the current alpha freeze schedule for leaf packages like the gimp or inkscape).

+

+

I think that people are currently mainly interested in the Feature process because of F19's slippage and unfortunately solutions to that seem to be more controversial or less fully fleshed out. Some of the problems leading to slippage:

+

+

** We let many things go through even though they aren't ready at the milestones that are on the schedule.

+

** We have a theoretical model for people to develop features over muliple releases and only release them into Fedora when they're ready. However, some teams claim they don't have the manpower for this.

+

** We have a theoretical model where people should start developing for the next version of Fedora once rawhide branches. But only some people work on this schedule.

+

+

There are some ideas on fixing these but they all cause somebody pain. We could tell more people to revert their features if they aren't ready in time. We could tell certain critical components that they aren't allowed to push things into Fedora until they're already finished -- or if they go in, they very strictly have to be finished by alpha (or a new milestone before that) otherwise, the team must spend the rest of the cycle reverting their changes and stabilizing for that. We can enforce people doing more work on the branched release by freezing earlier and staying frozen. Then QA and releng would control who was doing work on branched... everyone else wouldn't have the ability to push things to branched so they'd have to work

+

on rawhide.

+

+

I don't think we're quite ready to swallow the tradeoffs that go with any of these so a lot more work needs to happen to find something that will be palatable to everyone.

+

+

+

* '''What will you be able to accomplish if elected, that you couldn't as an unelected contributor?'''

+

+

Hopefully very little :-) Proposing changes to existing policies (which I hope is the most iportant thing I'll be doing) can be done by regular

+

contributors as well as members of FESCo.

+

+

Being a member of FESCo *will* give me the opportunity to vote on Features which I can't do as a regular contributor. However, I am definitely *not*

+

promising to do that job differently than any other member of FESCo currently does. I may ask more questions than the average member of FESCo does but I won't try to filibuster votes with endless questions. I will try to get proposed features modified to seek consensus, but I won't block things if there's nothing further that can be done to make something satisfy more people.

+

+

From a few of the controversial votes in the past few releases, I think I would have voted against several of them (UsrMove, for instance) but voted for others (for instance, SecureBoot). Given the information FESCo was given on the current hot button topic, anaconda's NewUI, I think I would have voted to approve that as well.

+

+

So do not vote for me if you think my voting record on features would have significantly changed what features made it into new versions of Fedora. I'd just be another member of the group charged with making hard decisions that affect the entire project.

+

+

+

== [[User:mmaslano|Marcela Mašláňová]] (mmaslano) ==

+

+

=== Introduction ===

+

+

* '''Mission Statement''': Fedora should be opened for new projects, but we need to work more on inclusion of changes. Features or changes of default shouldn't lead to breakage of rest of the system.

+

* '''Past work summary''': Red Hat employee since 2006. I started as a maintainer of small utilities in Base group and become a Perl maintainer. Currently, I'm working as a supervisor of Languages group. I have almost finished second term in FESCo. My current project is Software Collections, which are able to provide more versions of the same software in a single distribution release.

+

* '''Future plans''': Fedora should provide environment stable enough for development of new features. I'd like to work in FESCo on review of new features and help to communicate between group of developers so the lack of communication does not bring surprises late in the development cycle of release.

−

* '''Future plans:'''

−

** Continue to make Fedora the best freely available distribution anywhere. Work with those that show up to make changes, as, realistically, FESCo does not have a significant amount of resources to direct.

=== Questionnaire ===

=== Questionnaire ===

+

* '''What skills do you bring for FESCo?'''

−

* '''What will you be able to accomplish if elected, that you couldn't as an unelected coontributor? Why this post?:'''

+

I was a Perl maintainer few years, therefore I know a lot about maintenance of projects with huge number of packages in Fedora. I'm aware of problems in our infrastructure during rebuilds. I'm mainly working on interpreted languages.

−

** The point of serving on FESCo isn't so *I* can get stuff done, it's trying to help *others* get stuff done sanely. My goal on FESCo is to help make Fedora better by helping with policies and procedures, asking the right questions of features that are submitted so they integrate better, and so on. It's not directly related to work I might specifically be doing.

+

−

* '''What can be done to get more features and make more progress? Have you participated in any features before?:'''

+

* '''Where do you see Fedora in the next year?'''

−

** I have participated in features off and on in the past, and I am responsiple or adjunct for at least two F18 features so far. "Make more progress" is a little vague - make more progress on *what*, exactly? To have more features, we need more developers interested in doing new features, or coming up with new good ideas for features. The best way to do that is likely to try and grow our development community and Fedora usage by upstream developers; that is only tangentially related to FESCo. The other thing that would help make more 'features' would be to streamline the feature process so that people are more likely to submit their existing work as features.

+

−

* '''What do you think about spins? Do we still need them or will they become obsolete once we have a new anaconda with better package selection?:'''

+

I hope we will be working on stabilization of our distro. The last few releases brought huge changes and many of them weren't finished. I'd like to see more work on bugfixing than new features at least for one release. After release or two we could have a much better distro, but that depends on future features and how they will be done.

−

** Spins will always obviously have a place as demo-ware; it's much simpler to hand a user a disc/stick with "here, this does XYZ" rather than installation media with "here, click ABC and then you'll get something that does XYZ". I'd love to see more spins that are for more targeted purposes than just Fedora X + Desktop Y; a spin for a media server, or an OpenFiler like spin, would be two examples.

+

−

* '''Do you think the issues FESCo discusses and the decisions FESCo makes are effectively and efficiently communicated throughout the Fedora community? If you believe communication between FESCo and the Fedora community can be enhanced, what first steps or ideas would you propose?:'''

+

* '''Where do you see the Fedora Project in five years?'''

−

** I think we trend more towards the 'efficient' than 'effective'; we quickly disseminate logs & meeting minutes, we put information in the tickets, and so on. But that's still a pull mechanism for the users - they have to go to the meeting minutes list, go to the meetbot archives, or read the ticket info. <br\>I would think the first steps for improvement might be making the meetbot archives more prominent, searchable, and easily found so people can find the information they need.

+

+

Sounds like HR question, but okay. I'm afraid there is a possibility that Fedora would break up into smaller communities around different projects. Part of developers and their requests have been ignored (Server, Virtualization, ..). It might happen that Fedora will lose many users if we don't start talking with all projects working within Fedora project. I don't think we should focus on the desktop anymore. The market had changed, for pure desktop usage tablets, macs, or even smartphones are sufficient. Let's provide a strong development distribution, which means cooperate much better in distribution and focus on inclusion of new projects to work well within Fedora.

−

== [[User:jwboyer|Josh Boyer]] (jwb) ==

+

* '''What is your priority for Fedora'''?

+

+

He? If you meant which use-case is a must for Fedora, then Platform for development - easy to pick what you want without many useless dependencies.

+

+

* '''What are your thoughts on the Feature process?'''

+

+

We already created draft of improved feature process. We'd like to start discussion about it very soon. Our draft of Feature process is [[User:Mmaslano/Feature_process|here]]

+

+

* '''What will you be able to accomplish if elected, that you couldn't as an unelected contributor?'''

+

+

As a FESCo member I can decide, which features will be accepted and which won't.

+

+

== [[User:msivak|Martin Sivák]] (msivak) ==

=== Introduction ===

=== Introduction ===

−

* '''Mission Statement:'''

−

** I plan on helping the Fedora developer community accomplish the tasks and goals it puts effort into, while maintaing a well-balanced process and governing body.

−

* '''Past work summary:'''

+

* '''Mission Statement:''' Make sure the distribution stays modular and adaptable to the needs of many different user groups

−

** Linux user/developer since 2001. Fedora kernel team member. Fedora contributor long enough that I forgot when I started, former FESCo, Rel-Eng, and Board member.

+

* '''Past work summary:''' I have been a linux user since 1999, starting with Red Hat 7.1 and moving through different distributions including Linux From Scratch to the current Fedora 17. I also co-started a local annual linux conference for beginners and intermediate users in 2006 and have led the organization team for the last 5 years. Since 2007 I have also worked for Red Hat in Brno, mostly focusing on the anaconda internals, text mode and driver loading subsystems.

+

* '''Future plans:''' We have some places in the distribution which affect very large number of other packages and environments. Some of those were even adopted by other distributions and people are working on making the learning curve for converts smooth. Unfortunately, sometimes we forget the motto of one tool doing one thing, but doing it properly. When that happens, we loose the ability to replace packages easily, integrate them in different environments and also to test them in isolation. But all those points are important from the engineering and QA point of view and make it easier for other desktop environments and distributions to integrate the tools. So I would like to help tweak the Feature process to take this into account and work with the community to make sure Fedora parts are more easily reusable by others.

−

* '''Future plans:'''

−

** Work with community members to ensure Fedora is a rapidly evolving yet high quality distribution.

=== Questionnaire ===

=== Questionnaire ===

+

* '''What skills do you bring for FESCo?'''

+

+

As I already posted in my nomintion, I have led a team which prepares a conference for about 500 attendees for five years. That probably means I have some negotiation and planning skills. As part of the Anaconda team I am also used to explaining ideas and goals to people who do not like those. And that takes diplomacy and self control.

+

+

Other that that, I have the usual set of engineering expertise starting with masters in IT and ending with the relevant work experience. Having (co)maintained couple of packages myself I think I understand the contributors point of view as well.

+

+

* '''Where do you see Fedora in the next year?'''

+

+

It should have better definitions of its goals and better mechanisms for dealing with unforeseen issues and delays.

+

+

We cannot afford weeks of improvised slipage. We can slip if that is needed, but it should be planned and consistent with the goals, not based on improvised decisions.

+

+

+

* '''Where do you see the Fedora Project in five years?'''

+

+

Still state of the art, but less chaotic for the end users and contributors.

+

+

* '''What is your priority for Fedora?'''

+

+

Making sure Fedora has a clear goal maintainers can use to decide about features and keeping the distribution modular so it is possible to replace any component easily if it is needed.

+

+

* '''What are your thoughts on the Feature process?'''

+

+

I would like to see three things:

+

+

One is a document specifying what should Fedora look like and who it is for. We can than use it to implement default distribution behaviour on top of the upstream packages (APIs, btrfs vs. LVM vs. plain partitioning, /home partition, config files, graphic themes and so on) to avoid late in the release discussions about whether the default behaviour is right or not. Changes to this policy might then be regarded as Features and voted upon.

+

+

Secondly, the features are currently used mostly as topics we want to advertise. We do not always have the manpower to maintain the old version, once the upstream project decides to abandon it. And because most of our package maintainers and contributors are volutneers, we cannot force them. That means we are limited in what we can possibly do. Diplomacy is one possibility. Making sure the packages are smaller, better contained and thus testable and replaceable/revertable is another.

−

* '''What will you be able to accomplish if elected, that you couldn't as an unelected contributor? Why this post?:'''

+

And the last one is technical: When a feature gets filled we could find all packages that directly (and indirectly?) depend on the package the feature is filled against and notify the maintainers. The devel list is sometimes really busy and whole threads tend to get lost in history fast.

−

** Not much on an individual topic basis. The wonderful thing about Fedora is that it's a volunteer driven distribution, so contributors get to work on whatever they'd like. While I view that as an overall strength, it can mean that the direction of the distribution is scattered. I view one of FESCo's purposes as acting as a sounding board and provide oversight on the overall features to continue and present a consistent and coherent user experience. I enjoy looking at things in a slightly bigger picture, and being part of the steering committee allows that.

+

−

* '''What can be done to get more features and make more progress? Have you participated in any features before?:'''

+

So I believe that simply updating the Feature process won't solve the situation. It has to be a combination of changes to different policies. And for some situations, there just isn't any golden rule that solves everything.

−

** I'm not entirely sure we need _more_ Features. Our Feature list already runs quite large on a per release basis. I would instead like to focus on refining the Feature process so that our big ticket items are highlighted and sufficiently communicated during development. I think informing the community of the big Features that impact multiple things in the distro is important, and doing that early and often will help those Features land in a high quality way for the release.

+

−

** As a former FESCo member I have been involved in the Feature process since it's inception, however I have not personally proposed or worked on a specific Feature.

+

−

* '''What do you think about spins? Do we still need them or will they become obsolete once we have a new anaconda with better package selection?:'''

+

* '''What will you be able to accomplish if elected, that you couldn't as an unelected contributor?'''

−

** I think Spins, as a concept, are great. They allow sufficiently motivated parties to remix Fedora in ways they see fit and allow like minded users to easily install that particular flavor of Fedora. That being said, I think the current incarnation of that concept has become a bit cumbersome. Keeping a repository of spin kickstart files is a great idea, however I feel that focusing effort on producing those spins in an official capacity is misguided. I think Spins should be easy to produce by individual users, either by improving the existing tools or perhaps creating an on-demand spin service. Promoting a spin to an officially supported per release flavor should be extremely rare.

+

−

* '''Do you think the issues FESCo discusses and the decisions FESCo makes are effectively and efficiently communicated throughout the Fedora community? If you believe communication between FESCo and the Fedora community can be enhanced, what first steps or ideas would you propose?:'''

+

I will be able to directly influence the policy changes that would lead to smoother release cycle and better experience for contributors. By helping making sure the distribution stays modular I would be also able to help spins efforts and spreading Fedora based tools across the linux universe.

−

** I believe the communication FESCo does is as good or better than it has been since FESCo was created. Agendas and minutes are published promtply, tickets are tracked well, and the meetings are lively and fairly well attended by the electorate and community members. However, we might want to broaden the scope of where that information is communicated to. If our developer community is going to grow, we need to reach people that are interested but might not be on the devel list. Perhaps a weekly FESCo blog that highlights particularly interesting Features or technical issues and discusses progress and items that need help. More interaction with people on users list, etc.

+

Revision as of 22:51, 5 December 2012

The nomination period is CLOSEDThe nomination period ended at 23:59:59 UTC on November 13, 2012.

Candidates

Introduction

Mission Statement:

Make Fedora THE platform for rapidly developing the next generation of free, open-source software.

Past work summary:

Red Hat employee since 2008, developed the System Security Services Daemon, participant in the FreeIPA project. Currently advising the OpenLMI project and working on packaging Node.JS and its dependencies. Fedora Hosted admin maintaining ReviewBoard. Working with the OpenShift developers to host tools for use with Fedora such as Gerrit. Former FESCo member from June 2011 - 2012. Currently employed as the BaseOS Architect at Red Hat.

Future plans:

Continue to drive Fedora to become the best platform for developing exciting new technologies for the desktop and datacenter.

Questionnaire

What skills do you bring for FESCo?

I am currently employed as the BaseOS architect for Red Hat. My full-time job at this time is to facilitate collaboration between different open-source projects and help them avoid duplication of effort as well as resolving disputes between projects with competing technologies or goals.

Where do you see Fedora in the next year?

In the next year, I anticipate that we're going to see a significant shift in Fedora. The technology ecosystem is shifting from its classic development model of reinvent-the-wheel compiled languages into the more dynamic world of web applications built atop dynamic infrastructures
such as Django or Node.JS. Fedora has always represented the "will of the people" and will be adapting to these new development styles.

Where do you see the Fedora Project in five years?

I see Fedora refocusing on its core strengths over the next five years. We've spent a long time being everything for everyone, and it's become clear over the last several months of devel@ mailing list discussions that this isn't working for us and is not sustainable. My view of the five-year future is that Fedora is going to simplify its plans and shift back towards being a platform distribution as opposed to a software distribution.

What is your priority for Fedora?

I have two primary goals in mind for Fedora:

I want Fedora to be the distribution that software developers are *excited* to use for the development of the Next Big Thing.

I want Fedora to provide a powerful and extensible platform for doing that development.

What are your thoughts on the Feature process?

The Feature process is too bureaucratic in some instances while being simultaneously toothless in other situations. For example, there are many Features that come in that are simply rubber-stamped into the distribution because they were raised as Features simply to be added to the Release Notes and Talking Points. I think we should have a separate process for these additions that should be handled by FAmSCo instead, since this is more an evangelizing task. The purpose of Features should be constricted to dealing with those changes that have impact throughout the Fedora Project; it should address those tasks that require coordination among multiple projects or those whose slippage could delay releases.

Additionally, there are Features that are approved without a sufficient understanding (or communication) of the risks involved. Features such as the recent Anaconda mass changes that have significant likelihood of slipping the release should be communicated out to the community very carefully ahead of time. Such enormous changes should be communicated throughout the community and effort made to involve the whole community *early on* to do what they can to facilitate the Feature so that we minimize the risks of slippage.

What will you be able to accomplish if elected, that you couldn't as an unelected contributor?

In my role as a facilitator, my efforts will carry more weight if I am part of a team whose job it is to enable the creation of a unified product. I can negotiate between teams with the additional influence that a position on FESCo can provide.

Introduction

Mission Statement: To further the goals of the project and Free Software in general by helping enable contributors to bring the highest quality and most diverse collection of software to the distribution. I'm fully committed to the goals of Free Software, for ideological, but also primarily technical reasons.

Past work summary: I've been a Fedora user since RHL 7.1, and an active packager since 2007, as well as a sponsor and member of FESCO and the FPC. I initially focused on games and php applications, but have expanded to other things over time. I also encounter and deal with many of the issues we encounter as a project in the course of my day job.

Future plans: Ideally, I'd like to find ways to encourage and educate new contributors. I've sponsored a few new packagers, but would like to help shorten the time from first interest to active packager, and can only do so much on my own. I also have ideas and opinions on many areas FESCO addresses, including the Feature process, and would like to continue to contribute what experience I have to those conversations. I'm also very much interested in helping ARM achieve Primary architecture status, and have been doing a bit of work towards that goal.

Questionnaire

What skills do you bring for FESCo?

Many years of Linux use and administration experience, several years experience as a Fedora packager and developer, and both work and Fedora leadership experience.

Where do you see Fedora in the next year?

I think we'll see ARM become a primary architecture, and continue to advance the progress of free software with the latest and best software. We'll work out the kinks in our feature process, and grow the community.

Where do you see the Fedora Project in five years?

We'll be a technical, if not numerical, leader on the desktop, in the server room, on mobile, in the cloud, and making serious inroads in at least one place that doesn't exist today.

What is your priority for Fedora?

My day-to-day priorities are fixing FTBFS bugs and updating versions on software important to me. Most of my energy outside of my direct packages has been on ARM FTBFS and SCM maintenance.

What are your thoughts on the Feature process?

There needs to be a closer relationship between FESCO and feature owners, and the feature submission process needs to begin and end sooner in the cycle. Ideally, I'd like to see each feature assigned to a FESCO member whose responsibility is to act as a patron, or sub-feature-wrangler for that feature, making sure the status page matches reality, that the feature is progressing, and assisting if needed.

What will you be able to accomplish if elected, that you couldn't as an unelected contributor?

Being a part of FESCO, in my view, gives me greater insight into the technical direction of the Fedora project as a whole, and I'd like to continue that, particularly with regard to me ideas around the feature process.

Introduction

Mission Statement: To help Fedora developers get their work done in such a way that we ship a distribution that benefits our users.

Past work summary: I'm a former Red Hat employee keen on continuing to contribute to Fedora. I've worked on various power management and ACPI features, and have been leading the Secure Boot implementation that's been adopted by most significant Linux distributions. I've recently been spending time on helping with the remaining Anaconda and upgrade issues for Fedora 18.

Future plans: FESCo exists to enable Fedora contributors to get their work done, providing that that work doesn't adversely affect other contributions or the goals of the distribution. That isn't how it's always been treated recently. I want to focus on returning FESCo to being an enabling group, while simultaneously engaging the community in discussions to fix the various infrastructural and policy flaws that stand in the way of developers.

Questionnaire

What skills do you bring for FESCo?

I'm an experienced developer with detailed knowledge of how most system components fit together. I've worked on the kernel, and I've worked on desktop applications. I've worked on pretty much everything in between, too. I've also been involved in the development of other distributions, so I don't approach issues with the inherent assumption that the existing Fedora solution is necessarily the best.

Where do you see Fedora in the next year?

With luck, back to regular release cycles that can benefit from the infrastructural work that's been carried out this cycle. I don't imagine
that there'll be massive changes. ARM may have reached the point of being a primary architecture.

Where do you see the Fedora Project in five years?

Where I'd *like* to see the project in five years is a place where people spend more time developing and less time arguing, but that might be a fundamental outcome of our community model. There'll probably be even more focus on cloud than there is now, and I expect that ARM will have been a primary architecture for a significant period of time. I'd hope for less infrastructural churn in the lower levels of the distribution - we'll have rewritten everything enough by then that we should finally have got it right.

What is your priority for Fedora?

Pragmatic technical excellence.

What are your thoughts on the Feature process?

It's currently mostly pointless. There's no way to mandate that development goes through the feature process, and most of what does is doing so purely so a box can be ticked somewhere. Our failures to communicate development aren't helped by getting people to fill out forms.

What will you be able to accomplish if elected, that you couldn't as an unelected contributor?

Vote in FESCo decisions. If you trust my judgement, elect me. If you don't, don't.

Introduction

Mission Statement: Make Fedora work better for its primary purpose as a distribution - to turn various differing upstreams into a consistent and well-integrated whole.

Past work summary: Contributor since RHL times, worked on many things including a tcsh internals rewrite, initscripts, pyrpm, switch from MD5 to SHA-256 hashes in RPM and other places, audit work from the kernel to GUI layers, volume_key, encrypted disk support in libvirt, kernel's crypto interface, and the Fedora signing server. Used to be a heavy-duty translator into Czech.

Future plans: Fedora is often the place where packages affected by changes other packages first interact, and handling this well is critical for fulfilling the above-mentioned primary purpose of a distribution. To that end, I plan to work on improving the Feature process, and otherwise improving the handling of changes that affect other packages and ensuring distribution-wide consistency - while making it possible to make successful transitions faster, not slowing change down in bureaucracy. I also generally favor policies that allow quick bug->fix turnaround time and allow more enhancements into released versions of Fedora. Outside of FESCo my interest is in improving security of Fedora.

Questionnaire

What skills do you bring for FESCo?

From the technical point of view, probably an above-average understanding of most of the major functional areas of the distribution: For example, I've been doing kernel programming, GUI programming, web programming, I've worked on the old init/network scripts. This was directly relevant to FESCo - looking at the FESCo tickets, I think I've been one of the more active people in researching the technical status/issues/interactions of various proposals.

From the organizational point of view, I've been on FESCo for the past year, and thus have some understanding of what the pain points are and what the
possible solutions might be - certainly more than I had when I started in FESCo.

Where do you see Fedora in the next year?

I want to help with, and have some proposals for:

More cooperation between maintainers of various packages, resulting in more complete and less painful integration of new features.

Improved processes that "scale" with the task, getting out of the way for simple cases and handling the larger cases better. (See the "Feature process" question for some details.)

I also want to start moving Fedora toward:

Better QA (more automated testing, more involvement of testers in planning of updates and feature integration); in my experience doing such work upfront pays off in the future, especially when a component is faced with a large magnitude of "external" changes, like it is often the case within Fedora.

More agreement on who the primary users and expected uses are, to establish a better common ground for the more controversial technical discussions and decisions that are often primarily disagreements about the users/uses. I don't think these things can happen within a year, but we can make some progress.

Where do you see the Fedora Project in five years?

The basics should not change: integrating upstream open-source software into
a distribution in a collaborative way, quickly adopting new technologies.

We should get better at it, though - integrating the new things quicker, better and more completely, with fewer surprises and less unexpected breakage.

Currently a better feature process, and better QA seem to offer the most effective ways to improve. The better QA will take some time to develop, and
we will certainly encounter and have to overcome other, currently unexpected, hurdles towards the goal.

What is your priority for Fedora?

Short-term it is clearly improving the "feature process"/communication mechanisms (see the "five years" question for rationale).

What are your thoughts on the Feature process?

It mostly works well as a marketing device. For technical coordination, there's certainly room for improvement

As a possible immediate improvement, Marcela Mašláňová, Tomáš Mráz, Jaroslav Řezník and me have prepared a specific proposal that will:

significantly improve feature visibility, which alone should make coordination easier and avoid some surprises

simplify the process for changes that don't need FESCo micromanagement

get FESCo more involvement in the integration and quality of more risky features.

Over time, I would like Fedora to move towards somewhat higher expectations from package maintainers, at least for the most important packages (at least packages shipped in the default spin, or perhaps in any spin?):

Setting up "release goals" for each Fedora release, where every maintainer is expected to update their own package for some change.

The problematic sysv->systemd conversion is a current example. We can expect similar migration necessary for GTK+ 2->3, Python 2->3 in a
not-too-far future.

Ability to distribute such work across all package maintainers - and to really get it done for the next release - is critical to Fedora's ability
to quickly integrate new technologies.

Puting more focus on the already existing package maintainer responsibilities (dealing with bugs, notify others about changes) - perhaps making it easier to become a comaintainer of "problematic" packages.

What will you be able to accomplish if elected, that you couldn't as an unelected contributor?

Many contributors express opinions on policies, processes and distribution-wide technical decisions decided by FESCo. All of them are heard, but ultimately they are effective through a representative on FESCo, and I'd like to serve as a representative for people who agree with my mission statement and plans.

Introduction

Past work summary: I've contributed to Fedora since the fedora.us days and was a member of FESCo during the merge of Core and Extras. Recently I've been an active member of the Fedora Infrastructure Team working on FAS, PackageDB, and general scripting and bugfixing, worked on Packaging Guidelines as a member of the Fedora Packaging Committee, and have just returned from a stint on the Board. Around alpha release, I can often be seen to step in to get python packages building or work on bugs that have hit the community's radar but aren't important enough to hit a blocker list.

Future plans: Past FESCo's have streamlined many policies including the updates policy, a fast track for nonresponsive maintainers, and how FPC guidelines are approved. The current and next FESCo are likely going to be tackling an update of the Feature Process. There's been a lot of work around this already. Many packagers have contributed to the Fixing_features wiki page. FESCo has been discussing issues on the Refining Features ticket. I'd like to help organize the identified problems and suggested solutions and incrementally improve pieces of the policy. If we finish that work, it may be time to take another look at improving the non-responsive maintainer policy.

Questionnaire

What skills do you bring for FESCo?

Experience working in groups that are striving to reach consensus (FPC, Fedora Board)

Large amount of experience with packaging for Fedora. I've been around since the fedora.us days and served on the Fedora Packaging Committee since its inception.

Good python programmer, okay shell scripter, rusty C programmer, for those times when FESCo will need to provide manpower to work on blocker bugs.

Where do you see Fedora in the next year?

There will be incremental changes in the next year. But we'll have started talking about some new, far reaching changes to how we create the distribution. We'll be tossing around ideas like every other release being more like an update release with minimal changes to the core platform and what level of support we want to offer to people creating copr addon repositories for Fedora.

Where do you see the Fedora Project in five years?

There will have been a few major changes to Fedora by the time we get five years down the road. We have accumulated a lot of processes that aren't working very well (and contrariwise, a lot of things that are working well). I think that similar to no-frozen-rawide, the core and extras merge, and Fedora Core 1, we're closing in on a place of re-evaluation where we're ready to make some changes to how we produce the distribution. I think those changes are going to be evolutionary rather than revolutionary but they aren't going to be small either. The changes that will inevitably come to the Feature Process in the next year are just the first of several of these large changes that we will see.

Although it's hard to spot things that are barely on the radar, I think that once the Copr buildservers become available in the next couple years we'll go through several phases of integrating what they offer into our universe of offerings. I would hope that we could get to the place where we offer people who care to work on the side repos some measure of support for providing some sort of full-service to the people who use them. Issue trackers, hosting for them. An automatic way to install repositories, perhaps some way to hook into the Fedora release schedule. However, watching the various secondary arch efforts, I'm not sure that this is where the project will go and if it does, whether it will be able to go there in the next 5 years.

What is your priority for Fedora?

Changing the Feature Process. Working on the AWOL maintainers process. Attempting to change the culture of package ownership to be more open to letting people work on things that they are not the owner of.

What are your thoughts on the Feature process?

It was a good first try but it's in need of some revisions. Some of the things that we have been kicking around for a while that I don't think are very controversial to implemment:

Make the feature process easier for things that just need documentation and more structured for things that need coordination by making separate processes and templates for each.

Give more power to the Feature Wrangler to approve things that fall into the documentation only set.

Probably want to get more people to do Feature Wrangling so that approvals at this level don't become a single-point-of-failure

Write some guidance about how to tell the difference between a feature that is docs only and a feature that needs coordination.

Those changes will help keep fesco free to deal with and focus on things that may be a problem within a release cycle instead of spreading themselves out looking at many things that merely require an entry in the Release notes if they get done. They'll also clear up some longstanding confusion and maintainer issues where various parts of the feature process don't map well to the particular type of feature that's proposed (Release notes for upgrading the boost library, for instance; the current alpha freeze schedule for leaf packages like the gimp or inkscape).

I think that people are currently mainly interested in the Feature process because of F19's slippage and unfortunately solutions to that seem to be more controversial or less fully fleshed out. Some of the problems leading to slippage:

We let many things go through even though they aren't ready at the milestones that are on the schedule.

We have a theoretical model for people to develop features over muliple releases and only release them into Fedora when they're ready. However, some teams claim they don't have the manpower for this.

We have a theoretical model where people should start developing for the next version of Fedora once rawhide branches. But only some people work on this schedule.

There are some ideas on fixing these but they all cause somebody pain. We could tell more people to revert their features if they aren't ready in time. We could tell certain critical components that they aren't allowed to push things into Fedora until they're already finished -- or if they go in, they very strictly have to be finished by alpha (or a new milestone before that) otherwise, the team must spend the rest of the cycle reverting their changes and stabilizing for that. We can enforce people doing more work on the branched release by freezing earlier and staying frozen. Then QA and releng would control who was doing work on branched... everyone else wouldn't have the ability to push things to branched so they'd have to work
on rawhide.

I don't think we're quite ready to swallow the tradeoffs that go with any of these so a lot more work needs to happen to find something that will be palatable to everyone.

What will you be able to accomplish if elected, that you couldn't as an unelected contributor?

Hopefully very little :-) Proposing changes to existing policies (which I hope is the most iportant thing I'll be doing) can be done by regular
contributors as well as members of FESCo.

Being a member of FESCo *will* give me the opportunity to vote on Features which I can't do as a regular contributor. However, I am definitely *not*
promising to do that job differently than any other member of FESCo currently does. I may ask more questions than the average member of FESCo does but I won't try to filibuster votes with endless questions. I will try to get proposed features modified to seek consensus, but I won't block things if there's nothing further that can be done to make something satisfy more people.

From a few of the controversial votes in the past few releases, I think I would have voted against several of them (UsrMove, for instance) but voted for others (for instance, SecureBoot). Given the information FESCo was given on the current hot button topic, anaconda's NewUI, I think I would have voted to approve that as well.

So do not vote for me if you think my voting record on features would have significantly changed what features made it into new versions of Fedora. I'd just be another member of the group charged with making hard decisions that affect the entire project.

Introduction

Mission Statement: Fedora should be opened for new projects, but we need to work more on inclusion of changes. Features or changes of default shouldn't lead to breakage of rest of the system.

Past work summary: Red Hat employee since 2006. I started as a maintainer of small utilities in Base group and become a Perl maintainer. Currently, I'm working as a supervisor of Languages group. I have almost finished second term in FESCo. My current project is Software Collections, which are able to provide more versions of the same software in a single distribution release.

Future plans: Fedora should provide environment stable enough for development of new features. I'd like to work in FESCo on review of new features and help to communicate between group of developers so the lack of communication does not bring surprises late in the development cycle of release.

Questionnaire

What skills do you bring for FESCo?

I was a Perl maintainer few years, therefore I know a lot about maintenance of projects with huge number of packages in Fedora. I'm aware of problems in our infrastructure during rebuilds. I'm mainly working on interpreted languages.

Where do you see Fedora in the next year?

I hope we will be working on stabilization of our distro. The last few releases brought huge changes and many of them weren't finished. I'd like to see more work on bugfixing than new features at least for one release. After release or two we could have a much better distro, but that depends on future features and how they will be done.

Where do you see the Fedora Project in five years?

Sounds like HR question, but okay. I'm afraid there is a possibility that Fedora would break up into smaller communities around different projects. Part of developers and their requests have been ignored (Server, Virtualization, ..). It might happen that Fedora will lose many users if we don't start talking with all projects working within Fedora project. I don't think we should focus on the desktop anymore. The market had changed, for pure desktop usage tablets, macs, or even smartphones are sufficient. Let's provide a strong development distribution, which means cooperate much better in distribution and focus on inclusion of new projects to work well within Fedora.

What is your priority for Fedora?

He? If you meant which use-case is a must for Fedora, then Platform for development - easy to pick what you want without many useless dependencies.

What are your thoughts on the Feature process?

We already created draft of improved feature process. We'd like to start discussion about it very soon. Our draft of Feature process is here

What will you be able to accomplish if elected, that you couldn't as an unelected contributor?

As a FESCo member I can decide, which features will be accepted and which won't.

Introduction

Mission Statement: Make sure the distribution stays modular and adaptable to the needs of many different user groups

Past work summary: I have been a linux user since 1999, starting with Red Hat 7.1 and moving through different distributions including Linux From Scratch to the current Fedora 17. I also co-started a local annual linux conference for beginners and intermediate users in 2006 and have led the organization team for the last 5 years. Since 2007 I have also worked for Red Hat in Brno, mostly focusing on the anaconda internals, text mode and driver loading subsystems.

Future plans: We have some places in the distribution which affect very large number of other packages and environments. Some of those were even adopted by other distributions and people are working on making the learning curve for converts smooth. Unfortunately, sometimes we forget the motto of one tool doing one thing, but doing it properly. When that happens, we loose the ability to replace packages easily, integrate them in different environments and also to test them in isolation. But all those points are important from the engineering and QA point of view and make it easier for other desktop environments and distributions to integrate the tools. So I would like to help tweak the Feature process to take this into account and work with the community to make sure Fedora parts are more easily reusable by others.

Questionnaire

What skills do you bring for FESCo?

As I already posted in my nomintion, I have led a team which prepares a conference for about 500 attendees for five years. That probably means I have some negotiation and planning skills. As part of the Anaconda team I am also used to explaining ideas and goals to people who do not like those. And that takes diplomacy and self control.

Other that that, I have the usual set of engineering expertise starting with masters in IT and ending with the relevant work experience. Having (co)maintained couple of packages myself I think I understand the contributors point of view as well.

Where do you see Fedora in the next year?

It should have better definitions of its goals and better mechanisms for dealing with unforeseen issues and delays.

We cannot afford weeks of improvised slipage. We can slip if that is needed, but it should be planned and consistent with the goals, not based on improvised decisions.

Where do you see the Fedora Project in five years?

Still state of the art, but less chaotic for the end users and contributors.

What is your priority for Fedora?

Making sure Fedora has a clear goal maintainers can use to decide about features and keeping the distribution modular so it is possible to replace any component easily if it is needed.

What are your thoughts on the Feature process?

I would like to see three things:

One is a document specifying what should Fedora look like and who it is for. We can than use it to implement default distribution behaviour on top of the upstream packages (APIs, btrfs vs. LVM vs. plain partitioning, /home partition, config files, graphic themes and so on) to avoid late in the release discussions about whether the default behaviour is right or not. Changes to this policy might then be regarded as Features and voted upon.

Secondly, the features are currently used mostly as topics we want to advertise. We do not always have the manpower to maintain the old version, once the upstream project decides to abandon it. And because most of our package maintainers and contributors are volutneers, we cannot force them. That means we are limited in what we can possibly do. Diplomacy is one possibility. Making sure the packages are smaller, better contained and thus testable and replaceable/revertable is another.

And the last one is technical: When a feature gets filled we could find all packages that directly (and indirectly?) depend on the package the feature is filled against and notify the maintainers. The devel list is sometimes really busy and whole threads tend to get lost in history fast.

So I believe that simply updating the Feature process won't solve the situation. It has to be a combination of changes to different policies. And for some situations, there just isn't any golden rule that solves everything.

What will you be able to accomplish if elected, that you couldn't as an unelected contributor?

I will be able to directly influence the policy changes that would lead to smoother release cycle and better experience for contributors. By helping making sure the distribution stays modular I would be also able to help spins efforts and spreading Fedora based tools across the linux universe.