Incomplete with no response >30 days

[Reinhard Tartler]

Wolfger <wolfger at gmail.com> writes:

> The current case in point: This thread arose because I touched a
> workflow bug when I shouldn't have. In theory, your request would have
> stopped me (I didn't understand, so I shouldn't have touched it), but
> in reality your request does not stop me, because:
> a) I didn't know (and still really don't, aside from bdmurray's
> greasemonkey script) how to tell a workflow bug from a regular bug

Waaait a minute. I now assume that you are talking about
http://launchpad.net/bugs/154730? How much more clear can the
title "Please remove secvpn source and binary from Hardy" with the
team "Ubuntu Package Administrators" subscribed and a valid and
understandable rationale in the bug description be?

You definitly need to read the bug to understand it.

> b) I didn't know (but now do) that the rules are different for
> workflow bugs than non-workflow bugs

Just by looking at that particular bug should have have given you the
hint that this bug does not need any attention by the bugsquad team. It
has been filed by an developer following the procedures given by the
ubuntu package administrators with very clear instructions and
rationale.

And btw, the point of actually reading before acting is pretty valid for
non-workflow bugs as well. If it wasn't, I'd we should change bugs like
that fully automatically. However, this tends to cause a lot of fallout
which we don't like. That's why we use humans to triage and do
housekeeping on that bugs, because people usually do think before
acting. [1]




> So your request does nothing to stop somebody from touching something
> they don't understand, if they think they understand it. Understand?

I don't think this needs any more commenting.




>> Leaving out the most important sentence of my mail is not going to help
>> a productive conversation.
>
> Well, I went back and re-read that entire paragraph (all two sentences
> of it), and did not see anything mitigating the accusation that some
> nameless group is being malicious. Please help me out and tell me what
> the most important sentence is.

Let me see:

Quoting from <874p8ldpu9.fsf at faui44a.informatik.uni-erlangen.de>:
>> If there is a group of people randomly and cluelessly
>> editing bugs, they must be stopped in order to enable developers to work
>> effectivly. I don't have the impression that the bugsquad is such an
>> group, at least not yet. However the arguments you rised in your mail
>> could be interpreted this way. That's why this email is so harsh.




> the thread arose because:
> 1) There was no easy way to tell one specific (and small) subcategory
> of bugs apart from the main

I agree. However there is a straightforward way: Actually reading and
understanding the bug you are touching.

> 2) The subcategory has special rules and does not follow the
> "standard" rules for status.
> 3) The dev who owned the bug (but did not assign it to himself) got
> rather snippy with me when I touched it.

Which I acknoledge that it is a problem that should be fixed. I
agree. Let's work together on that.



Perhaps it makes sense to collect issues like that in malone? It is very
hard to follow arguments on mailing lists like this.



> So really it all boils down to the need for better documentation of
> procedure, better adherence to procedure, and possibly a need for
> better procedures.

I'd like to add announcments and announcements of changes to those
procedures to that list.


[1] yes, we all do mistakes, including developers, and usually, that is
    not really a problem if the effects of the mistake can be fixed.


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4