updating pages

[Micah Cowan]

On Thu, 2006-09-28 at 11:01 +0100, Caroline Ford wrote:
> I think the Responses page needs much more work to be usable. I note
> that no-one seems to be using those stock responses - and this is a good
> thing as I know I hate it when I get a stock response to technical
> support emails ;)

Stock responses to frequently-asked and sometimes misinformed questions
are not inappropriate, though. What I /have/ seen, though, is that a lot
of people write responses with a slightly more personal touch, that seem
to be /based/ upon the Responses.

I /do/ frequently use the Response for "aged Needs Info" bugs. In this
case, nothing much would really be saved by tailoring a response anyway,
as at this point it doesn't seem likely that the original reporter will
actually be reading it (since they hadn't read it for at least a couple
months after the status changed to "Needs Info").

I /would/ like to be able to use the other "bug is not described well"
Response, but I agree that linking to a massive (though well-written)
essay on bug reporting isn't likely to be productive. Perhaps we could
summarize Mr Tatham's points on a page of our own? The link to
http://wiki.ubuntu.com/DebuggingProcedures is also much too vague:
better to hone it down to the specific set of DebuggingProcedures that
applies to this case. Giving them a link to a page that includes how to
debug GNOME or Firefox isn't helpful if their problem is a CLI app that
dumps core.

Also, it doesn't seem like it should generally be a bug reporter's
responsibility to debug their problem: a bug reporter's responsibility
is to describe the bug in a highly reproducible manner (which, of
course, is unfortunately not always possible). Anything asked above and
beyond that should be as gentle a request as possible. The "average joe"
user is not going to be happy to be asked to download source packages,
build them with debugging symbols, run it under gdb, and provide a stack
trace--as extremely useful as those can often be. Requesting these is
often necessary when the developers/debuggers can't reproduce the
problems themselves, but folks should realize what they're asking of the
reporter, and if a backtrace is not obtained from the reporter, the
Reject comment should be as courteous as possible ("I'm sorry, but I am
unable to reproduce the bug on my own, and would need more low-level
information regarding what you're experiencing in order to proceed").

> That page implies that problems with translations are not bugs when they
> are. The answer given - "fix it yourself!" is not helpful to bug
> reporters or to translators who would like to know when there are
> problems..

That's incorrect. What it actually says is that Malone is the
wrong /forum/ for translation bugs, which belong on Rosetta. And I see
nothing along the lines of "fix it yourself".

That being said, Rosetta is /not/ the appropriate forum for a lot of
these translation issues. Many of them ought to be handled by upstream,
in which case Malone may be more appropriate (I don't know, I'm fairly
new), or may be handled in a different way from what Rosetta is capable
of doing. In any case, it may be best to let the bugsquad determine when
a bug would be more appropriate to Rosetta, and forward the bug
themselves, rather than tell the user "you goofed, wrong forum".

-Micah


----------------------------------
Barracuda Networks makes the best spam firewalls and web filters. www.barracudanetworks.com