From Fedora Project Wiki
This page is currently OPEN for suggestions on fixing the Feature Process. Comments will close, at least temporarily, on June 15, 2011, so that feedback can be assessed and we can move on to next steps.

Fixing the Feature Process

A good number of people think that the Feature Process, as it exists currently, is broken. This page is an attempt to start gathering feedback, information, specific examples, suggestions, flames, praise, or anything else you'd like to leave.

I (Robyn) will leave this wiki page open for commentary through 2011-06-15. After that, I'll attempt to concatenate some of the information into a readable format by 2011-06-20, and start figuring out what next steps should be, if any.

Please remember: This is a wiki page, BE BOLD! Feel free to add additional sections, information, etc. as you see fit. If people want to use the discussion tab, go for it.

About the Feature Process

Here are some handy links to Feature Process-related wiki pages.

Comments, Suggestions, Flames taken HERE.

Please put your comments in below. Adding your signature is helpful, as it allows for follow-up without having to sort through wiki history.

Problem Areas

  • Your comment here. Use the signature button to sign your name, to make follow-up easier. --Rbergero 13:13, 1 June 2011 (UTC)
  • We really have multiple goals with features and the requirements for them should be different: --abadger1999 19:26, 1 June 2011 (UTC)
    • Features that require package maintainers to coordinate with each other (NetworkManager updates, systemd, programing language updates) --abadger1999 19:26, 1 June 2011 (UTC)
    • Features that we want release noted and to hit marketing (new version of blender/inkscape/other self-contained app) --abadger1999 19:26, 1 June 2011 (UTC)
    • Some features have some degree of cross-over (gnome3, kde4 for instance) as they're both major end user changes and require coordination with others --abadger1999 19:26, 1 June 2011 (UTC)
  • Features that fall into the first category (requiring maintainers to coordinate with each other) arriving late in the cycle but being approved either as (1) part of another feature or (2) because we don't consider the burden it might place on other maintainers. --abadger1999 19:26, 1 June 2011 (UTC)
  • I agree, there are two major groups. Imho it's leaf packages, which can't broke other packages, and critical packages that can. I would create two categories. First one would be things like Aeolus, only release notes & marketing. It's nice to have it in Fedora, but they are leaf packages and Fesco doesn't have to control them. The second group should be critical things - interpreters like Python, init - systemd. There should be rules 'what to check' before adding them or replace as default. Fesco should work with feature owners, control list of (tracking) bugs and problems. In case critical feature would broke other packages, it should be taken back and Contingency plan from feature page should be used. User:mmaslano 19:36, 3 June 2011 (GMT)
  • The feature process isn't necessarily mandatory at this point, and I personally think that it's a flaw. Major features *should* be required to go through the features process, not only from a technical governance and integration standpoint, but in an effort to help with documentation and marketing. Jsmith 16:02, 6 June 2011 (UTC)
  • Maintainers are still unclear about what the various milestones/dates mean for them. At Feature Freeze/Alpha/Beta/etc, what do I have to have done and what can still be left for later? --abadger1999 20:08, 6 June 2011 (UTC)
    • FESCo also tends to err on the side of letting late features through rather than keeping them out (which is not always bad). Some of this could be helped by separating the types of Features and having an understanding that things for documentation have one due date (needing to be sure it's in so that release notes and translations of release notes can be finalized) while things requiring coordination need a much earlier (or sequence of much earlier) deliverable date so that coordination and fixing of dependent packages can happen. --abadger1999 20:08, 6 June 2011 (UTC)

Things that work

Do you think that some particular things work *well* in the Feature process? List them here -- the goal should be to fix the things that are broken, and keep the things that work well.

  • Your comment here. Use the signature button to sign your name, to make follow-up easier. --Rbergero 13:13, 1 June 2011 (UTC)
  • Paul Frields expressed profound satisfaction with the feature process helping to get proper press attention to features Fedora wanted to highlight in a release --abadger1999 19:27, 1 June 2011 (UTC)
    • +1. Feature listings are immensely helpful for writing one-page release overviews, formulating highlight sldes for the main website, and yielding talking points for Ambassadors worldwide. Thanks for including this, Toshio. --pfrields 20:36, 6 June 2011 (UTC)
  • Feature pages help to write proper release notes. It's good for seeing improvement on project and you can track list of TODO here. User:mmaslano 19:21, 3 June 2011 (GMT)
  • The Feature process ensures that FESCo has oversight over large technical changes. Jsmith 16:03, 6 June 2011 (UTC)

Specific examples of where the Feature Process failed

Specific examples help out quite a bit. If you have any, please list them here.

  • Your comment here. Use the signature button to sign your name, to make follow-up easier. --Rbergero 13:13, 1 June 2011 (UTC)
  • NetworkManager update in F15 arrived after the Feature process was closed to new features and left us scrambling and we weren't able to fix Sugar by release time. --abadger1999 19:30, 1 June 2011 (UTC)
  • Python2.7 upgrade in F13(?) -- the feature was accepted on time but the rebuilds to implement the feature happened late, leaving us with modules that had to be fixed in order to work very late (sometimes too late) in the cycle --abadger1999 19:30, 1 June 2011 (UTC)
  • NetworkManager brought lot of unplanned work for KDE team. Also changing /run into root added work to selinux team. Such change wasn't discussed with selinux maintainers before, so they couldn't prepare it and co-operate on changes. Both updates of /run and new selinux rules should go out in one update. User:mmaslano 19:21, 3 June 2011 (GMT)

Suggestions Welcome

Have any ideas on how to improve the feature process? List them here!

  • Your comment here. Use the signature button to sign your name, to make follow-up easier. --Rbergero 13:13, 1 June 2011 (UTC)
  • Split the process -- a set of criteria and due dates for features that need external marketing and a different set of criteria and due dates for features that need internal coordination. Probably give different names to each of these to avoid confusion. Initially, FESCo and the Feature Wrangler may need to tell people that their feature was submitted to the wrong group, point out the relevant criteria, and help the feature owner move them. --abadger1999 20:16, 6 June 2011 (UTC)
  • Different expectations around who does the work depending on when a coordination requiring feature is publicized. For instance, if you introduce API changes in the first stage of release creation, the dependent packages have primary responsibility for fixing their packages. If you introduce API changes later than that, the package maintainers introducing the API changes have primary responsibility for fixing the dependent packages. --abadger1999 20:16, 6 June 2011 (UTC)

Other comments

Comments that don't fall into any of the above categories can land here.

  • Your comment here. Use the signature button to sign your name, to make follow-up easier. --Rbergero 13:13, 1 June 2011 (UTC)
Retrieved from "https://fedoraproject.org/w/index.php?title=Fixing_features&oldid=240484"