Launchpad bug statuses

[Jordan Mantha]

On 10/3/07, Scott Kitterman <ubuntu at kitterman.com> wrote:
> On Thursday 04 October 2007 01:00, Emmet Hikory wrote:
>
> >    ... The parallel case of rejecting bugs
> > for which nothing is happening is already established as a manual
> > workflow (at least for Ubuntu), and so does not become worse through
> > automation (regardless of any perceived benefits or detriments to
> > users, reporters, triagers, contributors, developers, etc.).
>
> I pretty strongly disagree with this.
>
> Different teams and projects have different standards for how long is long
> enough.  In Ubuntu Backports we don't (until LP took away the choice) close
> bugs that have been incomplete as they are usually incomplete due to lack of
> sufficient testing.  This testing, depending on the package in question, may
> take quite some time.
>
> My perception is that LP developers have a "right" way to use LP in mind and
> do not appear to be very open to alternate visions.  As an Ubuntu developer,
> LP is a tool to work on Ubuntu and so the end state of the distro at release
> and through updates is what matters, not the purity of the bug database.

Well, obviously LP developers have a "right" way to use LP in mind,
they designed it. They have reasons for doing things they do, which
are not always apparent to us because they have bigger plans/goals.
The fact that LP developers regularly discuss design with users in
public (on #launchpad, launchpad-users, and in bug reports) and often
change implementations depending on our needs would, IMO, contradict
your perception.

I think it's clear that more discussion needs to take place. This
thread is evidence of that. What we need is to be on the same page so
that we understand how the LP developers designed LP to be used and
they understand how we are using LP. I'd like to thank Christian for
digging into this issue as it seems to me that it's the source of
quite a bit of friction.

In interest of trying to get something productive out of this thread
I'd like to throw out a few ideas:

  - maybe LP devs can do an "observation" day in #ubuntu-bugs during a
HUG Day to see how the Ubuntu Bug Squad is using LP.

  - is it worth documenting the bug work flow that LP developers have
in mind when they are designing new features for LP? Also getting
common use cases for contributors, MOTUs, and Core Devs may help?

  - better post-rollout support. Having a bunch of changes hit on a
Friday as developers are trying to prepare a release can be quite
frustrating, especially since Canonical employees tend to disappear on
the weekend (understandably so).

 - better pre-rollout announcement/discussion. Obviously catching
problems *before* they get rolled out is better than trying to clean
up the mess afterwards. We've seen that sending an "this is what we
just released" announcement email doesn't sufficiently inform Ubuntu
developers. It would be nice to have a "these are changes we are
planning to do for the next rollout that will affect how you work"
around a week beforehand (even if some get retargeted at the last
minute) to ubuntu-devel-announce.

These are just some random thoughts.

-Jordan