[arch-general] Bad attitude in flyspray again!

Heiko Baums lists at baums-on-web.de
Sat Mar 13 01:04:29 CET 2010


Am Fri, 12 Mar 2010 16:38:36 -0600
schrieb Aaron Griffin <aaronmgriffin at gmail.com>:

> Not at all. It is statistics. For a long time before the bug
> wranglers, I personally had to deal with 75% of the Project Manager
> requests from flyspray. These were all reopen requests, and many of
> them arguing with the actual choice a developer made. Something like:
> 
> Developer: Won't Implement. We want patch in features like this
> Reopen #1: But it's a good feature and upstream says it will be
> included soon! Me: Deny. He said he won't implement. Wait for upstream
> Reopen #2: This should totally be done. Without this patch Arch Linux
> sucks! Me: Deny

This is slightly different. In this case the developer and you have
given the reason for not implementing it, because you as downstream
don't want to add a feature by patching the package. This is common and
well known Arch policy. And this was not a bug report but a feature
request.

In my case - I still don't give the links. I don't want to blame a
certain developer and I actually don't want to keep on at this certain
issue. - a program has worked perfectly in the previous version. After
the latest update it didn't work anymore, it was almost completely
unusable, without changing the configuration. So it's most likely a
bug, and I of course have searched the forums, wiki and the web before
reporting the bug. The bug was closed as "works for me" without giving
a reason as far as I remember (those comments are not added to the
normal comments - should be changed).

Something similar already happened with another bug.

How do I understand it? What was my reaction?

I felt being ignored by the developer. And that's why I sent a
reopening request with a not quite friendly comment.

Then this reopening request was denied with another unfriendly comment.
How do I understand this? What's my reaction?

The developer doesn't take my bugs (problems) seriously, isn't willing
to look more precisely at the bug, doesn't care if a software is
unusable etc. So from my (the reporter's) point of view it's just
arrogant and ignorant.

In the meantime I know that this all have been misunderstandings. The
developer hasn't read my bug report precisely enough and thought that
it was again such a bug report where the user hasn't configured his
system correctly. I have missed, that my reopening request was denied by
another developer to whom the bug wasn't assigned. And I of course
know, that the developer in fact wasn't ignorant and arrogant. He
rather looked again into this bug and found the problem.

This all could have been avoided, if the bug hadn't been closed so
early without giving me the chance to respond with a normal comment
and if the reopening request would have been answered only by the
developer to whom it was assigned.

Such misunderstandings can always happen. And such reactions can be
prevented by first writing a comment that the developer can't reproduce
the bug and asking for more details, or asking if the reporter is sure
that he already searched the forums, or whatever. Then I wouldn't have
felt being ignored and would have explained in a much friendlier manner
why I'm sure that this is a bug and not a configuration issue.

I'm not talking about such conversations you mentioned above. But such
conversations couldn't completely be avoided.

Even if such bug reports can be annoying, a developer shouldn't first
think about such users who don't read the documentations, search the
forums, want other people to do the user's work, reports invalid bug
reports etc. when reading a bug report.

And - I repeat myself - think about how the reporter will understand it.

So better keep bugs reports open a bit longer than closing them too
early.

I'm telling this again, because I just want to explain the
user's/reporter's point of view, and that such cases could be at least
reduced. Just think about it. ;-)

Greetings,
Heiko


More information about the arch-general mailing list