Re: [Desktop 13.04-Topic] Discussing PS-related product processes
Thanks to the one that considered, that there are not only desktop developpers are reading here :-| -- Best Thomas Am Montag, den 15.10.2012, 13:21 +0500 schrieb Omer Akram: In case anyone does not know what PS stands for (which I am sure many don't). Its Product Strategy previously called DX-team. On Mon, Oct 15, 2012 at 12:43 PM, Didier Roche didro...@ubuntu.com wrote: Hey everyone, as you probably know already, PS is our upstream for a lot of desktop components nowadays (Unity, compiz, webapps, indicators, multi touch stack…). The past cycle has been a real ride in term of features, which spawn the release team, translation team and documentation team with FFe/UIFe. We need to discuss a way to ease the process in both ways with all involved parts. Seeing the importance of those components on our stack today, I think for instance that having a standing FF/UIF exception as we have for GNOME components in ubuntu will make sense. However, the counter-part will be that PS will work on getting things landing only when they are ready, to avoid further and further refinements (and additional documentation changes) as we had in the past just to match the date gate. So this one can clearly be a win-win situation. Also, I want to discuss about what can land in a SRU. Little (few pixel move) change, not really impacting the documentation may want to be considered. We currently have 2 examples we can discuss in the session: - https://bugs.launchpad.net/unity/+bug/1043808 (Dash: Preview activation doesn't have instant feedback). Design worked on a spinner to partially address this one. This is a behavior change in some way, for a transient state, however it can be completely acceptable in a SRU as it will make the quantal experience better and don't change doc/add new strings, and so on. - Another one is the ribbon on the application lens for software-center content. This one is giving (due to pixelized images with the magazines) a lot of headaches to design and they would want to remove it. This specific case is an UI change, but doesn't seem it would impact the understanding of the lens. We can base the UDS discussion on those examples to see how we can get the process smoother and more reliable for everyone in the next cycle and going on. :) Cheers, Didier -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Desktop 13.04-Topic] Discussing PS-related product processes
Hey everyone, as you probably know already, PS is our upstream for a lot of desktop components nowadays (Unity, compiz, webapps, indicators, multi touch stack...). The past cycle has been a real ride in term of features, which spawn the release team, translation team and documentation team with FFe/UIFe. We need to discuss a way to ease the process in both ways with all involved parts. Seeing the importance of those components on our stack today, I think for instance that having a standing FF/UIF exception as we have for GNOME components in ubuntu will make sense. However, the counter-part will be that PS will work on getting things landing only when they are ready, to avoid further and further refinements (and additional documentation changes) as we had in the past just to match the date gate. So this one can clearly be a win-win situation. Also, I want to discuss about what can land in a SRU. Little (few pixel move) change, not really impacting the documentation may want to be considered. We currently have 2 examples we can discuss in the session: - https://bugs.launchpad.net/unity/+bug/1043808 (Dash: Preview activation doesn't have instant feedback). Design worked on a spinner to partially address this one. This is a behavior change in some way, for a transient state, however it can be completely acceptable in a SRU as it will make the quantal experience better and don't change doc/add new strings, and so on. - Another one is the ribbon on the application lens for software-center content. This one is giving (due to pixelized images with the magazines) a lot of headaches to design and they would want to remove it. This specific case is an UI change, but doesn't seem it would impact the understanding of the lens. We can base the UDS discussion on those examples to see how we can get the process smoother and more reliable for everyone in the next cycle and going on. :) Cheers, Didier -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop 13.04-Topic] Discussing PS-related product processes
In case anyone does not know what PS stands for (which I am sure many don't). Its Product Strategy previously called DX-team. On Mon, Oct 15, 2012 at 12:43 PM, Didier Roche didro...@ubuntu.com wrote: Hey everyone, as you probably know already, PS is our upstream for a lot of desktop components nowadays (Unity, compiz, webapps, indicators, multi touch stack…). The past cycle has been a real ride in term of features, which spawn the release team, translation team and documentation team with FFe/UIFe. We need to discuss a way to ease the process in both ways with all involved parts. Seeing the importance of those components on our stack today, I think for instance that having a standing FF/UIF exception as we have for GNOME components in ubuntu will make sense. However, the counter-part will be that PS will work on getting things landing only when they are ready, to avoid further and further refinements (and additional documentation changes) as we had in the past just to match the date gate. So this one can clearly be a win-win situation. Also, I want to discuss about what can land in a SRU. Little (few pixel move) change, not really impacting the documentation may want to be considered. We currently have 2 examples we can discuss in the session: - https://bugs.launchpad.net/unity/+bug/1043808 (Dash: Preview activation doesn't have instant feedback). Design worked on a spinner to partially address this one. This is a behavior change in some way, for a transient state, however it can be completely acceptable in a SRU as it will make the quantal experience better and don't change doc/add new strings, and so on. - Another one is the ribbon on the application lens for software-center content. This one is giving (due to pixelized images with the magazines) a lot of headaches to design and they would want to remove it. This specific case is an UI change, but doesn't seem it would impact the understanding of the lens. We can base the UDS discussion on those examples to see how we can get the process smoother and more reliable for everyone in the next cycle and going on. :) Cheers, Didier -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop 13.04-Topic] Discussing PS-related product processes
On 10/15/2012 02:43 AM, Didier Roche wrote: Hey everyone, as you probably know already, PS is our upstream for a lot of desktop components nowadays (Unity, compiz, webapps, indicators, multi touch stack...). The past cycle has been a real ride in term of features, which spawn the release team, translation team and documentation team with FFe/UIFe. We need to discuss a way to ease the process in both ways with all involved parts. Seeing the importance of those components on our stack today, I think for instance that having a standing FF/UIF exception as we have for GNOME components in ubuntu will make sense. However, the counter-part will be that PS will work on getting things landing only when they are ready, to avoid further and further refinements (and additional documentation changes) as we had in the past just to match the date gate. So this one can clearly be a win-win situation. AIUI, GNOME only has a MicroRelease exception, not a standing FF/UIF exception. If Feature Freeze were targeted for Features, then there are about 2 months left in the cycle to clean up any bugs. Also, the time between Feature Freezes is about 6 months, so if their schedule were adjusted to focus on Feature Freeze instead of the release date, you'd still get about 6 months of feature work into the release (it also means you get 2 months of polish as well). Obviously, if something slips, there's still the exception process, but that should be the exception, not the rule. Thanks, Micah -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop 13.04-Topic] Discussing PS-related product processes
Adding ubuntu-doc to the CC list as this seems more a FF/UIFE discussion than a -desktop discussion. On 15 October 2012 03:43, Didier Roche didro...@ubuntu.com wrote: Hey everyone, as you probably know already, PS is our upstream for a lot of desktop components nowadays (Unity, compiz, webapps, indicators, multi touch stack…). The past cycle has been a real ride in term of features, which spawn the release team, translation team and documentation team with FFe/UIFe. We need to discuss a way to ease the process in both ways with all involved parts. Seeing the importance of those components on our stack today, I think for instance that having a standing FF/UIF exception as we have for GNOME components in ubuntu will make sense. However, the counter-part will be that PS will work on getting things landing only when they are ready, to avoid further and further refinements (and additional documentation changes) as we had in the past just to match the date gate. So this one can clearly be a win-win situation. I believe standing feature freeze exceptions need a history of doing the right thing, which is not how I would describe what happened for quantal. Otherwise, it seems to me that giving the developers and designers more official permission to break the freezes they are already breaking would make the problems worse. Or to put it another way, PS really really needs to land these features closer to the beginning of a cycle in the regular archives (not a PPA) to get near-real-world testing so that there is time for polishing. I wonder if the emphasis on keeping Ubuntu+1 working has gone too far and if we are actually pushing Ubuntu developers to land new features late. Also, I want to discuss about what can land in a SRU. Little (few pixel move) change, not really impacting the documentation may want to be considered. We currently have 2 examples we can discuss in the session: - https://bugs.launchpad.net/unity/+bug/1043808 (Dash: Preview activation doesn't have instant feedback). Design worked on a spinner to partially address this one. This is a behavior change in some way, for a transient state, however it can be completely acceptable in a SRU as it will make the quantal experience better and don't change doc/add new strings, and so on. Adding a busy spinner seems harmless enough and wouldn't impact docs or translations. I don't think it would make much of a difference for video reviews. On the other hand, I wouldn't want to see animations change near Final Freeze or after. - Another one is the ribbon on the application lens for software-center content. This one is giving (due to pixelized images with the magazines) a lot of headaches to design and they would want to remove it. This specific case is an UI change, but doesn't seem it would impact the understanding of the lens. I need more information about that issue. We can base the UDS discussion on those examples to see how we can get the process smoother and more reliable for everyone in the next cycle and going on. :) Cheers, Didier Thanks, Jeremy -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
