Difference between revisions of "SpecApprovalDeadline"
(Created page with "__NOTOC__ SpecApprovalDeadline (SAD) is an optional step in the release cycle: a deadline after which all unapproved specs won't be considered for inclusion in the current...") |
|||
Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
− | [[SpecApprovalDeadline]] (SAD) is an optional step in the release cycle: a deadline after which all unapproved specs won't be considered for inclusion in the current cycle. It generally happens around the second development milestone | + | [[SpecApprovalDeadline]] (SAD) is an optional step in the release cycle: a deadline after which all unapproved specs won't be considered for inclusion in the current cycle. It generally happens around the second development milestone. |
=== Freeze === | === Freeze === | ||
− | Once SAD kicks in, specs that are not yet approved will not be approved for the current development cycle. In other words, you have to get your spec for a feature you wish to land in the current cycle accepted before that deadline. | + | Once SAD kicks in, specs that are not yet approved will not be approved for the current development cycle. In other words, you have to get your spec for a feature you wish to land in the current cycle accepted ''before'' that deadline. |
=== Rationale === | === Rationale === | ||
− | SAD ensures that core reviewers don't waste time reviewing specs where the implementation is unlikely to land during the current development cycle anyway. It is generally preceded by [[SpecProposalDeadline]]. | + | SAD ensures that core reviewers don't waste time reviewing specs where the implementation is unlikely to land during the current development cycle anyway. It avoids distraction that would result in less features being delivered in the current development cycle overall. SAD is generally preceded by [[SpecProposalDeadline]]. |
=== Exception procedure === | === Exception procedure === | ||
Sometimes a feature is desired, the spec for it is basic and implementation is ready to be approved once the spec is validated. In that case you may raise an exception request by raising a specific topic to the corresponding project team meeting. Exceptions may be granted by the PTL of the affected project. | Sometimes a feature is desired, the spec for it is basic and implementation is ready to be approved once the spec is validated. In that case you may raise an exception request by raising a specific topic to the corresponding project team meeting. Exceptions may be granted by the PTL of the affected project. |
Latest revision as of 15:58, 2 July 2014
SpecApprovalDeadline (SAD) is an optional step in the release cycle: a deadline after which all unapproved specs won't be considered for inclusion in the current cycle. It generally happens around the second development milestone.
Freeze
Once SAD kicks in, specs that are not yet approved will not be approved for the current development cycle. In other words, you have to get your spec for a feature you wish to land in the current cycle accepted before that deadline.
Rationale
SAD ensures that core reviewers don't waste time reviewing specs where the implementation is unlikely to land during the current development cycle anyway. It avoids distraction that would result in less features being delivered in the current development cycle overall. SAD is generally preceded by SpecProposalDeadline.
Exception procedure
Sometimes a feature is desired, the spec for it is basic and implementation is ready to be approved once the spec is validated. In that case you may raise an exception request by raising a specific topic to the corresponding project team meeting. Exceptions may be granted by the PTL of the affected project.