Proposed Features for Launchpad Bugs 3.0 - call for help!
Christian Robottom Reis
kiko at canonical.com
Sat Aug 23 14:57:13 BST 2008
On Wed, Aug 06, 2008 at 05:15:21PM +0200, Reinhard Tartler wrote:
> My current impression is that the list of specs is too long.
Thanks for following up and providing us with input. The point you make
above is dear to me -- we do really have lots of work to do. This ties
into another point you make:
> Having said this, I have a urgent plea: If you implement a spec, please,
> pretty please think about who is going to be affected by a change, and
> talk to them before starting to change launchpad. Any change that has
> the potential to have an effect on workflows we already agreed on is
> very likely to cause confusion and anti-sentiments. This already has
> happened in the past, unfortunately. And the answers I received so far
> support these observations.
I've struggled with this over the past two years, and in less than a
year we will be open sourced. I understand that existing end-users are
very much affected by changes, but on the other hand, we need to change
Launchpad in order to make it better. On top of that, when we do get
feedback it is very varied -- some users really like the changes, but
others, not that much. Additionally, if you've read `Don't Shoot the
Dog', you'll understand me when I say that the negative feedback we do
get doesn't encourage us to seek out more!
I have been thinking about ways of getting better input into what's
being changed in Launchpad. One thing that hurts us is that we do want
to keep our rate of change high, and any process around making a change
affects it. Our milestone lists are very public and it is today possible
to subscribe to a milestone and get notifications to bugs added and
removed from it. So it would not be impossible to keep track of what's
changing in Launchpad -- unfortunately, I think the traffic and level of
detail may not be for everybody.
One thing that will change for 3.0 is that our priority lists will be
publically available and you will be able to tell from them (and the
milestone) what is likely to be worked on in the near future. I would
like to find a good process to invite feedback on our changes. The
immediate thing that comes to mind is a period notification reminding
users of the current priority list and milestones. We could send one out
once a milestone. Does that sound like a good idea, or too much detail?
And who is the right channel and audience for such a notification?
A final note to MOTU specifically following upon the "varied feedback"
point I made above. We really do want your feedback. However, it makes
/my/ work much less effective when the feedback we do get is conflicting
or negative. Presenting balanced, consistent guidance to my team is the
best way for you to ensure we do what you want -- I know it's hard, but
it's really the right way to do it.
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3376 0125
More information about the Ubuntu-motu