Let people ask questions without previously creating an account

Bug #158181 reported by Martin Pool
4
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
Low
Unassigned

Bug Description

We're interested in using the Answer tracker as an initial contact point for Bazaar users. (At the moment they are encouraged to post to the list or ask on irc instead.)

I think at the moment they are required to create an account before asking a question. I wonder if that will put some people off asking.

There is some potential for spam or other abuse if people can post to Launchpad without verifying their identity, or alternatively if they can cause Launchpad to send unlimited amounts of mail to an email address.

Here are some options:

0- let people post entirely anonymous questions -- not so good as then they won't get notified when it's answered
1- let people specify their name and address when they post the question, and implicitly create an unverified account.
1a- then, go ahead and show the question. If it's spam, allow project owners to delete it. If it's not spam, then send the answer back to the original user. This is most similar to how email works. It is possible they could have entered someone else's email address, but then it seems unlikely they'd add a plausible question.
1b- put the question on hold until the person responds to an email confirming their address
???

(Bug 50653 is the equivalent for bug reports.)

Revision history for this message
David Allouche (ddaa) wrote :

I like the idea of doing something along 1b.

The "traditional" way for new users to ask a question (comment on a bug, etc.) is to:
 * Find out that they must be logged in
 * Go the account creation form
 * Provide an email address
 * Wait for the confirmation email
 * Load the confirmation page.
 * Go back to what they intended to do in the first place.

Painful.

It would be nice if we could cut this down to something like:

 * Confirm that they do not have an account yet
 * Provide an email address
 * Do what they intended to do in the first place.
 * Wait for the confirmation email.
 * Load the confirmation page.

The question would be held back until the email address is confirmed.

Not only this is shorter, but it also provides much earlier reward: the intended task is completed more quickly, and it breaks the user's flow a lot less. The disruptive "wait for email and load confirmation page" does not need to block completion of the task.

This would probably have far reaching implication on the account model of Launchpad, but I think it would be worth the trouble. I hate all those sites that force me to go through the account registration drill just to report a bug or post a simple message.

description: updated
Revision history for this message
James Henstridge (jamesh) wrote :

If the "Unauthorized" view could preserve the contents of a form post before directing the user to login, it could then repost the form after logging in.

If we combine this with the workflow implemented by login.launchpad.net, we'd be able to have an "ask question" form usable by anonymous users that posted the question once the user had validated their email address.

Curtis Hovey (sinzui)
Changed in launchpad-foundations:
status: New → Triaged
importance: Undecided → Low
Revision history for this message
Curtis Hovey (sinzui) wrote :

This will be fixed in the Answer tracker example when Launchpad is an RP for any OpenID. IT might even be considered fix now given that no one can register with Launchpad anymore; users use the Ubuntu Single Signon Service.

Revision history for this message
Robert Collins (lifeless) wrote :

I've marked this as a dupe on the one for bugs - the basic scenario seems common to many objects, and while we may need separate bugs to land various splinters, I don't think having itemised bugs is useful at this point - there is one conceptual issue.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.