Incomplete with no response >30 days

[Yuriy Kozlov]

> However, in the end, we all want the bugs to be fixed. And this is
> getting more complicated if the bugsquad does things that intervenes
> with the developers work. And editing bugs without understanding them is
> a severe intervention, because it causes confusion on both the reporters
> and the developers side.
>
> So a pretty please with sugar on the top: If you don't understand what a
> bug is about, please do not touch it. This includes all what is recently
> called a "workflow bug".
>

I was going to post a rant (ok, still will) about making proper use of
the statuses, then I finally looked at the original bug in question,
and looks to me like Incomplete was the right status and this really
is a case of **"If you don't understand what a bug is about, please do
not touch it."**

That said, responses from developers in this thread do seem to imply
that once they are working on something, bug status is ignored, as
well as some disrespect for people trying to help them out and
learning.  Bug statuses and the other tools available in Malone, such
as tags, let *everybody* know what's going on.  Not using them or
abusing them makes things confusing for the reporter, any other user
looking at the bug, bug squaders looking to help, new developers
looking to help, other developers, and they can even be useful to the
developer working on the bug if they have a lot on their plate.  Using
the given example, bugs that are marked In Progress but not assigned
to anyone (nothing wrong with being assigned to a team) are silly and
confusing.  Using sensible uniform conventions throughout the process
keeps the machine working efficiently.

Workflow bugs are great, the bug tracker is a good way to keep track
of things and it lets others know what's going on, if you use it
properly.  But there is no reason they can't fit into the rest of the
system.  And if they really, really don't (and I don't think that's
the case.  Again, in this particular case, the triager probably
shouldn't have messed with a report he didn't understand) then put
some form of disclaimer on top.  And greasemonkey scripts[1] don't
count!

Yes, the point of the bug squad is to make it easier for developers to
actually fix the bugs.  [I assume] the bug squad guidelines were
written with developer input on how to make bug reports useful to
them, and eliminate the ones that aren't. If there is some convention
that hurts the workflow overall, then it should be revised.  But
throwing them out only makes things confusing for everyone.  Remember
that [almost] everything on Launchpad is public and can be viewed and
edited by anybody for various reasons, most of them trying to help in
some way.  There are 9 statuses, importance, assignee, tags,
description, comments, and more tools that let you express what's
going on to users, triagers, and developers.  Use them.

~ Yuriy

[1] https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-May/000851.html