Wiktionary talk:Votes/2013-03/Disallow mobile edits by unregistered users

Latest comment: 11 years ago by Chuck Entz in topic Edits or creations?

Lies, damn lies, and ... edit

“ratio of bad to good seems to be well over 100:1. To show this more explicitly: in the last 30 days, only two mobile edits with any content that is worth keeping have been made”

This shows it less explicitly, unless you say two out of how many. The provided link shows zero results for me, so I can’t look up the answer to this. Michael Z. 2013-03-15 21:22 z

I don't know of a way to show which mobile edits have been deleted. But I probably delete at least a few every day, and Semper deletes a whole lot more I presume, so I think that easily surpasses 3.3 deleted edits per day. —CodeCat 22:25, 15 March 2013 (UTC)Reply
I believe I have yet to see any mobile edit that wasn't rubbish, and I see a lot of Recent Changes. Equinox 22:27, 15 March 2013 (UTC)Reply
I did actually see a reasonable one a couple of days ago. I couldn't believe my eyes. (Sorry, I didn't make a note of it) SemperBlotto (talk) 22:29, 15 March 2013 (UTC)Reply
Incidentally, the other day (stuck on a train) I tried using Wiktionary from a mobile device for the first time. The mobile view (m subdomain) was okay for looking things up, but didn't seem to offer editing features at all. The regular view wasn't really usable on a phone (and attempts to view my watchlist timed out!). Equinox 22:35, 15 March 2013 (UTC)Reply
I have never seen a good mobile edit that wasn't explicitly pointed out to me, and I try to do my share of patrolling. —Μετάknowledgediscuss/deeds 23:25, 15 March 2013 (UTC)Reply
I saw a set of good mobile edits yesterday or the day before, but they were made by a registered user. - -sche (discuss) 01:01, 16 March 2013 (UTC)Reply

Lack of good edits edit

Okay, I tried the mobile view for a bit and I see absolutely no trace of any editing interface. So perhaps there is an explanation for the lack of good edits, which disallowing editing won’t improve. Michael Z. 2013-03-16 00:27 z

Your logic makes no sense. How would disallowing editing not improve the quality of almost wholly vandalistic edits? —Μετάknowledgediscuss/deeds 01:14, 16 March 2013 (UTC)Reply
The symptom is a lack or absence of good edits. The cause is no way to edit. The fix is to let people edit; enable the interface, make it visible. Disabling something will not help this serious problem.
An associated symptom is some amount of vandalism. Since there is no apparent mobile interface for editing, we don’t even know how this happens, but we are considering turning off some invisible interface in response. This is random and arbitrary, and I can’t support it until there’s evidence that we have a clue what’s going on. Cutting off access without understanding the problem is against logic, and our Wiki principle of openness. Michael Z. 2013-03-16 14:30 z
Re: "The cause is no way to edit." Do you see why I can't take your arguments seriously? They clearly make no sense, when we know that people are editing thus and that your statement is false. If you have a way of understanding the problem, that would be great. However, it appears that you know no better than the rest of us, but would rather have other people delete this deluge of vandalistic edits, instead of preventing the vandalism in the first place. —Μετάknowledgediscuss/deeds 16:08, 16 March 2013 (UTC)Reply
“we know that people are editing thus” – We do? How do we know this?
  • The link given on the vote page shows zero mobile edits in the last 365 days. Where do I find these good and bad mobile edits?
  • Can an unregistered mobile edit be made? The “mobile view” link gives no edit link on any entry if I am not logged in. I have tried this in three different mobile browsers and three desktop browsers. Please give me the steps to make an unregistered mobile edit, because it appears to be impossible.
Dude, just show one piece of basic evidence before calling a vote. Michael Z. 2013-03-16 17:04 z

Okay, I see this, but I’m not sure I understand it:

Editing in this view can be done by accessing articles through the index.php file with edit as action. For example to edit this page in mobile view visit http://en.m.wiktionary.org/w/index.php?title=Wiktionary:Votes/2013-03/Disallow_mobile_edits_by_unregistered_users&action=edit.

Does “accessing articles through the index.php file with edit as action” mean hacking the URL to get to an edit page? Is the hypothesis that vandals are laboriously cutting and pasting URL fragments with their Blackberry keyboards to do all of this vandalism? What’s to prevent these smart, hard-working vandals from pasting en.wiktionary.org instead of en.m.wiktionary.org? I see that the mobile edit page is identical to the non-mobile one anyway.

And if hacking the URL is the only way to make a non-registered mobile edit, then it still looks like the problem is that mobile is too closed, not too open. Michael Z. 2013-03-16 17:14 z

Disabling (by disallowing, or any other means) mobile editing cannot improve mobile editing because then we will have no mobile editing for us to improve it. It is as if we say that we improved the child's ability/success in walking by not letting him/her to walk. Having overall better quality of (all) edits by disabling anon (or all) mobile edits is a different thing tho.
The edit in which I explained how to make a mobile edit is also one "mobile edit". Here's another (this one an anon edit) that was deemed as mobile: diff. Both were made with a desktop computer. As for whether hacking the URL is the only way to make mobile edits I dunno. --biblbroksдискашн 17:28, 16 March 2013 (UTC)Reply
In fact, this does not “edit this page in mobile view.” The user is presented the identical, non-mobile, edit page whether the editing URL is constructed on en.wiktionary.org or en.m.wiktionary.org. Disabling mobile editing just means that a vandal has to leave out “m.” from their URL.24.77.227.250
Perhaps we need a vote to enable mobile edits by unregistered users. That might improve the ratio. Michael Z. 2013-03-16 18:10 z
Michael, you seem to be confusing me with CodeCat, the vote's creator. And, yeah, we know mobile editing exists because it happens. I really don't get what you're saying: either there's a misunderstanding or you're denying reality. —Μετάknowledgediscuss/deeds 19:18, 16 March 2013 (UTC)Reply
The reality is that a URL with the correct post args returns an editing page. The edit gets marked as “mobile edit” if the URL has an .m. in it, and otherwise doesn’t. There is no other difference in the process. (There is nothing particularly mobile about them.)
I don’t know why there are edits being made this way, but whether this is done by cutting and pasting the URL, or by some app or bookmarklet, if we “disable mobile editing,” all these vandals will do is drop the “.m.” or update their app, and continue vandalizing with no “mobile edit” flag. If there is some way to look at server logs, perhaps we can figure out where these edits come from.
But without understanding the problem, this vote is a knee-jerk reaction to the tag “mobile edit,” and not to the problem’s real source. I doubt that this proposal will reduce the vandalism for long.
It remains that legitimate unregistered mobile editing, without some exceptional workaround like URL hacking, is already effectively blocked, because legitimate readers see no edit links. Is there a reason for this? Of course “almost all edits with the tag "Mobile edit" have been bad,” because making legitimate edits thus is impossible. Why don’t we enable mobile editing so we can have some legitimate edits by readers who rely on the mobile view? Michael Z. 2013-03-16 20:12 z
You're making statements about how the vandals would react to not being able to edit mobilely, and predictions about how it wouldn't make a difference — but you have no better ideas! It's easy to call for enabling legitimate mobile edits, but a lot harder to figure out how to do that. If you really think this vote won't make a difference, then why would you oppose it? And isn't opposing the vote without suggesting an alternative to te issue at hand a classic "knee-jerk reaction" in and of itself? —Μετάknowledgediscuss/deeds 20:40, 16 March 2013 (UTC)Reply
Knee-jerk is doing something without evidence that it will help. Asking for information and trying to figure out what the problem is, before firing off a potentially fruitless a vote, is not knee-jerk.
I suggested alternatives. Enable mobile editing to get the lamented 100:1 edit ratio down while serving this project’s openness mandate. Look at the server logs to divine the source of these weird edits to formulate an appropriate response. No, I do not know how to enable mobile editing, but I guessed that whoever was planning to “disallow mobile edits” would have some idea of where to ask. I also suggested getting more information, or any information, about these mobile edits to so we can learn more about this problem, but no one on this page would even do the courtesy of providing a working link to the list, so I had to troubleshoot that myself.
How many bad mobile edits are there? How does their number compare to the number of bad non-mobile edits? Michael Z. 2013-03-16 23:17 z
How would encouraging more edits eliminate bad edits? You are going by ratios, but the ratios aren't really the end of the problem, they're just a justification for the action we want to take. The real problem is the large amount, in absolute terms, of bad edits coming from mobile devices. We are saying they should be blocked, but consider what would happen if we ever tried to block non-mobile IPs from editing. We'd say that we'd be blocking too many good edits. That's where the ratio comes in: we say that since there are proportionally much more bad edits than good ones, that is a good reason for the block. Encouraging more edits will muddle down that justification, but it will not solve the underlying reason for that justification. —CodeCat 23:24, 16 March 2013 (UTC)Reply
For the record, I ran a check a few months ago of a large number of anonymous (non-mobile) contributions and found that fully 20% of them were vandalistic/questionable, required fixing, or were petty (like pointlessly rewording example sentences). If any user had a record like that, we'd indef-block them. But I'm not advocating we block all anons, just saying that they aren't going to improve the mobile good-to-bad ratio as much as one might hope.Μετάknowledgediscuss/deeds 23:33, 16 March 2013 (UTC)Reply
Well, it looks like we might already be blocking a lot of good mobile edits. What if allowing unregistered mobile editing raised the mobile ratio to 20%? If the number of bad mobile edits is so huge, doesn’t that indicate that we are potentially losing that 80% of a huge number of good mobile edits?
Okay, if we have no intention of restoring mobile editing, then I guess we may as well really block it. But like I said, if the mobile-tagged vandals are already using exceptional means, then we are likely just driving them from en.m. to en.
But this whole episode does make me want to know why mobile editing is disabled in the first place. Mobile is exploding, and for many people it is the main or only access. This situation seems contrary to openness. Michael Z. 2013-03-17 00:23 z
We are only voting on blocking unregistered mobile users. Anons make up most vandalism by far; even Wikipedia (as "open" as we are) restricts what anons can do, in e.g. creating new entries. Equinox 19:57, 21 March 2013 (UTC)Reply
I totally get that. As I mentioned above, unregistered mobile users are provided with no edit link, so only hackers can can make so-called “mobile” edits. So we have no evidence that mobile anons vandalize any more than non-mobile anons. Michael Z. 2013-03-21 20:06 z
Huh... if the statement above is true (that flagged "mobile edits" are only those created through the m. subdomain, which does not offer an editing interface) then my feeling is that we should temporarily pull this vote and identify how it is happening; for example, is there some Scrabble-clone word game that links users to create pages (just a guess)? Can we study these edits, e.g. HTTP referrer, to find out? Equinox 20:10, 21 March 2013 (UTC)Reply
Good ideas. Michael Z. 2013-03-21 20:13 z

Sunset clause edit

Someone pointed out in the BP or GP that the percentage of people who use their mobiles to interact with the web, including with Wiktionary, will likely only increase. Right now, the ratio of bad to good mobile edits by IPs is imbalanced, but 1–2 years from now, it might be comparable to the ratio of bad to good non-mobile edits by IPs — and we won't know unless we stop blocking IPs from mobile editing for a while. I'd suggest writing a sunset clause that disables mobile edits by unregistered users for some specified period of time, like one year, but not indefinitely. - -sche (discuss) 05:22, 16 March 2013 (UTC)Reply

How about after a year, there can be a testing period of one month, and at the end of that month mobile edits by anons can be re-allowed if the community judges that the edits made were good enough? —Μετάknowledgediscuss/deeds 05:30, 16 March 2013 (UTC)Reply

Edits or creations? edit

Are all of the bad anonymous mobile edits new-page creations, or edits of existing pages?

The former can be done by following a link from the 404 page. The latter only by hacking a URL, which, although easy, is much less easy than the former. Michael Z. 2013-03-21 20:12 z

[Here] is the page you get from a failed search. No explanation beyond saying the query produced no results, and the search box has disappeared. Aside from the icon in the upper-left-hand corner and wikilinking on "entry templates", new-entry-creation buttons are the only usable links on the screen. This is an incredibly lame excuse for a user interface. I can see how people could get frustrated and enter garbage. The [404 page] is much better.
By the way: it is possible to make edits (as opposed to new pages) using the mobile interface, but you have to register someplace to have it enabled. For those who don't know about that, the mobile interface offers only the ability to create new entries (practically shoving it in users' faces), but no way to edit. I believe we could stop the garbage edits right now by adding code to the new-entry-creation apps that disallows use through the mobile interface, but that would just make the experience even worse for mobile users.
As for whether the problem is real: look through the deletion log, and I think you'll find that most of the recent deletions with the summary "(Incomprehensible, meaningless or empty: please use the Sandbox)" are mobile edits. Chuck Entz (talk) 06:40, 30 March 2013 (UTC)Reply
Return to the project page "Votes/2013-03/Disallow mobile edits by unregistered users".