openSUSE:Openfate process

openFATE

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

This is a proposal for the openFATE process, please help fleshing out the process - and start evaluating features so that we see how it works.

Process

openFATE uses following states:

• Unconfirmed: Initial state of a feature.
• New: A feature that needs to be evaluated by experts
• Marketplace: A feature that is ready to get implemented but is waiting for developers to grab the feature and implement it.
• Implementation: Developers have started working on it.
• Done: It's done and integrated into the next release.
• Duplicate: This feature is a duplicate of another one.
• Rejected: This feature will not be handled by the openFATE process further.

A feature that gets implemented is initially "Unconfirmed", then moves through states "New", "Marketplace", "Implementation" to the state "Done." A feature can move anytime to the states "Duplicate", "Rejected" or also "Done" (if we notice it's done already).

The evaluation happens with the change from "New" to "Marketplace". For each tag, we have an expert (or team lead) that does the evaluation. So, for the tag "GNOME" it might be Dominique, for the tag "KDE" it might be Will etc.

Until feature is marked as Done or Implementation, it stays in the "openSUSE Distribution" product as it's not clear when the feature will be really done.

Different Steps

The process (source of file) can be visualized as follows:

Evaluating unconfirmed features

This is the transition from "Unconfirmed" to "New", "Done", "Rejected" or "Duplicate":

1. Check if the feature is already implemented. If yes, mark it as "Done"
2. Check if the feature is a duplicate of an existing one. If yes, mark it as "Duplicate".
3. Check that description looks complete and the overall feature makes sense:
   • Check that URLs are given for additional information, especially if a new package should be added.
   • Check that a real benefit is explicitly mentioned: What advantage does it bring? What problem is solved?
   • If you have questions, ask the requester for more details (setting the requester as InfoProvider). Give the requester a fixed date (due in 14 days) to solve the open questions and if that does not happen, reject the feature.
4. Add tags
5. Remove all openSUSE releases from product list, leave "openSUSE Distribution" product only.
6. Finally, set the status to "New"

Evaluating new features

This is the transition from "New" to "Marketplace" and is an evaluation by an area expert. An area expert searches for features with specific tags and handles them:

1. Check if the feature is already implemented. If yes, mark it as "Done"
2. Check if the feature is a duplicate of an existing one. If yes, mark it as "Duplicate".
3. Check overall technical quality of the feature:
   • does it make sense?
   • do we want this?
   • will it break anything?
4. Set the priority of the feature
5. Move feature to state "Marketplace"

Starting to implement a feature

This is the transition from "Marketplace" to "Implementation". As soon as somebody commits doing the feature, the person should add him/herself as "Developer" and move the feature in the state "Implementation".

At this point of time, feature should be moved from "openSUSE Distribution" product to particular openSUSE release, e.g. "openSUSE 11.4".

Note that there can be more than one developer.

Finishing a feature

This is the transition from "Implementation" to "Done". The developer marks the feature as done once it's done.

Prioritizing

Each team should set themselves realistic goals, so "Mandatory" features are those that a team really likes to see in the next release. The number of "mandatory" features overall should be low so that it's easy to track them. I propose to strive for not more than 20 "mandatory" features.

Getting features done

Since we have the vote system for features, the more voted features should have the higher priority in principle. But as mentioned above, even if a feature is very important and interesting, we can't implement it if there's no one who can and will do. So my proposal is as follows:

• Every week, we'll pick up the newly requested features and introduce them in Weekly News (Heliosreds is doing this already ;-)).
• At each bi-weekly meeting, we will see the status of the features receiving the higher number (more than 30 is reasonable?) of votes. And when we find the status of such features are still 'unconfirmed', we will push forward them and search the right persons who can implement them, or at least, evaluate them.
• If we cannot find out the persons who can and will implement those features, let's widely call for volunteers by posting email to opensuse, -project, -factory and appropriate lists such as -kde or -gnome.

Cleaning up after a release

Past experience shows that after a release there are still features that are open. So, an evaluation needs to happen on what to do with them. The evaluation will do:

• Mark those features as "done" which have been done and it was forgotten to mark them as done.
• Reject those features that have not been done.

If a feature was not done for the last release, it can be moved to the next release (just create a new product and mark the feature as "New" since we want to have some evaluation again). To not postpone features forever, let's use the following rule:

• Maximal two releases: Do not move features to the next openSUSE release that have been open for more than two releases by default.

Timeline

For the openSUSE distribution, we have to evaluate features early so that they can get implemented.

Here's a proposal for timeline and goals:

• Two week before Milestone 5: Closing of the openSUSE distribution release for new features. No new features can be created.
• Milestone 5: No unconfirmed features
• Milestone 6: No features in state "new" or "marketplace"
• RC1: No open features.

Notes

Infoprovider

Bugzilla has an explicit NEEDINFO state. openFATE has no separate state but instead allows to have several people with the role "infoprovider".

Role "developer"

Note that for implementation features the role "developer" is used. For some features, the "developer" will be a system administrator or an artist. Basically "developer" means the person doing the actual work - the "implementer".

What does rejection mean?

Rejecting a feature does not necessarily mean that the feature is bad, it often means that the openSUSE project does not want to push this feature on its own and instead focus on other features.

Rejection can happen because of:

• A feature was not done in time for the integration deadline
• Nobody was found that is interested in implementing the feature
• The openSUSE team proposes to handle this via the upstream feature process and will take it from upstream
• It conflicts with some other features
• ...

Therefore, it might make sense to open a feature again for a newer release. Also, if you really want to have a feature in which was rejected because nobody volunteered doing it, you can implement it yourself and ask for the integration of it - even if the feature was rejected.

Tags

Part of the screening work when setting a feature to 'new' is adding a specific tag so the responsible expert group gets notified about the feature. They will then evaluate it and push it to the marketplace eventually.

Products

openFATE has entries for several products. The openFATE screening team "owns" the following products:

• openSUSE distribution, e.g. openSUSE 11.3
• Package Wishlist
• openSUSE.org

These products are owned by other teams that will work on features according to their own processes:

• Buildservice: Adrian Schröter and Andreas Jaeger
• Education Li-f-e: TBD
• SUSE Gallery: SUSE Studio team
• SUSE Studio Online: SUSE Studio team
• openFATE: TBD
• openSUSE Medical: Sascha Manns

---

Handling of specific requests

Let's decide on how to handle specific situations and add also friendly standard texts. Below are some proposals, please enhance them:

Bugreports

Bugs should be filled in bugzilla, you can use the following text for rejecting features:

Please report this as bug via bugzilla, details can be found via http://bugs.opensuse.org.

Upstream Features

Features for upstream packages should be filed in general upstream. For which do we want to do this ourselves? For which do we want to ask the users?

Package Wishes

Currently we see both in the product "Package wishlist" and in the openSUSE 11.x products requests for packages. I propose to handle them only in the "Package Wishlist" to avoid tracking them with each release. So, they will be rejected from the openSUSE 11.x project.

A package wish is a wish for inclusion in the next openSUSE distribution release. The first step is to build the package in the openSUSE Build Service, the second step is to get it into the factory distribution.