openSUSE:Openfate upstream projects

openFATE

Documentation - Screening team - Feature Process - Feature Teams - openFATE and upstream projects - FAQ

How upstream could benefit from Fate with KDE as example

Feature Tracking is a task that many companies/projects have to deal with. Often Bugzilla is used for it with the "enhancement" severity, which is not really suitable for that. Fate (and its webfrontend openFATE) has been designed dedicatedly for Feature Tracking and thus has some features that make it the better choice:

1. Ability to track several products per feature with own priorities and states
2. Threaded discussions with richtext-support for better and more productive communication
3. Role-based priorities (e.g. for requester, manager, ...)
4. Feature trees for visualising dependencies between features
5. customizable process definitions for ensuring data integrity, applying process policies, ...
6. ...

Fate as a whole system is released as open source software (GPL), so that others can benefit from it. Below is a proposal how it could be used in a large OpenSource project (KDE), for example.

---

KDE Fate

Mission

Fate is a communication tool which makes it possible to enhance the transparency and improve the collaboration between users and developers, but also between promotion people and downstream. It is not about forcing developers to track their work or hustling them into implementing features they don't want to do.

Infrastructure

There is a webclient (see openFATE) for KDE "users" (e.g. link it to the bugzilla accounts), to request and discuss requirements. Direct access to the database, e.g. with the KDE fat client, is given only to people with write access to KDE (=svn accounts).

Setup

The Fate products might be:

1. KDE 4.3
2. KDE 4.4
3. Promotion
4. Packaging
5. Infrastructure
6. ...

We might want to assign components (=applications in case of KDE x.x) to each of those products, in order to make it easier (automatically) to find the according maintainer (see below) to a feature. I don't think we'd need Milestones, do we?

There are the following actors defined:

1. Requester: The person (or contact in case of a distribution) requesting the feature
2. Maintainer: The maintainer of the application,... in question
3. Developer: The ones doing the work
4. Interested: People following the development of that feature
5. QA Manager: A person checking the quality of the implementation
6. Documentation Manager: The one who looks for documentation impacts and applies them

What about what in companies is called "Productmanagement"? I think we lack that a bit in KDE - people answering the question: "What features are needed to make KDE 4.3 a good, useful release?" In a company product manager role is responsible for the design of the product and thus its success in the market. We do not have that in the community because we can not really assign resources to jobs. How can we constructive cope with this situation? I think it would be a great start to create the PM-Role in the tool to simply keep them informed, I am sure that people active in KDE-Promo would be interested.

A feature is in one of the following states (per product):

1. Unconfirmed: New features enter the system in state Unconfirmed. They have yet to be screened (for duplicates, nonsense, ...)
2. New: A feature that has been screened gets the New state. At this stage, it is ensured that it's not a duplicate and a Maintainer should have been assigned.
3. Accepted (or Queued or whatever): The Maintainer has decided that it's a valid request and it should be considered for implementation.
4. Implementation: The request is being worked on.
5. Done: It's done :)
6. Duplicate: It's a duplicate of another feature
7. Rejected: Rejected because ... (there's a field "reject reason", which tells details)

The stakeholder of a feature specifies where the request comes from. There would be a "Community" stakeholder for all requests from the community and one stakeholder per distribution, that wants to requests features for KDE. Maybe a stakeholder 'core team' would be also useful, for example for handling requests inside of the core group of KDE development.

A feature has a requester priority and a maintainer priority (again, for each product). Note that a feature usually has these values for more than one product. That reflects the the real world situation that a feature might be nice to have in version n but absolutely mandatory in n+1.

So, the concrete lifecycle of a feature is:

1. A community member or a distribution contact enters the feature. It's in state Unconfirmed.
2. The screening team or the according maintainer look for validity and set it to state New.
3. Once it's decided if the feature should be done it's given the state Accepted.
4. When the actual work on the feature is started by the developer(s), they set it to Implementation.
5. When they are finished, they set it to Done.