Wikimedia Bugzilla is closed!

WONTFIX b/c we don't want mobile-only features that we won't have on the main site.

(In reply to comment #1)
> WONTFIX b/c we don't want mobile-only features that we won't have on the main
> site.

This isn't a valid WONTFIX rationale. It doesn't make any sense on multiple levels. Re-opening.

Seems the same rationale for closing Bug #227 should work here.

*** This bug has been marked as a duplicate of bug 227 ***

Re-opening this (with a bit of consensus, for a change!).

There's no real principle that mobile features need to match non-mobile features in MediaWiki development. And the reality is that mobile browsers' feature sets don't match of those of their non-mobile counterparts. That's an important consideration.

The justification for WONTFIXing bug 227 doesn't apply here (and in my opinion, is a bit dubious for bug 227 as well).

To avoid the problem of spamming, there should be some control be put in place so that a user cannot edit or create and article and then send it to someone.

We should also allow people to opt-out of getting these emails.  If your Aunt Sue starts sending you every article she finds in Wikipedia, you may quickly get annoyed.  So we should maintain a list of people who've gotten the email and then said they don't want any more.

Finally (and this is really more of an Ops issue), we should hook into Feedback Loops (See AOLs for example: http://postmaster.aol.com/Postmaster.FeedbackLoop.php but other large providers like Yahoo, Hotmail and Comcast use them as well) so that when someone marks the email as spam their provider can notify us that they don't want to get the emails any more.

We don't need to reinvent the email cycle here, we could just have a button that loads the local client with email then its up the user to send it. That way we don't really have spam issues to deal with being sent from our end.

I don't really see how X sending how many emails to Y is really a issue for us to consider unless we decide to go down the route to setting up our own email gateway/system to send these.

(In reply to comment #7)
> We don't need to reinvent the email cycle here, we could just have a button
> that loads the local client with email then its up the user to send it. That
> way we don't really have spam issues to deal with being sent from our end.
> 
> I don't really see how X sending how many emails to Y is really a issue for us
> to consider unless we decide to go down the route to setting up our own email
> gateway/system to send these.

+1

I was thinking the same thing where we just give an easy mailto: link that prefills everything (like subject, body, etc.) but uses the the person's own e-mail client.

I think Mark was imagining a system where we managed the sending ourselves through our server, but I don't think that's needed. An easy button that fills out the e-mail for you would be good enough.

(In reply to comment #8)
> I think Mark was imagining a system where we managed the sending ourselves
> through our server, but I don't think that's needed. An easy button that fills
> out the e-mail for you would be good enough.

Agreed.  And it would avoid the having to deal with the whole mess I talked about in comment #6.

I'm not sure about this. As an Android user I'm perfectly content with holding down my finger on the address bar, clicking share and then making use of android intents to either share the link by e-mail or twitter or any other app I have installed.

This aside I realise that not all phones have a similar mechanism.

If we did want to pursue this I'd encourage encompassing more than email (e.g. twitter, facebook etc) and would recommend keeping a close eye on the WebIntents [1] which the Mozilla Lab and Chrome teams are working together on in particular the webintents share intent [2]. This way "we don't need to reinvent the email cycle"

[1] http://www.w3.org/wiki/WebIntents
[2] http://webintents.org/share

Not much interest in it, and not in mobile team's plans.