| Thread Previous • Date Previous • Date Next • Thread Next |
One other point to keep in mind: If a user has an Ubuntu One account, it doesn't mean he has enabled it for use with Launchpad.
I think you buried the lede here. Can someone fill me in with more details? What has to be done to enable a Ubuntu One account on Launchpad. Can we do this automatically, or does it require some user interaction? If we can't make it work automatically, then my approach won't work. (I signed up for Launchpad in the pre-Ubuntu-One era, so I don't know how it works these days.)
I think it would be easier for both parties if a review which a user submits as a bug report is sent to the developer via e-mail. We know his Ubuntu One id, so we can also find out his e-mail address.
On the one hand, this makes me a bit uncomfortable. People signed up to Ubuntu One expecting their email to be used for "official" purposes. Giving it out to random developers feels like a betrayal. But Launchpad spoofs From: lines with users' actual email addresses, so my approach really has the same effect. Launchpad feels less invasive to me, but but I guess it isn't.
This way, the developer can then create a bug report for the particular issue on his favourite bug tracker and, most important, it is easy for both him and the user who reported the bug to reply to each other.
I'm not sure I really see the advantage of transferring a bug from email to Github and manually keeping the reporter up-to-date over transferring a bug from Launchpad to Github and manually keeping the Launchpad bug up-to-date.
One advantage of a bug tracker over email is that it leaves a public record of the bug reports. The submitter can be sure that the report got through, can see if it's being worked on, and can check how long it takes for other bugs to be attacked. Reports that disappear into someone's inbox may leave the reporter in the dark.
Additionally, I believe that this would be much easier to implement than any solution proposed above.
Who sends the email to the developer? If it's the user's phone directly, then the app scope needs a SMTP client built-in, and someone needs to be running a SMTP server for the phone to talk to. And because running open SMTP relays is a bad idea, we need some authentication scheme. (Or do we open the user's mail client, paste in the report, and ask them to hit send? Can we do that with all mail clients?) More likely, I'd think, would be to have a server that the scope talks to over HTTP which can send out the emails. But someone has to design that HTTP interface and then build and run that server.
All that said, I could see this being an option for the developer to choose, once someone figures out how the backend would work.
Robert
| Thread Previous • Date Previous • Date Next • Thread Next |
