Recently Henne Greenrock sent a status report about the Boosters Standup-Meeting here he said that nothing happened to the openFATE sprint. Well, that’s only partly true, so it seems to be time to take a closer look and revitalize the project openFATE a bit.
What’s the matter with openFATE?
We did a good start with openFATE to involve everybody who is interested into product planning. However, after the screening team was formed it turned out that some parts of the process are not yet working well. The biggest problem is still that the screening team members can not move features from state UNCONFIRMED to NEW which turned out to be crucial for a fluent process. So the Boosters picked up the task since we think this is a huge blocker to work together as a community effectivly.
The openFATE Screening Page lists a few more details about the openFATE screening team and the issues.
How are we going to solve the issues?
The Screening Team Members need additional rights. We will create a user group “openFATE Screener” which gives people in it additional rights in openFATE. For the time being, the group will be maintained within openFATE. Once we have connect.opensuse.org in place, we will use it to maintain the group setting. The important bit here is to give the screeners group the ability to maintain itself, ie. add or remove members.
Being a screener will enable people to change status of a feature from UNCONFIRMED to NEW. That is a responsible task because being in state NEW, the feature goes through the whole mill of the process, also through product and project management for SLE products. We have to make sure to have high quality features here.
Futhermore the screeners will be able to add infoproviders to features in case they know who can help there which is also a very sensible task.
Another part to work on are notifications. People should be notified when they get added to a feature. We use Hermes for that (which is already working) so the only issue is that if people who get added to a feature are not subscribed to the certain notifications in Hermes, they do not receive anything. Which is per purpose as we want to leave the control to the users. The solution to that is to inform the screeners about the Hermes subscription status of the people added. If somebody is not subscribed, its on the screener to talk to the guy and convince him to join into the openFATE game. I don’t think it makes sense to subscribe users silently because that would take away control over their subscriptions and messages get ignored as spam in the end.
Last but not least we have to solve the “I am free, pick me!”-problem, which is about features that went through the decision process and would fit nicely into a product but have no developer implementing it yet. In the company process that means that a teamlead assigns a developer from his team on that. In the community we need to change that so that people can pick the feature themselves. That has some implications to the attached internal process, so that there are still some questions open. We have to investigate a bit on that.
What has happened so far?
I was able to change the keeperproxy, which is a security relevant proxy which filters data that is going to be exposed to the internet. Moreover I was kung-fuing through the Javascript in the openFATE webapp so that it is now possible to change the status if one is screener. I also added a screener attribute to the Person-Model in the openFATE rails app. Last but not least I added the basic API functionality to get and set subscriptions to Hermes.
What needs to be done?
Well, everything that is there is still rough and needs testing and polishing. Futhermore I added the remaining tasks to Retrospectiva, please check there.
As usual we’re happy about your input on this!
