Elections/Questionnaire

The question collection period is closed
The collection period ended at 23:59:59 UTC on July 07, 2014.

The following special elections will take place in July 2014:

• FESCo (Engineering) (three seats)

All dates and times noted are UTC time.

Please add questions you'd like to see asked to this page.

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.

CLOSED The questionnaire is closed. No further questions will now be added. Please do not modify this page!

Fedora Engineering Steering Committee (FESCo)

Questions

What is the role of FESCo in your opinion? What is it to do or not to do?

• Tomáš Hozza: FESCo's role is to do well informed decisions on issues (tickets) raised by any Fedora project community member. Members should keep in mind the overall usability of Fedora and the Fedora Foundations while doing decisions. Members should not prioritize their personal opinions and feelings over the pure technical and objective point of view.
• Josh Boyer: FESCo is the hub of all things technical in the creation of the various Fedora distribution products. That includes spins and Products. In my opinion it should also function as the Base WG rather than having a separate entity for that.
• Kalev Lember: Fedora is a huge project and has a lot of people working on it. Sometimes the people agree, sometimes not. Sometimes people are unsure which is the best path forward, sometimes they need assurance that they are doing the right thing. I see FESCo's role as providing technical guidance and helping choose the best path forward. After all, FESCo means "Fedora Engineering and Steering Committee".
• Lukáš Nykrýn: I believe that truly free opensource distribution should use bottom-up approach. FESCo should serve as an organizer, moderator and judge in the case of major conflict.
• David King: I see it as a way to resolve engineering questions relating to Fedora as a whole, and (as a last resort) to resolve technical disputes.

Where do you see Fedora in the next year? Next five years?

• Tomáš Hozza: I really like the upcoming Fedora products. In the future I see Fedora as an attractive distribution, that has something to offer to wide variety of users, whether it is on a server, desktop or cloud.
• Josh Boyer: Hopefully the Fedora.next approach results in some high quality Product releases that have good marketing and uptick in usage within the next year. Building on that over the next five years should help Fedora remain relevant for developers, sysadmins, and end users. That should allow us to grow our contributor base and expand the areas we can reach.
• Kalev Lember: I would like Fedora to become the go-to platform for new developers. A platform they could easily install and quickly start using to work on projects of their choosing. As an example, one of the most exciting new projects in the Linux distro land, Docker, was developed outside of Fedora. Why? Why didn't Docker developers use Fedora to work on their new project? I do not have all the answers here. But I'd like us to try and figure them out and move towards a future where Fedora is seen as a great platform for developers working on their projects.
• Lukáš Nykrýn: In near future we will see huge changes in userspace and we have to make sure that we will not stay behind.
• David King: Over the next few years I hope to see a good level of product differentiation, and Fedora used more widely in those product categories running up to the next 5 years. In other words, I think that the success of the Working Group products is critical to the continued success of Fedora.

What is your priority for Fedora?

• Tomáš Hozza: My priority is to keep Fedora the cutting edge distribution with focus on the latest technologies and trends. Make it attractive for contributors by having easy understandable processes and tools automating most of the regular and repetitive tasks.
• Josh Boyer: To make sure it remains a top tier distribution, both in terms of quality and features provided.
• Kalev Lember: Fedora Workstation.
• Lukáš Nykrýn: As I already mention in my statement Fedora should be a cutting edge distribution.
• David King: Ensure a smooth workflow for Working Groups, so that they can produce great products.

If you could change one thing about how FESCo has operated traditionally, what would it be?

• Tomáš Hozza: Raise developers' awareness of the FESCo's activities.
• Josh Boyer: I don't find anything particularly wrong with the processes that FESCo uses, so I wouldn't really change the operation much. The one thing I think we as a project need to look at is stagnation of the various committee members though. FESCo has been comprised of many of the same people for many releases now. These people are doing a fine job, but our candidacy pool for elections should be much broader and allow for fresh view points. If the elections result in the same people still being elected, then great but interest in the seats seems to have dropped off. We need to renew our contributor's interest in steering Fedora.
• Kalev Lember: Less voting, more leadership.
• Lukáš Nykrýn: I believe that FESCo should actively pull competent developers and maintainers into major decision topics.
• David King: Personally, I think that smaller committees are more effective than larger ones, and FESCo has 9 members, which seems large to me. However, FESCo seems reasonably effective, so I not see a need for a specific change.

How do you see FESCo working with the Fedora product Working Groups?

• Tomáš Hozza: I think FESCo should support efforts of Working Groups and coordinate the outcomes.
• Josh Boyer: I think it's somewhat premature to ask this question for two reasons. The first is that we're still in the middle of working on this for the first release. It's difficult to stand back and assess something you are in the middle of at the moment. The second reason is that many of the Working Groups have heavy FESCo involvement among their members. The interaction thus far seems to be working well enough, but it's hard to tell if that is because the liaisons are FESCo members or because things are actually operating smoothly.
• Kalev Lember: I think it makes sense to give the product WG-s more freedom in their area of expertise. After all, that's why they were created -- they know their product best.
• Lukáš Nykrýn: I think that Workings Groups should have casting vote in their respective fields and FESCo should intervent only in the case of disagreement between working groups or in a WG itself.
• David King: Working Groups have a bit more freedom to set their own goals, and hopefully this makes it easier for FESCo to resolve questions on Fedora as a whole and reduces tension. FESCo should act more as a point of contact between Working Groups, and only be called on to resolve disputes as a last resort.

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

• Tomáš Hozza: I will be able to contribute to the decision-making process.
• Josh Boyer: I hope to bring a bit more preparedness to some of the Feature and item reviews by actively reaching out to the submitters before meetings, etc.
• Kalev Lember: -
• Lukáš Nykrýn: Again I believe Fedora should be driven by developers themselves and as a member of FESCo I would like to ensure that this is really happening.
• David King: Vote on FESCo decisions and take on responsibilities that only FESCo members can do (acknowledging unresponsive maintainer notifications, proven packagers and so on).

What technical criteria should be established for products to be accepted as a new Fedora product or the other way, to be removed from the list of supported products. Should this apply for implicit three products too?

• Tomáš Hozza: There should be a clear use-case and a technical justification why any already existing product is not suitable for the use-case. It would be inefficient to focus contributors time end effort in developing things that already exist. We should also keep track of already rejected products with exact reasons and concerns, for further argumentation or reopened discussion.
• Josh Boyer: Great question. I have no idea. This is something FESCo, as a committee, should work out as we work through the first Product release. As a starting point, I would simply say the same criteria we have used for previous Fedora releases should work well enough. Refinement from there will need to be worked out between FESCo, QA, and the Working Groups. I'm sure some of the criteria will differ for each Product.
• Kalev Lember: First of all, I think we've hit a good balance with the current 3 main products and I do not see us adding any new ones soon. If there's a 4th one coming up in the future, it should probably be for a totally new market segment that doesn't overlap with current products, e.g. Fedora Phone. Also, I don't want to come up with technical criteria here because the choice of what the main products are is a social question and not a technical one.
• Lukáš Nykrýn: I don't think that this should be a question of technical requirements. I would like to see that behind every product is a caring community with a clear statement.
• David King: This seems like a topic where it is best to ask the existing Working Groups (and prospective Product owners) what they need from Fedora, rather than dictating this in advance.

I can think of some example criteria, such as using the output from the Base Working Group, using the Fedora name and branding, using Fedora infrastructure and so on. The important details will be how to deal with a conflict between a Working Group and the output from the Base Working Group, and whether that can be resolved without invoking FESCo. Ideally, I would like to see Working Groups set the direction and take part in the Base Working Group, for the benefit of all of Fedora. Given that there is an open FESCo ticket about Working Group interactions, this would seem to be a hot topic for the next committee: https://fedorahosted.org/fesco/ticket/1179

On the spectrum between ABI stability for third-party applications, and maximum innovation with no API stability, where should Fedora lie in your opinion?

• Tomáš Hozza: Somewhere reasonably in between. Since innovation is one of Fedora's focuses, the API stability breakage is sometimes inevitable. In such situations compatibility packages for some selected subset of (important) components should be provided. This could be done for example for one extra release cycle. Without at least some kind of stability, or at least some mechanism, Fedora will be hardly used as the deployment distribution for third-party applications.
• Josh Boyer: I'd like to see it somewhere in the middle. Fedora shouldn't adopt a RHEL-style ABI guarantee, as that is much too long of a cycle to maintain but it also shouldn't break things with every release. I thought Tom Callaway's model of a release cycle was a nice middle ground, where we set the initial direction for the distro at a certain release and refine that over the next few subsequent releases. This allows us to innovate with a defined break point in mind while not overwhelming our users with massive churn. The resources to accomplish this is likely more than we have right now, so we would need to work on increasing our contributor base.
• Kalev Lember: I think we should define a supported base ABI for each product and commit to supporting it for at least 2 Fedora releases. See e.g. the recent discussion in fedora-devel where we broke ABI compatibility with a major 3rd party app (Chrome). If we want to innovate and change our interfaces, this is fine, but we should also try and provide compatibility options for libraries that 3rd party apps tend to use.
• Lukáš Nykrýn: Core components of the system should have a stability promise where the subset of their interface will be marked as stable. And for the rest of the system I believe that now we finally have technologies to achieve both of those diametric goals. We can provide a system with innovation and support stable interface for third-party applications through SCL or Docker.
• David King: I think that there is scope for both approaches, with a stable base system, which Working Groups can build on to give a product that is tailored for a particular category of users. I think it is expected that the base system changes less radically, and is therefore more stable, than the layers built on top of it, but there should also be room for some more "lockstep" development, such as a desktop environment driving and depending on new features in systemd or the kernel. Fedora has been pretty good with such transitions in the past (BlueZ 5, upower 0.99 and so on).

History

Questions from previous elections can be found here:

• Fedora 19 elections questionnaire
• Fedora 18 elections questionnaire
• Fedora 17 elections questionnaire
• Fedora 16 elections questionnaire
• Fedora 15 elections questionnaire
• Fedora 14 elections questionnaire
• Fedora 13 elections questionnaire
• Fedora 12 elections questionnaire