Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Scope

Life Cycle

Planned features will pass through the following statesthe begin-of-life cylce with the following status before a decision is taken whether they will be developed or not:

Status
colour

...

Yellow
titleOPEN

  • A feature or bug has been described and assignedadded but might not yet be assigned to any developer or release.
  • Open issues are assigned a release and are worked on in the course of this release.
  • The next step will be to decide, whether the feature is a Known Issue or it has to be ClarifiedCLARIFY the feature, i.e. to collect requirements and to decide on future development.

Status
colourYellow
titleCLARIFY

  • The feature or bug has to be specified before any further status is assigned. This includes to check the validity of requirements and the feasibility.
  • Issues for clarification are assigned a release and are worked on in the course of this release.
  • Users are invited to vote for the feature and to comment by adding use cases and requirements that help to specify the feature.
  • Subsequent to clarification the feature will then be ACCEPTED or DEFERRED for development, or it will be DISMISSED or classified as KNOWN ISSUE without further action.

Status
colourGreen
titleKNOWN ISSUE

  • This is not a feature, it is The feature or bug is classified as a known issue, i.e. as an inconvenience with a valid workaround available, and will by purpose not be changed.
  • Known issues are not assigned a release.
  • Being a known issue Issue is an end status for a feature, there is therefore no further decision action will be taken.

...

...

  • The issue is assigned one of the resolutions
    • the feature works as designed (resolution: works as designed).
    • the issue not being fixed (resolution: won't fix)
  • The feature has to be first discussed before a further state is decided
  • The feature can be then dismissed or accepted
    • .

Status
colourGreen
titleDISMISSED

...

  • In case the feature is NOT going to be implemented, it will be set to Dismissed.
    • Dismissed is an end status, there is no further decision taken.
  • In case the feature is going to be implemented, it will be set to Accepted.
    • At that point, the Development of the feature can be initiated.

...

  • The feature is going to be developed because it has been Accepted
  • Even though, the feature is not going to be developed for the Planned Release.
  • Another future Release will be assigned to it in order for this feature to be developed.

Example

  • The feature or bug is dismissed, e.g. due to architectural constraints or invalid requirements. The feature is not considered for future development.
  • Dismissed Issues are assigned a release and are worked on in the course of this release.
  • Being dismissed is an end status for a feature, therefore no further action will be taken.
  • The issue is assigned one of the resolutions:
    • the feature works as designed (resolution: works as designed).
    • the issue is caused by misconfiguration or misapprehension of the underlying functionality (resolution: bogus).
    • the issue not being fixed (resolution: won't fix).
    • the issue duplicating an issue and being resolved with that issue (resolution: duplicate)
    • the feature requirements being incomplete (resolution: incomplete).
    • the bug cannot be reproduced (resolution: cannot reproduce). 

Status
colourYellow
titleACCEPTED

  • The feature or bug includes valid requirements and is accepted for development with the assigned release.
  • Subsequently the feature will proceed through the Development Cycle, see Release Policy - Development Cycle.

Status
colourBlue
titleDEFERRED

  • The feature will be considered for development in a future release.
  • However, the feature is not assigned to a release. Instead, the feature is deferred for later consideration.
  • The issue has no resolution assigned (resolution: Unresolved). Therefore the issue can be voted by the users in order for the company to prioritize these issues for future releases
  • Lifecycle
    • A feature is announced as being deprecated with release 1.8:
      • This feature will still be included in all maintenance releases1.8.1, 1.8.2 etc.
    • This feature will then be announced as being unsupported from release 1.9:
      • This feature will still be included in all maintenance releases 1.9.1, 1.9.2 etc.
      • Support will not be provided if an unsupported feature should break in a release 1.9 or later
    • This feature may be removed in a subsequent release such as 1.10 or later.
  • Please note:
  • The period between releases will usually be around three months.
  • This means that you will have about six months to modify your configuration and to upgrade to replacement features.