Page MenuHomePhabricator

Developers not replying to bugs using the bug form
Closed, InvalidPublic


Author: qleah

It is not helpful to force bug reports to become user monologues.

Version: unspecified
Severity: major


TitleReferenceAuthorSource BranchDest Branch
[hack] Patch irc handler to offset BNC event replytoolforge-repos/bridgebot-matterbridge!1bd808work/bd808/T305487main
Customize query in GitLab

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 8:07 PM
bzimport set Reference to bz1054.
bzimport added a subscriber: Unknown Object (MLST).

rowan.collins wrote:

I can see that not getting any replies to your bug must be frustrating, but
remember that the software is entirely developed and maintained by a relatively
small group of volunteers, many of whom are also responsible for the day-to-day
operation of the Wikimedia servers, as well as having possibly full time jobs in
"the real world". In some ways, it is amazing that the software works *at all*;
in fact a lot of bugs *do* get fixed, but there are always more being found -
not to mention people clamouring for completely new features, which create work
in themselves, and then further bugs to track down and fix.

In the case of bug 372, I suspect the fact of the matter is that no one has yet
worked out what might be causing it - it being a rather awkward bug to track
down and test. This doesn't mean that nobody *cares*, but when given a choice
between a major bug with a known diagnosis and a relatively minor (though
annoying) malfunction which appears only inconsistently, I guess the developers
are going for something which seems achievable. (I was reminded of the continued
existence of bug 275 earlier - like bug 372, it is hard to test and diagnose,
and thus no-one has committed enough time to tackle it.)

I guess the only comment that anyone could have made would be "thanks for trying
to isolate this bug; I'm not sure what it is, but I'll look if I get round to
it" - but maybe no-one was confident enough even to make that promise. So yes,
thank you to everyone who has reported bugs, but please be aware that the
developers *are* busy, and are not likely to spend time predicting which bugs
may be looked into in the future; if nobody says "this bug is going to be
ignored", assume it will be looked into eventually.

qleah wrote:

The issue is not that there isn't time for every bug; it's the communication
outside of Mediazilla that may be a problem. In bug 372, Omegatron makes a
series of comments which indicate some sort of dialogue, but the other side of
the discussion is missing.

rowan.collins wrote:

OK, maybe I misunderstood what you meant (I also assumed this bug was opened by
Omegatron, so apologies to both of you); but I'm still not sure what you want
doing. I presume the monologue appearance of bug 372 is because Omegatron
discussed it on IRC, or perhaps the mailing list; are you saying that every time
someone discusses a bug, they are responsible for entering their half of the
discussion into the tracker? Or should discussions outside the tracker be
completely banned?

Surely the onus is on Omegatron to make each comment added not dependent on
context which isn't there, as comments such as "I was told to test with a
different account" do. In other words, it doesn't matter that one person added
all the information to "MediaZilla", as long as no information is actually
"lost". I don't see that the developers are doing anything wrong here.

[I'm removing the "blocking" status as well, since this isn't really what that
relationship means] wrote:

That's as it should be. Bug reports are not a good place for well-rounded
informal discussion between developers about the ways to approach a problem.

In the case you reference, real time bug reporting and discussion happens in the
IRC channel where the developers also discuss and deal with the real time issues
with the Wikimedia systems. Those, and attempts to reproduce them, often depend
on the exact state of the servers at the time the issue is happening. There's a
very high chance that bug 372 is related to a lagging database slave. Reporting
such things here is of little use because the problem will be fixed before
anyone reads the report.