mailing list subscription required to report problems

There is many people sending empty messages in that list or just saying "unsubscribe", and sometimes they are really angry. I bet most of them have been subscribed to report a timeout. That's bad for them and bad for the users reading the list.

They should be pointed to launchpad/malone/rosseta/whatever bug tracker, and not to a users mailing list.

We could change this to ask users to file a question at

https://answers.launchpad.net/launchpad-project/+addquestion

This allows the submitter to chose which Launchpad component the OOPS occurred in.

There are two caveats:

1) if the OOPS occurs during login/registration, users will not be able to file a question (this was the original thought behind the mailing list)
2) if the OOPS occurs filing a question

An even better solution is to detect that an OOPS has occurred and then present the user with the ability to file a Question with the OOPS ID.

Joey Stanford wrote:
> An even better solution is to detect that an OOPS has occurred and then
> present the user with the ability to file a Question with the OOPS ID.

That sounds like a better option indeed, and since it is possible to convert a
question into a bug AFAICS it would be easy for the Launchpad stuff to do so if
they need to.

If a problem is urgent enough that waiting for our QA staff to analyze the oopses would take too long, then asking them to report a bug or "ask a question" would be pointless, because we'd be similarly slow in responding to either of those (in addition to the catch-22 possibility Joey mentioned).

I suggest not directing people anywhere from this page (like Amazon and Google don't, for example), unless/until we actually have a support channel that Launchpad staff read 24/7 (whether that be #launchpad, launchpad-users@, or anything else). I think suggesting that people can get urgent help when they can't causes more harm than good.

Reported bug 196882 about making it easier for people to unsubscribe.

Matthew's comment is interesting in that we do record all OOPS events that display that page. And we look at those on a daily basis to identify problems.
We also raise the more user-affecting ones that need attention during our public weekly development meeting on #launchpad-meeting.

So, there is no need for a user to contact us unless it's urgent and they are blocked. This does help us assign an internal value of "user is blocked" such that we make the fixing of that OOPS a higher priority but beyond this I don't think, in general, there is much we can do to help the user until the OOPS is fixed. In some cases like timeouts, the user often tries again or with a slightly different approach which works.

The events I'm more worried about are the ones which present the unplanned-offline.html page because those do not result in an OOPS. Those I would definitely like to receive an email or question from a user which describes what they did, the URL, and when so we can go through the logs.

The unplanned-offline page says "If the problem persists, let us know in the #launchpad IRC channel on Freenode". It doesn't direct people to the mailing list, or to Answers, for the reasons already discussed.

I suppose another option we can do which is more inline with MPT's comments is to point users to a help wiki entry, which is currently on the front page but I can move it to it's own page, that lists the ways a user can get help with a problem.

The new text would be similar to this:

Sorry, something just went wrong in Launchpad. We’ve recorded what happened, and we’ll fix it as soon as possible. Apologies for the inconvenience.

Trying again in a couple of minutes might work. If it doesn’t, and this is blocking your work, feel free to <a href="wiki link>contact us</a>. Please include the error ID OOPS-655EB8 in your message.

That seems like it would just move the problem from one page to another. What would the wiki page say? :-)

I'll remove the reference to the mailing list from the error page. If we later introduce any support channel that is usually quicker than the oops report analysis process, we can mention that on the error page then.

Fixed in mainline, r6077.