It is still under construction and content may change. Do not rely on the information on this page.
The Feature Process has proven itself to be clunky. We need to think about changes to it now that we have some experience with what works and what doesn't.
One process, two audiences
Perhaps the most problematic issue with the Feature Process is that it is really meant to address three separate needs with sometimes disparate changes.
Coordination among package maintainers
Some features are invasive. The work may be done in one package but that package then affects multiple other areas of the project. For instance, changes to NetworkManager, dbus, and systemd could all fall into this category of feature. These packages need to coordinate their changes with the people who consume them.
Prominent announcement in the Release Notes, talking points, marketings
Some features are there for the press value. An example of this might be Features/BoxGrinder or Features/RupeeSign. These are things that the user's of Fedora might recognize as great new features or changes that may cause them pain but don't require coordination across areas of the project.
Things that are good about feature process
Testing and contingency plans
Having testing and contingency plans helps make a quality release. Need feedback from QA about whether this has been helpful in getting test plans and sensible rollback mechanisms in place. Are there examples of Features which did these well? Are there examples of Features that did these poorly? What else can we do to make this better?
Expectations of deadlines
Laying out when the freeze dates are and defining what each of those mean.
Things that we know could be improved
- Deadlines are kinda slushy
- Docs/marketing style features have different impact on the release than features that need coordination among different parts of the distro.
- Some features in the coordination sense don't make sense from the documentation sense