Hey, Thanks for the ping. I meant to reply to this but it slipped away. Here's some relatively uncoordinated thoughts.
On Tue, Apr 03, 2012 at 02:06:11PM +0200, Sebastien Bacher wrote: > Le 30/03/2012 12:00, Iain Lane a écrit : > >Hi there, > Hey Iain, > > Thanks for writing that email, I had that on my list as well, making > sure we don't have another of those "default application selection" > session like previous UDS ;-) Right. I think that having a session named like that is probably not the most constructive use of time. Like you say it's probably better to have more focussed discussions on particular areas. > > > > >Hopefully others have thoughts about how this can work better. The main > >issue I think is to allow all stakeholders ample opportunity to make > >their representations, but the issue around how the decision is actually > >finally made is also worthwhile IMHO. > > > > > Ok, I did some thinking over that and that's what ideas I come with > (in random order): > > - we should make a public call for changes to discuss early and > froze the list of topics at two weeks before UDS > > - we should reach the concerned upstreams at least one week before > UDS (earlier if possible) to let them the opportunity to comment Yes, and the distribution developers involved too. It would be a bad idea if upstreams were forced to defend their application in long mailing list threads every six months. The desktop team can act as a filter here, vetoing choices and selecting those which should go ahead for further discussion. There should be no (if avoidable) surprises coming out of UDS sessions. > > - we want to avoid the session to turn into a "list all the things I > don't like about $software", we don't aim at stop energy but at > improving things It would be nice if issues could be communicated with upstreams /before/ it got to the stage of ditching / switching applications. Say some user testing or a survey or bug analysis or something 2-3 months after release to figure out what's working and not. > […] > So what I think we should discuss: > > - what new application we might want to get in, basically the world > change and we need re-evaluate what we ship to match that. Let's > take an example and say everybody owns an ebook nowadays, we might > consider getting a software allowing you to load books on a device > in the default install. Those discussions should be easy enough to > keep on track > > - what application we might want to drop from the CD, not because of > bugs or quality but because the world changed and we think that's > not useful anymore (i.e do we still need something to record audio > CDs installed by default in a world where less and less people use > CDs). That should also be an non troll-material discussion Yeah, it'd be good if we could come up with some usecases that we want the default desktop to support and then review and change this list which would then affect the choice of shipped software. Sort of one step removed. > > - what applications we are unhappy about, that's the "tricky" one. > > I would suggest for those to: > * not start with a "let's drop", or "let's replace" $foo, but rather > "how can we improve ..." > * not go on the "list specific bugs or issues" into that discussion, > that's often non constructive, quite the contrary > * not suggest changes for the coming cycle but rather do it over 2 > cycle: "how can we improve what we have next cycle" and "what do we > do if next cycle we are still unhappy about what we got", that > should lead to constructive discussions over what we,upstream can do > over next cycle without blocking us too much If we can find out earlier on what's not working well then we'll be able to feed this back to upstreams so that they can plan accordingly. It shouldn't be a case of "fix this in the next six months or we're dropping you". UDS timing is a bit unfortunate in this regard because it comes too soon after release to have real user feedback but we're trying to make decisions for a release which is happening in only six months time. > I would rather like to see the session being focussed on the Ubuntu > weaknesses and how we work toward resolving those rather than on > pointing what doesn't work. Yes. If there's to be a general session then I think it shouldn't be about default application selection, but rather about the quality of the desktop in the previous release and what we should tweak, and the session lead should be strong in stopping unproductive discussions from happening. Thanks for your input, -- Iain Lane [ [email protected] ] Debian Developer [ [email protected] ] Ubuntu Developer [ [email protected] ] PhD student [ [email protected] ]
signature.asc
Description: Digital signature
-- ubuntu-desktop mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
