Features/F10PolicyReview

From FedoraProject

Jump to: navigation, search

Contents

Fedora 10 Feature Policy Review

This page is to track changes and discussion changes to the Fedora 10 feature process based on our experiences during Fedora 9 development. This is a public white board--everything is up for discussion.

Background

Proposal

  • Circulate request for feedback and constructive suggestions for improvement for a one week period ending with a FESCo vote to ammend the existing policy as directed or leave it as it is on 2008-05-29.

Tracking Bugs

  • Jesse Keating has proposed that a tracking bug be created for each new feature and used to block the release blocker bug.

Better Test Plans

  • Will Woods has proposed that Features not be accepted by FESCo that do not contain suitable information on how to test them. The thought here is that QA cannot always readily divine the expected behavior of new features so the developer should provide a clear test plan which explains how the new feature should be tested and what the expected behaviors are.

Empty Feature Page Sections

  • John Poelstra has proposed that feature pages without any information or substance for Documentation or Release Notes or other sections be deferred for review by FESCo until they are provided and substantive
  • This includes sections that are completely empty or provide no information like "See upstream" or "Need to create some" or "This doesn't need a release note", etc.

Feedback for incomplete feature pages

  • Plan to add a separate section at the bottom of the feature page
  • Will remove comments once feature is accepted
  • Once a page has been reviewed and not ready for acceptance it will be changed back to CategoryProposedFeature

Reduce FESCo overhead

  • Jason Tibbitts--FESCo spent much of its time in the F9 cycle dealing with features. Can we offload this to a subcommittee or SIG and only provide a FESCo comment period as we do with Packaging Committee reports?