OpenFATE documentation

From openSUSE

(Redirected from OpenFATE/Documentation)
openFATE:
Documentation - Screening team - openFATE and upstream projects - FAQ


openFATE is the community interface to the SUSE Linux feature database. Everyone who wants to request a feature for the SUSE Linux common codebase should use openFATE to submit the proposed feature for evaluation and planning. If the feature is approved for inclusion in the release, Fate tracks the development and testing of that feature.

Please also read our FAQ page.

Contents

Using openFATE

What is a Feature?

Institute of Electrical and Electronics Engineers defines a feature as a distinguishing characteristic of a software item (e.g., performance, portability, or functionality)[1]

Simple said: For openSUSE a feature is something significant which doesn't exist in the previous version and should be added to the version under development. Best would be it addresses the need of many users and not only few. Of course, some of these feature are a matter of resources, request and taste--thus do not be disappointed if your feature gets rejected. To avoid this you should describe the requested feature as understandable as possible and always talk about the benefit of the feature for the user.

Do not confuse features with bugs. Bugs are defects in existing products. That means some software doesn't work as expected/described in a existing product. With a bug you should go to openSUSE Bugzilla and open a bug that it can be fixed. With in enhancements it is similar. First, what is an enhancement?

  • Some software works in an existing product but it might need some improvement to fulfill its tasks even better or with raised performance.


Creating a Feature

Everyone with an openSUSE account is empowered to create features. Proceed as follows:

  1. At https://features.opensuse.org/, click Create.
  2. Enter a short Title such as Adjust Colors of the Default Desktop Wallpaper.
  3. Select the Product, for example openSUSE-11.3
  4. You can leave the Priority untouched.
  5. Add a concise Description, for example [in the meantime (11.2), this issue is fixed!]:
 In GNOME, the color of the default desktop theme and the colors of the
 default wallpaper do not fit.  Especially look at the title bar of the
 active window.
  1. Depending on the kind of the feature, add a Usecase and a Testcase by clicking on Add a Usecase and Add a Testcase.
  2. Finally click Save feature.

How Does the Feature Process Work?

Creating a Feature usually is the initial step. Then a discussion and decision round starts. All people who can contribute input to the topic are asked to add comments. Important persons are for example teamleads and developer who have to add technical details and development time estimates. Interested people can add themself to the feature to stay in the loop. Fate knows about all these roles.

The discussion and feature refinement phase is meant to give the responsible people, that is the product and the technical project manager for the product, the base for a good decision about the feature. They give the result of their decision a so called priority.

These are the available priorities:

Desirable
The feature should be in the product if it is a low-hanging fruit.
Important
The product would lack important functionality without this feature.
Mandatory
Missing this feature is a showstopper.
Neutral
No opinion for any reason.

There is the field state that reflects the actual state of the feature in the process. The feature starts in the NEW or UNCONFIRMNED state until somebody adds a bunch of responsible people to it and puts it into one of the evaluation states. The evaluation states give people time to come to a decision. Finally the feature goes into the status either "Candidate" which means it is accepted and worked on or "Rejected" which means that the feature is not considered for that product.

It is important to understand that priorities and status are set on a per-product base. That means that even if a feature is rejected for product A it might show up in product B. This is one of the big benefits of Fate over other methods to track these requests like in Bugzilla.


How is the Process Opened?

The feature core data, discussions and status values are browseable. Comments can be added by everybody with an openSUSE login.

Features coming in for openSUSE differentiate from others through a special field in the feature data called partner. That fields gets automatically set to openSUSE by openFATE.


Browsing and Commenting the Feature Database

Finding a Feature

  1. At https://features.opensuse.org/, click Browse.
  2. Specify search criteria. For example, a keyword such as "color" in the Title/Description contains field. Or, if you are interested in all done features for a product, for example select "openSUSE-11.2" in the Product(s) list and "done" in the Status field.
  3. Click Search.

If you know the feature ID, enter the ID in the upper right field and click the search symbol.

Once you have found the feature you are interested in, read it and add a comment.

Commenting a Feature

Below Discussion click "add comment" to open a text edit box. To save your comment click "Add comment" below the edit box. Finally click Save feature to store your comment in the feature database.

Once comments are available, you can refer to a comment directly by clicking reply.

Voting for features


The voting widget is displayed on the upper right side of a feature. It shows the current score of a feature, and you can see a history of the votes on "toggle statistics". To give a vote, please login, and you will have the three options "down", "neutral" and "up" when hovering over the voting applet. Please use the voting to show your favourite features, and don't misuse the comments for that, as that only makes the feature view confusing. Votes on a feature will help to indicate the importance of a feature but aren't the sole source to make a decision.

Stay informed

To stay informed on what's going on in general with features or with my features we offer different services.

Notification service Hermes
You're interested in a feature. How can you efficiently follow the discussion or add comments when necessary? For that our smart notification service Hermes is the perfect fit. There you can subscribe to notifications and define how and in which frequency you want to get notified.
RSS feed
Just subscribe to our RSS feed and you stay informed about all feature changes happen.
Feature mailing list
For all interested in everything just subscribe to the feature mailinglist where all changes to openFATE entries are distributed.

Detailed definition of feature attributes

A feature is described by a number of attributes. What the attributes mean and how they should be filled in is described below.

Title A very brief one-line description of the feature request. (Example: "Improved argument handling for zypper")

Tags Tags are keywords associated with a feature (see also http://en.wikipedia.org/wiki/Tag_(metadata)). The tag cloud is created from all feature tags, the more often a tag is used, the bigger it will be rendered in the tag cloud.

Products One or more products for which the feature is requested. Each product is tracked by a seperate state, so maybe your feature gets rejected for openSUSE 11.2, but implemented for 11.3, for example.

Priority Specifies the priority this feature has for the corresponding actor.

  • Mandatory: This feature is absolutely needed. The product cannot be shipped with non-implemented mandatory features
  • Important: The feature has a significant benefit and should be implemented if feasible.
  • Desirable: The feature adds value to the product, but can be dropped from the list of requirements or moved to a later release if necessary.
  • Neutral: This feature is of low priority.

Please note that giving a feature request a high priority does not entitle you to actually insist on openSUSE implementing the feature for the next release of the product.

Actors

  • Requester: The contact for openSUSE when needing further details or clarification about the feature request. When creating a new feature, the requester is automatically set to the authenticated user.
  • Interested Person: Add yourself as "Interested Person" when you want to have the feature be available in your watchlist.
  • Developer: The developer is responsible for implementing the feature. This can be a Novell person, or an external community member.

Description

Describe the feature request clearly enough so the intent of the request can be understood without any additional context information.

If possible, add a short use-case scenario.

Don't include multi-page specifications, code snippets, or kernel patches here. Better provide URL hyperlinks for such kind of data.

Please mention if you know about an existing implementation for the request or can provide a patch.

Stakeholder benefit

Which benefit has the feature stakeholder from implementing this feature.

Richtext

Data for the fields description, comment, usecase can be entered as richtext. openFATE supports the following richtext elements:

   <p>...</p>
   New paragraph
   <pre>...</pre>
   Preformated text. All contained text is printed as typed.
   <h3>...</h3>
   Headline
   <ul>...</ul>
   Bulleted (unordered) list. Needs to contain <li>...</li> elements
   <ol>...</ol>
   Ordered list. Also needs to contain <li>...</li> elements
   <a href="http://host.domain/path/">...</a>
   Hyperlink to another ressource in the internet
   <b>...</b>
   Bold text
   <em>...</em>
   Italic text
   <tt>...</tt>
   Typewriter font