Proposals/openFate
From openSUSE
Contents |
Fate open for openSUSE
Currently there is a gap in the way features for upcoming products are tracked. Novell uses Fate for feature tracking for business products, but there is not yet a possibility to benefit from Fate for the external part of the community. That is especially bad because of the fact that the openSUSE distributions are the base for the business products and thus feature tracking should really be streamlined in one place.
openFate
The proposal is to offer Fate access for all community members based on the openSUSE account through a web based application called openFate.
openFate allows to
- get a good overview of the things happing for the upcoming products
- follow and participate on the discussion by adding comments
- work on features :)
openFate gives a good overview of what features are currently discussed and what the status is.
At this stage we are not able to give full write access to all members of the community. That would result in a huge number of UNCONFIRMNED features. Mainly this is because it is not easy to check for duplicates when adding a feature. We're currently not able to process all these features which would result in frustration for the posters.
In detail, the following fields of the feature data are visible:
- Title: A one liner describing the feature
- Description: The full description
- Benefit: A text why that is beneficial for the distribution
- Testcase: A testcase description
- The requesting person
- The priority of the requester per openSUSE product
- The status per product which reflects the decision what happens to the feature for the product
- The reason for Rejection if applicable
- The discussion
What is the process around the Features at SUSE/Novell internally?
In general how we use Fate internally is: A requester, which can be either an employee or engineering partners submit feature requests to the system. The features are described textually together with testcases and benefit descriptions. Additonally the requester also sets her or his personal priority for this feature.
A newly created feature starts a discussion and decision round. All people who have input for the topic are asked to give input and have a discussion about the topic. Important persons are for example the teamleads and developer who have to add technical details and development time estimates. Interested people can add themselves to the feature to stay in the loop. Fate knows 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 as a so called priority.
These are the available priorities:
- Desirable
- The feature should be in the product if it is a lowhanging fruit.
- Important
- The product would lack an 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 eval 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 stati 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 method to track these kind of requests like Bugzilla.
How is the Process Opened?
The feature core data, discussions and status values are browseable. Comments can be added.
One should not underestimate the Fact that all features for openSUSE and the SLE Business Products are maintained in the same Fate instance. SLE feature discussions will not be opened to the public for hopefully understandable reasons. But the openSUSE features are going to be open, the discussion is transparent and people can take part not only in the development and testing phase but also already in the planning phase. We consider that as really important and true openess.
Moreover, given the fact that openSUSE is the root of SLE it is obvious that the community gets a quite direct way to influence the decision takers for SLE in this way. We are looking forward to that.
The 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.
System Setup
Here is a short journey through the technical architecture that will be set up to link the internal and external worlds together.
There is a central server which stores the feature data in an XML database. The server, called keeper, is accessible via a HTTP interface and supports requests like getting documents, saving documents, document change history, and XQuery query support (https://forgesvn1.novell.com/svn/sxkeeper/trunk/sxkeeper/). There are internal clients, mainly our KDE fat client for the full feature support and a webclient with reduced functionality to search and comment. These clients operate on the full feature data sets.
openFate is not connected directly to the keeper, but via a system called Keeper Proxy. The proxy acts interface like exactly as the Keeper, is located in the DMZ and provides the following functionality:
- Authentication: Authentication is done via iChain or users.o.o
- Data Manipulation (Way Out): KeeperProxy modifies the data on the way out and removes all confidential parts of information. The external client thus does not have to care about security at all because the information is already not longer confidential.
- Data Manipulation (Way In): On the way in the proxy adds important information back to the feature data, ie. sets default values on saving new features etc.

