It is still under construction and content may change. Do not rely on the information on this page.
This page outlines two complementary ways to slim down FESCo's time commitment with the Feature Process.
Delegate power to drop to the Feature Wrangler
Background
The important milestones page of the Feature Policy lists these milestones with the following actions by FESCo:
- From start of the release (probably when rawhide branches from the previous release but that's not specified formally) until Feature Freeze, new features can be added. The features are vetted by the Feature Wrangler and then presented to FESCo for approval. At this time, FESCo has the ability to say no to a feature based on the four criteria listed on the Acceptance page.
- Feature Freeze -- code must be testable. Anything not testable or any feature pages where the Feature Wrangler cannot get an update are handed over to FESCo to grant an exception or drop.
- Beta Deadline -- code complete. Anything not testable or any feature pages where the Feature Wrangler cannot get an update are handed over to FESCo to grant an exception or drop.
- Post-Beta Deadline -- any exceptions are granted. No reviews of features seem to be officially scheduled after this point so it seems like features granted an exception at this point have shown that they are going to be in the release no matter what.
Criteria for FESCo dropping features at Feature freeze and branching are outlined here.
Proposed changes
Acceptance
Acceptance should still be run through FESCo to judge the technical desirability of the feature. However, the current acceptance policy lists these criteria:
- consistent with the goals and policies of Fedora while within the laws governing the corporate entity sponsoring Fedora--Red Hat.
- supported by the Fedora leadership.
- suitable for listing as an Official Feature of the next release of Fedora
- important to track prior to feature freeze and could affect timeliness of release
3. and 4. should be performed by the Feature Wrangler as part of the vetting process. FESCo should only be deciding on the compatibility of the feature with Fedora when it comes before them. One piece that's important is that criteria 4. should be flagged to the person in charge of the Fedora schedule. At present, the same person handles updating the schedule as handles features but this may not always be the case so it would be good to have the Feature Wrangler simply flag those features as such when reporting them to FESCo for judgement of criteria 1. and 2.
Testing phases
Presently, incomplete features are pinged by the Feature Wrangler to have their status updated and if the Feature Wrangler cannot get a response, the feature goes to FESCo who then ping the feature owner for several meetings, trying to get their attention and effect a status update. Instead of this, the Feature wrangler should ping for status updates and if they cannot get a suitable response, the feature should be dropped. If wanted, the Feature Wrangler could implement a grace period where they allow feature owners to update their status after the deadline and they will still be accepted (to simulate how present features are allowed to get final updates in after the official deadlines due to the FESCo review and exception granting process). Pinging by both the Feature owner and FESCo is wasteful of resources.
Both the Feature Freeze Deadline and Beta Deadline are included in this change.
Times when FESCo would still need to be involved
The exception mentioned here would likely still need to go through FESCo. Note that this is different from the exceptions listed on the milestone page. By default, under this proposal the exceptions on the milestone page turn into the Feature Wrangler dropping the Feature.
If a feature requires changes to a range of packages outside of the Feature Owner's control, the Feature Wrangler or FESCo, when checking the initial Acceptance criteria, should flag the feature as such. That way the affected parties can be notified that the feature will require something of them (be it that their package will be mass rebuilt when the time comes or that the package will need modifications to run with the new feature/with the next Fedora.) Questions about coordinating the feature with existing packages would need to come back to FESCo to handle.
Form a Feature Wrangling SIG to handle features
A Feature Wrangling SIG could be started to handle the feature process. To make this flow smoothly, the SIG should be jumpstarted with the present Feature Wrangler and at least one member of FESCo. Due to the large role that testing figures into the feature plan and the two milestones (testable by Feature Freeze and code complete by Beta) it would be advisable to also seed this with someone from QA but I'm unsure how heavily QA is involved in the current feature process. The SIG would handle all of the work needed to accept and track completion of features. (Note: an alternate version of this plan could have the initial Acceptance of features handled by FESCo, as in the #Delegate power to drop to the Feature Wrangler plan and have the rest of the process handled by the SIG. I would advocate handling things that way for the first release but revisit when/if the SIG size has grown.) The benefits of forming a SIG for this are largely the same as the #Delegate power to drop to the Feature Wrangler plan but add the benefit of dispersing both the work and the knowledge of wrangling features to more than a single person. There is a startup cost involved with this as the Feature Wrangler and FESCo person or people involved will have to train their fellow SIG members.
The risk of the plan is that no one volunteers join the SIG. However, that doesn't seem to put us in much worse of a space than we are in now. In this worst case scenario, the following benefits and drawbacks would seem to accrue:
Benefits
- FESCo as a whole would have less work to do.
- The Feature Wrangler would have less work to do than in the #Delegate power to drop to the Feature Wrangler as they would have at least one FESCo member who commits to helping them.
- At least the FESCo member who is working on the SIG will be trained by the Feature Wrangler so we'll be slightly less dependent on a single person than presently.
- Total time to check for features to drop at each milestone may drop since they won't have to be viewed by both FESCo and the Feature Wrangler.
Drawbacks
- The Feature Wrangler would have more duties to go along with their increased powers regarding dropping features vs the status quo.
- The specific FESCo member(s) that volunteer to seed this group will have more work as they will be learning about Feature Wrangling in addition to their previous duties of accepting features.
If no one joins the SIG after a release or two we'd need to evaluate whether we want to continue it or not. If we chose to discontinue it we'd also need to work out another method of continuity for the Feature process should the present Feature Wrangler wish to resign.