What is your background in Fedora? What have you worked on and what are you doing now? => I am using Fedora since its first release Fedora Core 1. I joined Fedora as a contributor in Fedora Core 6 development cycle. I have contributed many Internationalization(i18n) packages and sponsored some people in Fedora. I have done more than 1600 package reviews in Fedora. I am also a provenpackager and helped in fixing packages in mass-rebuilds. I also contributed to few packaging guidelines draft. Currently I do package reviews, sponsor people in packager group, add new style, new language script fonts in Fedora, maintain some i18n packages. Other than that I like Fedora Applications. Whenever there is any new Fedora Application(like tagger, pkgdb2, fmn) is available or any of its new release, I used to test it and if found any issues, report it upstream. I also test packages in updates-testing and provide feedback in bodhi. Do you think Fedora should be time based or more feature driven distribution? Or compromise? => It should be compromise. Accept Changes that will be ready to be tested by Alpha release and follow the release schedule deadlines. What are the most pressing issues facing Fedora today (from engineering POV)? What should we do about them? => We need to have more testing for Fedora Products and resolve any issues in them. I see we still have some installer, package selection, using dnf instead yum, migration to python3, installing non-default groups in any product issues going on. For some of these issues users need to be aware of these changes in advance by providing them some examples on how the changes will affect them and how can they will fix them otherwise their packages remain incompatible in the current development cycle. Everytime such big change comes we endup with filing mass bugs, fixing most of the release blockers but not fully resolve all such bugs. Over the last few releases I saw such leftover bugs remained still open. We should make sure to fix them all. If we look the development happened in last few releases we can see we got many features/changes development happened in Fedora but all this is not getting properly documented on Fedora wiki. We also need more test cases to be submitted with each Change proposal that people can test on test days. Translations is another thing. Every release we see some translations missed by some packages in Fedora. Sometimes anaconda installer too miss to pull translations. We need developers to also make sure that they will check translation coverage to be 100% for the packages getting tagged in final releases. We need more QA, automation to avoid any last minute schedule slip. We also occasionally find new contributors asking questions about packager sponsorship. We have been regularly amending the sponsorship guidelines but still there are some questions not answered in guidelines and left to individual sponsor to define. Lack of sponsor for new contributors or lack of response from submitter is one problem. The merge-reviews is another problem that could have easily solved by asking that package group/SIG members to finish those reviews in any Fedora release cycle. But no particular decision on this happened yet. Care to share a screenshot of your Fedora desktop? => I use Gnome as my primary desktop environment. What are your interests and experience outside of Fedora? What of those things will help you in this role? => In the free time I read about mobile technology related articles. I do testing of custom Android ROM's for my old mobile and provide feedback to its developers. I don't think this will help me in my FESCo role. How can FESCo do a better job communicating with the rest of the Fedora community, or do you feel that FESCo is already doing well here? => FESCo is definitely doing good work. Its weekly meeting logs are always posted on devel list so that contributors can know what is happening in FESCo meetings. But the tickets getting reported to FESCo are not getting lower and the queue is always filled with good number of tickets for each meeting and for future meetings. We need more hands to help FESCo in their work. That does not mean more seats to FESCo but more volunteers to either participate in FESCo meetings to share their views on tickets or on mailing list. What can you accomplish as part of FESCo that you couldn't accomplish as a contributor to Fedora without sitting on FESCo? => As a contributor to Fedora I can always provide my views on topics in FESCo meetings but as part of FESCo I will try to have Fedora development going forward in the required right direction by providing my vote. What degree of leeway do you feel that the Working Groups should have to diverge from one another in establishing their own identity? => The different Working Groups should use the same existing infrastructure, packages in Fedora. However they can diverge by using certain required features that is necessary for establishing their own identity. I think the per-product configuration will be helpful on how this divergence can be implemented. How would you define the set of criteria for promoting a spin to a product? What about the reverse? => I think spins should continue to stay like we have them currently and I don't think we need to increase our products also. If possible we should work on integrating some spins in our products. The current 3 products are good. The Workstation product uses Gnome desktop environment. The other desktop environment spins can use the similar PRD to promote them as a product. But, we need to find names for those products then. I don't think we need to go reverse now for already defined products. With the advent of Fedora Council now, what do you see as the significance of FESCO in Fedora project? => I think it's significance will remain the same. FESCo has been looking into the Working Group's discussions then the issues like Change discussions, some package development problems, non-responsive maintainers and provenpackager requests. The Fedora Council is not supposed to this work and is a high level decision making governance body. How "closely" do you, as a member of FESCO, follow the devel mailing list before voting on FESCO meetings? In other words, apart from your own technical qualifications, what is your typical process in arriving at decisions? => Sometimes the discussion on some topic receives many replies on the devel list within a day which takes some time to read and understand what users have to say. But, I will make sure I get enough information about the topic on which voting is going to happen. Before FESCo meeting, I will read the tickets given in agenda, try to reproduce the problem and if I can find some information related to that ticket then I will collect it. Based on this information I can decide to vote. Anything else voters should know? => I work for Red Hat Internationalization team. All other information is already covered in other answers.