[opensuse-project] Some additional comments, thoughts and questions about openFATE screening
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)'? * 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? * 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"? * 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?" * 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". * 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. Best, -- _/_/ Satoru Matsumoto - openSUSE Member - Japan _/_/ _/_/ Marketing/Weekly News/openFATE Screening Team _/_/ _/_/ mail: helios_reds_at_gmx.net / irc: HeliosReds _/_/ _/_/ http://blog.zaq.ne.jp/opensuse/ _/_/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
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
On Friday 12 November 2010 07:06:54 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. ;-)
As mentioned yesterday, I've tried to answer many of the open questions in a better way and thus created a new page: http://en.opensuse.org/openSUSE:Openfate_screening_process Please read through it and comment on whatever questions are open. I also updated the following page: http://en.opensuse.org/openSUSE:Openfate_screening I've tried to answer some of your questions already, so let me give references as appropriate. Feel free t o improve my description on the wiki - and whenever you disagree, please speak up. We're creating a new process from scratch and out of my experience with FATE inside Novell I propose the process but it's our team's process ;)
* 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)'?
I don't think so, here's my current understanding: http://en.opensuse.org/openSUSE:Openfate_screening_process#Products
* 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?
I guess we have to create different tags for different products.
* 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, you may.
* 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?"
IMO Package Wishlist describes packages for the openSUSE distribution and I've documented this at: http://en.opensuse.org/openSUSE:Openfate_screening_process#Package_Wishes
* 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".
Agreed - and thanks for Tom for changing it.
* 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?
Let's discuss these requests on our IRC meeting or via email. I'm adding a section to the IRC meeting now called: Discussion of specific features.
* 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.
We do not need to be perfect, it's ok if we filter out only 50 percent in the first step, since the area experts will do this step as well. Sure, the earlier we filter them out, the less work it is for everybody... thanks for your comments! Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hi! On piatok 12 November 2010 07:06:54 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. ;-)
I was thinking about the issue of postponing features. I would propose to use the 'Package Wishlist' approach, i.e. use backlog The idea is to use collect all features that are not ready to be integrated into a release (underdefined, no good solution found, ...) in a backlog bag. Only when we have an idea, how to implement a feature, ideally to have already someone willing to work on the feature, the feature would be marked for particular release. This approach will eliminate postponing features forever, at least for big number of features where this would happen. Also, it would keep us from cleaning up huge list of features for each release. Did we consider this approach before? If yes, what are the reasons against it? Stano -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tuesday 16 November 2010 13:33:18 Stanislav Visnovsky wrote:
Hi!
On piatok 12 November 2010 07:06:54 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. ;-)
I was thinking about the issue of postponing features. I would propose to use the 'Package Wishlist' approach, i.e. use backlog
The idea is to use collect all features that are not ready to be integrated into a release (underdefined, no good solution found, ...) in a backlog bag. Only when we have an idea, how to implement a feature, ideally to have already someone willing to work on the feature, the feature would be marked for particular release.
This approach will eliminate postponing features forever, at least for big number of features where this would happen. Also, it would keep us from cleaning up huge list of features for each release.
Did we consider this approach before? If yes, what are the reasons against it?
I have been considering as well a general "openSUSE distribution" product but was not sure how to do it properly. Could you elaborate a bit more when this backlog will be used and what will be done with e.g. openSUSE 11.4? Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hi! On utorok 16 November 2010 16:59:28 Andreas Jaeger wrote:
On Tuesday 16 November 2010 13:33:18 Stanislav Visnovsky wrote:
Hi!
On piatok 12 November 2010 07:06:54 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. ;-)
I was thinking about the issue of postponing features. I would propose to use the 'Package Wishlist' approach, i.e. use backlog
The idea is to use collect all features that are not ready to be integrated into a release (underdefined, no good solution found, ...) in a backlog bag. Only when we have an idea, how to implement a feature, ideally to have already someone willing to work on the feature, the feature would be marked for particular release.
This approach will eliminate postponing features forever, at least for big number of features where this would happen. Also, it would keep us from cleaning up huge list of features for each release.
Did we consider this approach before? If yes, what are the reasons against it?
I have been considering as well a general "openSUSE distribution" product but was not sure how to do it properly. Could you elaborate a bit more when this backlog will be used and what will be done with e.g. openSUSE 11.4?
Right now, most of the features are not really specific for release. They are ideas that might be good to be implemented. As we don't know better, right now we assign them to the next openSUSE release and keep that postponing for the ones that did not get done (majority). So, I would introduce an "incubator" for ideas - where even a short description is enough. From here, the openFate screening team picks them up, works on filling details up to the point where the idea is sufficently understood to be implemented (status "Marketplace").At this point, we need to find someone willing to implement the thing - and if there is someone, this feature can be finally moved to particular release (because only here more or less know the timeframe when it's going to be ready). It's similar to agile approach, but much better reflects the reality how we do openSUSE IMO. There is a question of the 'picks for next release' - those 5 mandatory features we want to focus on. For them, we might want to assign the release already in the Marketplace state. I don't have a good answer if to use Products for this or States. Products seems to be more natural choice given the way openFate works right now. Might be the case the current openFate does not fit this proposal. I would like to hear your opinions, if this is direction makes sense to others. Stano -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On 19.11.2010 11:06, Stanislav Visnovsky wrote:
Hi!
On utorok 16 November 2010 16:59:28 Andreas Jaeger wrote:
On Tuesday 16 November 2010 13:33:18 Stanislav Visnovsky wrote:
Hi!
On piatok 12 November 2010 07:06:54 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. ;-)
I was thinking about the issue of postponing features. I would propose to use the 'Package Wishlist' approach, i.e. use backlog
The idea is to use collect all features that are not ready to be integrated into a release (underdefined, no good solution found, ...) in a backlog bag. Only when we have an idea, how to implement a feature, ideally to have already someone willing to work on the feature, the feature would be marked for particular release.
This approach will eliminate postponing features forever, at least for big number of features where this would happen. Also, it would keep us from cleaning up huge list of features for each release.
Did we consider this approach before? If yes, what are the reasons against it?
I have been considering as well a general "openSUSE distribution" product but was not sure how to do it properly. Could you elaborate a bit more when this backlog will be used and what will be done with e.g. openSUSE 11.4?
Right now, most of the features are not really specific for release. They are ideas that might be good to be implemented. As we don't know better, right now we assign them to the next openSUSE release and keep that postponing for the ones that did not get done (majority).
So, I would introduce an "incubator" for ideas - where even a short description is enough. From here, the openFate screening team picks them up, works on filling details up to the point where the idea is sufficently understood to be implemented (status "Marketplace").At this point, we need to find someone willing to implement the thing - and if there is someone, this feature can be finally moved to particular release (because only here more or less know the timeframe when it's going to be ready).
It's similar to agile approach, but much better reflects the reality how we do openSUSE IMO.
There is a question of the 'picks for next release' - those 5 mandatory features we want to focus on. For them, we might want to assign the release already in the Marketplace state.
I don't have a good answer if to use Products for this or States. Products seems to be more natural choice given the way openFate works right now. Might be the case the current openFate does not fit this proposal.
I would like to hear your opinions, if this is direction makes sense to others.
I think it makes sense to collect the features in this incubator product. At the moment we need to reject and move features to the next product on and on... We had such a bucket product some time ago, and it got removed. But I think that was because it did not make sense for business products. But we should also have a procedure that features do not rot forever in the incubator product which also makes a bad impression. Greetings -- Thomas Schmidt (tschmidt [at] suse.de) SUSE Linux Products GmbH :: Research & Development :: Tools "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
On piatok 19 November 2010 17:32:12 Thomas Schmidt wrote:
On 19.11.2010 11:06, Stanislav Visnovsky wrote:
Hi!
On utorok 16 November 2010 16:59:28 Andreas Jaeger wrote:
On Tuesday 16 November 2010 13:33:18 Stanislav Visnovsky wrote:
Hi!
On piatok 12 November 2010 07:06:54 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. ;-)
I was thinking about the issue of postponing features. I would propose to use the 'Package Wishlist' approach, i.e. use backlog
The idea is to use collect all features that are not ready to be integrated into a release (underdefined, no good solution found, ...) in a backlog bag. Only when we have an idea, how to implement a feature, ideally to have already someone willing to work on the feature, the feature would be marked for particular release.
This approach will eliminate postponing features forever, at least for big number of features where this would happen. Also, it would keep us from cleaning up huge list of features for each release.
Did we consider this approach before? If yes, what are the reasons against it?
I have been considering as well a general "openSUSE distribution" product but was not sure how to do it properly. Could you elaborate a bit more when this backlog will be used and what will be done with e.g. openSUSE 11.4?
Right now, most of the features are not really specific for release. They are ideas that might be good to be implemented. As we don't know better, right now we assign them to the next openSUSE release and keep that postponing for the ones that did not get done (majority).
So, I would introduce an "incubator" for ideas - where even a short description is enough. From here, the openFate screening team picks them up, works on filling details up to the point where the idea is sufficently understood to be implemented (status "Marketplace").At this point, we need to find someone willing to implement the thing - and if there is someone, this feature can be finally moved to particular release (because only here more or less know the timeframe when it's going to be ready).
It's similar to agile approach, but much better reflects the reality how we do openSUSE IMO.
There is a question of the 'picks for next release' - those 5 mandatory features we want to focus on. For them, we might want to assign the release already in the Marketplace state.
I don't have a good answer if to use Products for this or States. Products seems to be more natural choice given the way openFate works right now. Might be the case the current openFate does not fit this proposal.
I would like to hear your opinions, if this is direction makes sense to others.
I think it makes sense to collect the features in this incubator product. At the moment we need to reject and move features to the next product on and on... We had such a bucket product some time ago, and it got removed. But I think that was because it did not make sense for business products. But we should also have a procedure that features do not rot forever in the incubator product which also makes a bad impression.
I don't think it's a problem if a feature stays in Incubator for long time. This should not happen for features that get votes though. Stano -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
participants (5)
-
Andreas Jaeger -
Satoru Matsumoto -
Stanislav Visnovsky -
Thomas Schmidt -
Thomas Schmidt