From Fedora Project Wiki
< Features
| Line 31: | Line 31: | ||
* There are both good and bad examples of how to articulate features. Perhaps those feature owners who are prose-challenged could have a writer assigned to maintain the feature page. --[[User:Jjmcd | Jjmcd]] | * There are both good and bad examples of how to articulate features. Perhaps those feature owners who are prose-challenged could have a writer assigned to maintain the feature page. --[[User:Jjmcd | Jjmcd]] | ||
* Feature owners should always be CC'd on any announcements and meetings. --[[User:Rjones | rjones]] | * Feature owners should always be CC'd on any announcements and meetings. --[[User:Rjones | rjones]] | ||
* Integration of DNSSEC keys for resolving nameservers (named & unbound) with easy method of enabling/disabling. | |||
(working on a package for this, should be up for testing soon) --[[User:Pwouters | pwouters]] | |||
* bullet | * bullet | ||
* bullet | * bullet | ||
Revision as of 22:18, 11 November 2008
Fedora 11 Feature Policy Review
| This page is to track changes and discussion changes to the Fedora 11 feature process based on our experiences during Fedora 10 development. This is a public white board--everything is up for discussion. |
Background
- Current policy http://fedoraproject.org/wiki/Features/Policy
- https://fedoraproject.org/wiki/Features/F10PolicyReview
- https://fedoraproject.org/wiki/Features/F9PolicyReview
Proposal
- Please start a new section for processes or policies that you would like to be different during the Fedora 11 feature process
- We will collect the ideas here from November 4, 2008 through November 11, 2008.
- I will propose that FESCo review the proposed changes to the policy at their meeting on November 12, 2008
Invite Feature owners to FESCo meetings
- Feature owners need to get an invitation to the FESCo meeting when their feature will be discussed.
- posting the FESCo schedule to fedora-devel isn't sufficient as that's a high traffic list and it is to easy to miss the schedule
- Having the feature owners in the meeting can speed things up a lot as questions can be asked and answered without one week delay between the meetings
- This would seem to be key -- adequate prior notice of the meeting should be given directly to the feature owner (direct email, IRC ping, bug, whatever) so they both know when to attend and have the necessary lead time to adjust their schedule to make it, if needs be. Chris Weyl 16:55, 10 November 2008 (UTC)
Stick to the process
In F10, we have seen both late additions (AMQP) and late removals (empathy). This further reduced the buy-in to the feature process. Why bother, if it all gets undone in last-minute FESCo decisions anyway ?
<Your Suggestion>
- It would be good if even minor version updates were at least recorded, and all feature changes organized or tagged along "beat" lines so that beat writers have a prayer -- Jjmcd
- There are both good and bad examples of how to articulate features. Perhaps those feature owners who are prose-challenged could have a writer assigned to maintain the feature page. -- Jjmcd
- Feature owners should always be CC'd on any announcements and meetings. -- rjones
- Integration of DNSSEC keys for resolving nameservers (named & unbound) with easy method of enabling/disabling.
(working on a package for this, should be up for testing soon) -- pwouters
- bullet
- bullet