The 14-days rule of feature decision making

It is part of the decision making process of the community, and structures the way new feature proposals are handled.

The purpose of the rule is to ensure that community members have a chance to see new feature proposals and react if there is a problem with a proposal.

Feature proposals with a committed developer are accepted by default after 2 week/14 days (TheFourteenDaysRule) grace period (that is, no negative feedback/concerns means green light).

  • The 2 week/14 days grace period starts from the minute a developer commits to implementing the feature. You submit your proposal from FeatureProposals.
    • There is a proposal topic with a full spec of the feature or the change
    • A developer has put their name in CommittedDeveloper field
    • The developer has put the date of the commitment being posted in DateOfCommitment. This date cannot be a date in the past even if the proposal has been available for a long time as uncommitted proposal.
  • The clock stops the minute anyone with edit access to puts their name in the ConcernRaisedBy field.
  • The community should regularly follow what new proposals are open on NewFeatureProposals which lists both the topics where the 14-day rule applies and topics with concern raised.
  • Proposals must be in the CommittedDeveloper and DateOfCommitment state for the full 14-days before consensus can be declared, even if many community members give positive feedback. This rule ensures that community member can go away on travel for a week and come back and still have a chance to raise concern if a proposal has a problem.

See details at ReleaseProcess.
Topic revision: r4 - 02 Apr 2010, CrawfordCurrie
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy