On 12.11.2010 07:06, Satoru Matsumoto wrote:
After yesterday's openFATE screening team IRC meeting, I've overviewed recently requested features (via new instance) and got some additional impressions and questions which should be shared and further discussed.
# You can read the mention below on http://openfate.titanpad.com/notes # as well. ;-)
* Users can now request features for 'SUSE Gallary' and 'SUSE Studio Online (Hosted Service)' as well. As a part of openSUSE project, should screening team be responsible to features for 'SUSE Gallary' and 'SUSE Studio Online (Hosted Service)'?
No, I think the studio team will handle this themselves.
* Tags listed on http://en.opensuse.org/openSUSE:Openfate_screening#Tags are mostly appropriate for the features for the product "openSUSE 11.4", but not suitable for which for other products such as Buildservice, Package Wishlist, openFATE ... Do we need to prepare some more additional primary tags, or, tag them as "misc" anyway?
What we try to do at the moment is establishing a team and processes to screen mainly the opensuse distribution features. The other products get much less feature requests and may have other procedures to handle them.
* There's a newly requested feature "Include Pacman and VLC repos in OBS" https://features.opensuse.org/preview/310793 As Rémy has commented there, this feature cannot be realized due to legal issue. In such a case, may I move the status from "unconfirmed" to "rejected"?
Yes. I just added a comment to this feature.
* Look at this feature: "Please add Python Turbogears to OBS" https://features.opensuse.org/preview/310794 I think this is a kind of 'Package Wishlist'. But in this case, a user has already built the package in his home project. Can I move the status from "unconfirmed" to "done"? Or, should I ask the requester "Do you want the software to be included in standard repository?"
I asked the user if he could submit his update to the devel:languages:python project. I'm not sure if a package request is fulfilled when the package is available in a home project or in a devel project, or in factory. We probably should set up a guideline for this on our wiki page.
* The term "Customer benefit" evokes "Novell-Costomer" relationship. As a FLOSS community, we openSUSE don't have customers but users. Therefore I think it should be "User benefit".
Sure, I'll change this.
* In case the request is something like "openSUSE adopts A as default now. Let's replace A with B and set B as default!", it might be difficult to decide whether we should adopt the request or not. # You may remember the endless flame war "Default DE - KDE vs GNOME" See for example: "Include Unity as alternative GNOME GUI" https://features.opensuse.org/preview/310804 It is tagged as 'gnome' now, but I don't think GNOME people will accept including Unity *as alternative GNOME GUI*. :-P
1) Let's replace A with B and set B as default! 2) Let's add B in addition to A so that users can easily take their choice!
I think 1 and 2 have very different meanings. But sometimes it is very vague whether a feature request says 1 or 2. So the question is, how should we navigate such kind of requests?
* It takes thousands of man-hours to verify each feature request whether it is duplicated or already done. :-( We definitely need a solution for this problem.
At the moment we only have the search to find out duplicates. Greetings -- Thomas Schmidt (tom [at] opensuse.org) openSUSE Boosters Team "Don't Panic", Douglas Adams (1952 - 11.05.2001) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org