Last modified: 2014-11-01 16:22:37 UTC
This bug tracks obstacles to enabling anonymous editing via [[mw:Extension:MobileFrontend]]. Copied from bug 52442 comment 14: It's not quite so simple as a permissions change. Longer explanation below, but the tl;dr is that there's a lot of design and development work that needs to be done before we can just flip the switch. First and most importantly: editing a wiki "anonymously" means leaving a permanent, searchable trace of your IP address in connection with your edits; this is actually a non-trivial and in many cases highly sensitive piece of metadata. As a bare minimum requirement to ensure the safety and privacy of our users, we would need to build an educational system into the mobile editor that alerted users of their logged out status, made them understand the implications of this (e.g. if they're in a country where their edits could put them in danger, make sure they're aware that they're basically geo-targeting themselves by editing without an account), and let them login/signup before saving their edit. On desktop, we do this with a series of templates and mediawiki messages, but mobile has a very different, radically constrained UI, and solving this problem in a way that doesn't hinder the ability to actually make an edit and gets people to read and understand the disclaimer isn't easy or straightforward. In addition to this bare minimum requirement, there are a host of other social, UX-related, and technical challenges to opening up an anonymous editing funnel on mobile: 1. Mobile devices are quite different from desktop in that it's much easier to fat-finger and accidentally do something you didn't intend to do. A highly motivated IP editor on desktop who accidentally (or as a test) blanks a page might discover the page history and the undo button – that's much harder to do on mobile, where the history view is currently so tiny and cluttered that undo is barely enough of a target to tap on, let alone see. Until we have a nice, clean, mobile-friendly history view and revert actions (something the team is going to be working on sometime this year), you'll get a lot of first-time users messing up or messing around with no way to clean up the mess. 2. On desktop, it's not as huge a break from your workflow to leave what you're editing, log in, and keep editing; on mobile, where everything is so focused and zoomed-in, that feels like a huge break. Unless we made it obvious *why* an account is beneficial, it's doubtful most anon editors would go through the trouble of creating an account to fix a typo -- but that means they're missing out on important features like a watchlist and a notification system (see point 4). 3. The abuse filter is already a huge problem for mobile, since on many wikis it's configured to show a CAPTCHA for certain conditions (non-autoconfirmed users adding links, adding/removing large chunks of text, or, on projects like Portuguese Wikipedia, making edits of any kind), which in turn causes the mobile editor to throw an error. Right now the error rate is hovering at an alarming 48% across all projects; making editing available to anons would guarantee that the error rate would skyrocket. Until we build a replacement for the abusefilter CAPTCHA (again, a tricky engineering problem on mobile), we'd knowingly be showing anons a broken and unusable edit button most of the time. 4. A lot of the features we're building on desktop to keep people in the loop about what's happening to their edits (like email and Echo notifications) are for logged in users only, and those become extra critical communication mechanisms on mobile, where it's harder (and, again, a bigger break from your workflow) to find and check your talk page. I'm not sure how we'd build a notification system for mobile IP editors without unnecessarily spamming a huge swath of mobile readers with notifications about user warnings that don't involve them. This is already a problem on desktop, but it becomes exponentially more problematic with the wildly fluctuating IPs of most mobile devices. For all these reasons and more, letting IPs edit on mobile is (for now) not a great idea, so I'm closing this as WONTFIX -- however, the mobile dev team will be working on many of the associated issues here, and it's certainly not outside the realm of possibility for anon mobile editing to happen sometime in the future. For now, we can fulfill our ideological obligations to a free and open wiki by showing the edit button and a login/signup CTA everywhere and making it as quick and easy as possible to login or sign up. To reiterate my first point: "anonymous" editing is actually less anonymous than signing up for a free user account that requires no personal information, not even an email; to claim otherwise is simply demagoguery.
Comment 0 needs a proper reply and dependent bugs, but I'm tired after bug 52442, bug 53069 (this bug), bug 53073, and bug 53076. I'll do it later, maybe.
(In reply to comment #0) > First and most importantly: editing a wiki "anonymously" means leaving a > permanent, searchable trace of your IP address in connection with your edits; > this is actually a non-trivial and in many cases highly sensitive piece of > metadata. As a bare minimum requirement to ensure the safety and privacy of > our users, we would need to build an educational system into the mobile editor > that alerted users of their logged out status, made them understand the > implications of this (e.g. if they're in a country where their edits could put > them in danger, make sure they're aware that they're basically geo-targeting > themselves by editing without an account), and let them login/signup before > saving their edit. This is a red herring, bordering on fear-mongering. This statement tries to give the impression that anonymous editing is a new, unheard of concept. This is silly. Anonymous editing has been fully supported in MediaWiki since the dawn of time. The issues regarding anonymity, actual user privacy, risks associated with IP editing, etc. are relevant to Wikimedia, but they have nothing to do with this bug. Philosophical opposition to anonymous editing is most certainly not an obstacle (or blocker) to re-enabling anonymous editing via MobileFrontend. > 1. Mobile devices are quite different from desktop in that it's much easier > to fat-finger and accidentally do something you didn't intend to do. A highly > motivated IP editor on desktop who accidentally (or as a test) blanks a page > might discover the page history and the undo button – that's much harder to > do on mobile, where the history view is currently so tiny and cluttered that > undo is barely enough of a target to tap on, let alone see. The mobile team has been working for years now on re-inventing the user interface with these considerations in mind. If there are specific issues that relate to anonymous mobile editing, please file separate bugs that block this bug. As it is, you seem to be arguing that mobile devices are simply cumbersome to edit from. I personally agree, but this isn't a blocker to re-enabling anonymous editing. > 2. On desktop, it's not as huge a break from your workflow to leave what > you're editing, log in, and keep editing; on mobile, where everything is so > focused and zoomed-in, that feels like a huge break. Ummm, you've intentionally disabled anonymous editing. _That_ is what is disrupting user workflow. If you re-enable anonymous editing, you'll solve this issue altogether. You're currently arguing "well we put up this hurdle, but now there's a hurdle." It's borderline tautological. > 3. The abuse filter is already a huge problem for mobile, since on many wikis > it's configured to show a CAPTCHA for certain conditions (non-autoconfirmed > users adding links, adding/removing large chunks of text, or, on projects > like Portuguese Wikipedia, making edits of any kind), which in turn causes the > mobile editor to throw an error. Right now the error rate is hovering at an > alarming 48% across all projects; making editing available to anons would > guarantee that the error rate would skyrocket. I'm not sure what this is about, but it sounds worrying if true. If 48% of mobile edits are erroring, that would be a very high priority bug to get resolved. Do you have a link to a bug report tracking this issue? Presumably this bug report would also include links to the data you're basing these claims upon. > 4. A lot of the features we're building on desktop to keep people in the loop > about what's happening to their edits (like email and Echo notifications) are > for logged in users only, and those become extra critical communication > mechanisms on mobile, where it's harder (and, again, a bigger break from your > workflow) to find and check your talk page. There's a big orange bar. MediaWiki has made intentional design decisions to ensure that this big orange bar works for both anons and logged-in users. You're erecting obstacles and other "I personally don't like anonymous editing" arguments in the hope that one or some of them will stick. These problems are _hardly_ unique to mobile editing or anonymous editing. Mentioning in them in this context is misleading and unhelpful. > This is already a problem on desktop, but it becomes exponentially more > problematic with the wildly fluctuating IPs of most mobile devices. Similar to the opening point, this can and should be discussed separately. It may make sense to holistically re-evaluate our use of IP addresses for anonymous users, as Brion, Greg Maxwell, and many others have noted. But this isn't relevant to this bug. If we one day change from IP addresses to something else, it has no bearing on anonymous editing being intentionally disabled on mobile. > For all these reasons and more, letting IPs edit on mobile is (for now) not a > great idea [...] This bug is a tracking bug for obstacles to enabling anonymous editing via MobileFrontend. This bug report needs associated bug reports describing the actual issues blocking re-enabling anonymous editing on mobile. Reading through your lengthy comment, while you're unquestionably thorough, I don't see many blockers. Perhaps the CAPTCHA issue, but I'd need more info to know for sure. The philosophical issues about anonymous editing are moot in the context of mobile editing. Anonymous editing is a [[m:founding principle]] of Wikimedia wikis that can't simply be brushed aside by a small development team.
(In reply to comment #0) > This bug tracks obstacles to enabling anonymous editing via > [[mw:Extension:MobileFrontend]]. Thanks. I've added blockers for a few technical issues I found when testing. I'm not going to attempt to respond to everything, just stuff I'm concerned about. > It's not quite so simple as a permissions change. Longer explanation below, > but > the tl;dr is that there's a lot of design and development work that needs to > be > done before we can just flip the switch. > > First and most importantly: editing a wiki "anonymously" means leaving a > permanent, searchable trace of your IP address in connection with your edits; > this is actually a non-trivial and in many cases highly sensitive piece of > metadata. As a bare minimum requirement to ensure the safety and privacy of > our > users, we would need to build an educational system into the mobile editor > that > alerted users of their logged out status, made them understand the > implications > of this (e.g. if they're in a country where their edits could put them in > danger, make sure they're aware that they're basically geo-targeting > themselves > by editing without an account), and let them login/signup before saving their > edit. On desktop, we do this with a series of templates and mediawiki > messages, > but mobile has a very different, radically constrained UI, and solving this > problem in a way that doesn't hinder the ability to actually make an edit and > gets people to read and understand the disclaimer isn't easy or > straightforward. Basically there needs to be some mobile equivalent of the anoneditwarning ([[MediaWiki:Anoneditwarning]]). > In addition to this bare minimum requirement, there are a > host > of other social, UX-related, and technical challenges to opening up an > anonymous editing funnel on mobile: > > 1. Mobile devices are quite different from desktop in that it's much easier > to > fat-finger and accidentally do something you didn't intend to do. A highly > motivated IP editor on desktop who accidentally (or as a test) blanks a page > might discover the page history and the undo button – that's much harder to > do > on mobile, where the history view is currently so tiny and cluttered that > undo > is barely enough of a target to tap on, let alone see. Until we have a nice, > clean, mobile-friendly history view and revert actions (something the team is > going to be working on sometime this year), you'll get a lot of first-time > users messing up or messing around with no way to clean up the mess. Is this for users to revert themselves by finding the page history and hitting undo? I'd imagine that if I'm using huggle a revert would be near instantaneous, but if I had to use my fat-fingers on a mobile device, it would take at least a minute. Is there any evidence that logged in users have this issue? Users are already forced to view a preview and then hit save, so there already is an extra confirmation step that desktop doesn't have. > > 2. On desktop, it's not as huge a break from your workflow to leave what > you're > editing, log in, and keep editing; on mobile, where everything is so focused > and zoomed-in, that feels like a huge break. Unless we made it obvious *why* > an > account is beneficial, it's doubtful most anon editors would go through the > trouble of creating an account to fix a typo -- but that means they're > missing > out on important features like a watchlist and a notification system (see > point > 4). So we're rejecting an edit from a potential contributor because they don't know that they can experience more features? That sounds backwards. > > 3. The abuse filter is already a huge problem for mobile, since on many wikis > it's configured to show a CAPTCHA for certain conditions (non-autoconfirmed > users adding links, adding/removing large chunks of text, or, on projects > like > Portuguese Wikipedia, making edits of any kind), which in turn causes the > mobile editor to throw an error. Right now the error rate is hovering at an > alarming 48% across all projects; making editing available to anons would > guarantee that the error rate would skyrocket. Until we build a replacement > for > the abusefilter CAPTCHA (again, a tricky engineering problem on mobile), we'd > knowingly be showing anons a broken and unusable edit button most of the > time. I found bug 53369 for AbuseFilter, but couldn't find one for CAPTCHA. FWIW, the AbuseFilter can't be told to show a CAPTCHA, they're two totally separate extensions. > > 4. A lot of the features we're building on desktop to keep people in the loop > about what's happening to their edits (like email and Echo notifications) are > for logged in users only, and those become extra critical communication > mechanisms on mobile, where it's harder (and, again, a bigger break from your > workflow) to find and check your talk page. I'm not sure how we'd build a > notification system for mobile IP editors without unnecessarily spamming a > huge > swath of mobile readers with notifications about user warnings that don't > involve them. This is already a problem on desktop, but it becomes > exponentially more problematic with the wildly fluctuating IPs of most mobile > devices. I filed bug 56828 for discussing enabling Echo for anonymous users. I don't think that is a blocker for mobile editing though.
The draft privacy policy at [[m:privacy policy]] reiterates: --- You are not required to create an account to read or contribute to a Wikimedia Site, except under rare circumstances. However, if you contribute without signing in, your contribution will be publicly attributed to the IP address associated with your device. --- The "human-friendly" summary also includes "you may: read, edit, or use any Wikimedia Site without registering an account." Quoting comment 2, "anonymous editing is a [[m:founding principle]] of Wikimedia wikis that can't simply be brushed aside by a small development team." This is a high priority issue. I believe there's some awful configuration variable that needs to be killed in order to resolve this bug. I'll try to investigate later.
MZMcBride: Please don't repeatedly reset priority to high plus keep severity as enhancement as this request obviously covers enhancing features. Actionable dependency bugs for this ticket could be high if the development teams considers them high priority when they triage and assess tickets.
(In reply to comment #5) > MZMcBride: Please don't repeatedly reset priority to high plus keep severity > as enhancement as this request obviously covers enhancing features. Andre: It isn't an enhancement to support core functionality. And this is a high priority given the founding principles and other policies in play, as explained in comment 4. If you're confused about why I set the priority or severity a particular way, try discussion instead of blind reversion. Thanks.
(In reply to comment #6) > If you're confused about why I set the priority or > severity a particular way, try discussion instead of blind reversion. Thanks. Let me try discussion, although this should probably be discussed elsewhere. I'm happy to continue the conversation wherever you prefer. * According to https://www.mediawiki.org/wiki/Bug_management/Bugzilla_etiquette (draft), "bug status, priority and milestone should reflect reality (in summary form), they do not cause it. If in doubt, read about the meaning of the fields and do not change them, but add a comment suggesting the change and convincing reasons for it" * According to https://www.mediawiki.org/wiki/Bugzilla/Fields#Priority , "priority should normally be set by the developers who plan to work on the bug (or by the bugwrangler), not by the one filing the bug or by outside observers" * According to https://www.mediawiki.org/wiki/Developers/Maintainers , the maintainers of MobileFrontend are "the WMF mobile team, especially Arthur Richards" (all CCed here) * According to https://www.mediawiki.org/wiki/Bug_wrangler , Andre's role includes "working closely with product managers and developers to prioritize, categorize and assign bugs based on Mediawiki features and extensions" * According to Gerrit you don't seem to be a regular contributor to this extension. For all these reasons I believe that you, me, or anybody else interested in this area but not developing for it are not entitled to enter prioritization wars. This is Bugzilla, and all of us work here to improve things, but if a maintainer or the bug wrangler defines explicitly a priority and you still disagree then the solution is not to revert again. MZMcBride, I'm not attempting to discuss your points in this and other related reports. I have no opinion about the topic. However, I do have an opinion about the usefulness of prioritization wars in Bugzilla. After many years seeing them happening in various reports of different projects the pattern is always the same: a first round might have some justification but after some back-and-forth they are always counterproductive, wasting people's energies and damaging community's collaboration and good mood. And all this for no good reason, since at the end the maintainers developing the component are the ones deciding what goes in it and when. They tend not to be convinced by users reverting their prioritizations in Bugzilla. You are a vet, and you know all this well. If you want to challenge the current priorities of the MobileFrontend, fine. You can bring your arguments here as you do, and you can also escalate to other venues in case you think more eyes and opinions are needed. Up to you. But please, let the Mobile team reflect here the current priorities they have for their plans. Thank you.
I already said all I have to say about this topic at bug 52442 comment 4 and below, just a point: (In reply to comment #7) > [...] And all this for no good reason, > since > at the end the maintainers developing the component are the ones deciding > what > goes in it and when. [...] This is a tracking bug (which also means that usually its priority/severity fields don't mean much) and part of the rationale provided was: (In reply to comment #4) > I believe there's some awful configuration > variable that needs to be killed in order to resolve this bug. I'll try to > investigate later. Configuration matters are not under exclusive control of the extensions' maintainers. If a WMF/site policy happened to say that a certain configuration is mandatory, it wouldn't matter much what the authors of the code think about it and it it takes no intervention on their end to make it happen.
(In reply to comment #8) > If a WMF/site policy happened to say that a certain configuration > is mandatory, it wouldn't matter much what the authors of the code think > about it and it it takes no intervention on their end to make it happen. Yes, I also thought about this too. The situation is the same though: the decision of enabling anonymous editing or not will not be decided because certain Bugzilla report have one priority or another. As you point out that decision doesn't even rely on the Mobile team alone. That discussion can't go far in MobileFrontend bug reports, it must happen elsewhere. I would start with the mobile-l or the wikimedia-l mailing list, depending on where do you want to put the emphasis.
Resetting to enhancement. Sigh. I will write a bot if necessary.
"This is a tracking bug (which also means that usually its priority/severity fields don't mean much)" Whether or not those fields mean anything is a decision for the developer who is charged with resolving the bug, not the bug filer. Quim pointed this out above, and the fact that it is a tracking bug does not affect that.
(In reply to comment #11) > "This is a tracking bug (which also means that usually its priority/severity > fields don't mean much)" > > Whether or not those fields mean anything is a decision for the developer who > is charged with resolving the bug By definition, there's no such a thing for tracking bugs. So you've just confirmed what I said.
Change 106851 had a related patch set uploaded by MZMcBride: Allow anonymous editing https://gerrit.wikimedia.org/r/106851
(In reply to comment #10) > I will write a bot if necessary. No need. I fixed up Gerrit change #106851 for you. It's ready for review.
(In reply to comment #7) > Let me try discussion, although this should probably be discussed elsewhere. > I'm happy to continue the conversation wherever you prefer. Quim: if you're truly interested in discussion, please respond to comment 4 or the relevant portion of comment 6. Comment 7 was not an attempt to have a discussion, it was an attempt to lecture. Perhaps in your culture five consecutive bullets of "according to ..." constitutes a discussion, but I think it'd be better if you directly addressed the substantive points raised above or didn't post here.
(In reply to comment #3) > Basically there needs to be some mobile equivalent of the anoneditwarning > ([[MediaWiki:Anoneditwarning]]). This is now bug 59937.
(In reply to comment #0) [[m:Research:Anonymous edits]] may prove useful here. There may be newer research as well.
(In reply to comment #17) > There may be newer research as well. [[commons:File:Anonymous editors - WMF R&D showcase (Dec. 2013).pdf]]
(In reply to comment #15) > Comment 7 was not an attempt to have a discussion, it was an attempt to > lecture. Perhaps in your culture five consecutive bullets of "according to > ..." > constitutes a discussion, but I think it'd be better if you directly > addressed > the substantive points raised above or didn't post here. Good discussions deserve good argumentation, and I did my best trying to explain why you shouldn't keep reverting the priorities set by maintainers. I have shared my humble opinion at Bug 53076 comment 12. This discussion about anonymous mobile editing focuses on Wikimedia principles and needs. The decision to restrict mobile editing to registered users is more strategic than technical, and therefore (imho) that discussion belongs more to mobile-l, wikimedia-l, Meta, etc than to MobileFrontend Bugzilla reports. The Mobile and Design teams are basically executing according to that strategy. Challenge the strategy, be convincing, and if/when anonymous mobile editing becomes a higher priority for these teams then they will work accordingly. In the meantime, any contributions to MobileFrontend improving the experience of anonymous editing are welcome, and 3rd party MediaWikis might want to benefit from them regardless of the decisions made in the Wikimedia context.
(In reply to comment #19) > Good discussions deserve good argumentation, and I did my best trying to > explain why you shouldn't keep reverting the priorities set by maintainers. > > I have shared my humble opinion at Bug 53076 comment 12. This discussion > about > anonymous mobile editing focuses on Wikimedia principles and needs. The > decision to restrict mobile editing to registered users is more strategic > than > technical, and therefore (imho) that discussion belongs more to mobile-l, > wikimedia-l, Meta, etc than to MobileFrontend Bugzilla reports. Strategic in what way? Bug 52442 comment 14 which was the rationale that was given was basically technical issues. It's unclear why discussions on meta/wikimedia-l/etc. are required. Shouldn't any violation of [[m:Founding principles]] (it's #2 on the list) immediately be something that should be fixed? > The Mobile > and > Design teams are basically executing according to that strategy. Challenge > the > strategy, be convincing, and if/when anonymous mobile editing becomes a > higher > priority for these teams then they will work accordingly. I'm not sure how to convince someone that the founding principles are extremely important without just saying that. > In the meantime, any contributions to MobileFrontend improving the experience > of anonymous editing are welcome, and 3rd party MediaWikis might want to > benefit from them regardless of the decisions made in the Wikimedia context. Indeed :)
(In reply to comment #20) > Strategic in what way? Bug 52442 comment 14 which was the rationale that was > given was basically technical issues. Maybe it's simply a matter of wording, it doesn't matter. What matters to understand the current priorities of the Mobile Web team is this: https://www.mediawiki.org/wiki/Wikimedia_Engineering/2013-14_Goals#Mobile As you can see, not only anonymous mobile editing doesn't appear there, in fact the Mobile team has some targets tightly related to more and more engaged registered users in Wikimedia projects. Developers interested in good support for anonymous mobile editing in MobileFrontend can contribute in areas where the Mobile team won't focus now. This work is happening as some contributors are very motivated, very good! If what you want is to change the priorities of the Mobile team so they can focus on anonymous editing (necessarily changing their current goals) then this is requires a more strategic discussion that I really don't think that will or should happen in Bugzilla reports. This is what I'm trying to say.
From bug 59937 comment 3 by kenan wang: --- Hi Legoktm. We have decided not to approve this patch as the warning takes up too much of the limited screen real estate of the edit screen. However, anonymous mobile editing is an area that we are looking into. In the next few days we will be publishing a preliminary plan for enabling anonymous editing within mobile. This will be published on mediawiki.org and available for comment by the community. When that is published I will also post a link to that here. ---
Change 106851 abandoned by Jdlrobson: Allow anonymous editing Reason: From the activity on the bug it's clear this needs some more thought. Kenan Wang is working on a strategy to enable anonymous editing that he says he will be sharing soon. https://gerrit.wikimedia.org/r/106851
Hi all, Here is our plan for Wikitext editing on mobile. As you can see anonymous editing is a part of that plan. The TLDR is that we do believe that anonymous editing is important on mobile, but we want to make sure that we roll it out in a way that does not cause unnecessary headache for the community or the WMF mobile team; thus we are planning a 3 stage rollout process. Please take a look and leave comments on the talk page, I look forward to ironing out some of the details with you all: https://www.mediawiki.org/wiki/Mobile_wikitext_editing Note: This will also be distributed more widely in the next week or so (village pumps, email lists, etc.)
Two more technical requirements for anonymous editing are: *Ability to notify anonymous mobile editors (e.g. IP block threats, thanking) *Ability for anonymous mobile editors to view their talk pages I know this was brought up previously but let me expand more on this. These features are important because as https://en.wikipedia.org/wiki/Wikipedia:Blocking_policy#Blocking describes: "Administrators must supply a clear and specific block reason that indicates why a user was blocked. Block reasons should avoid the use of jargon as much as possible so that blocked users may better understand them. Administrators should notify users when blocking them by leaving a message on their user talk page. It is often easier to explain the reason for a block at the time than it is to explain a block well after the event."
(In reply to comment #25) > Two more technical requirements for anonymous editing are: > > *Ability to notify anonymous mobile editors (e.g. IP block threats, thanking) > > *Ability for anonymous mobile editors to view their talk pages This bug is a tracking bug. If you look above at the "Depends on:" list at the top of the page, you can see which bugs are listed as dependencies for this bug to be considered resolved (currently bug 53076, bug 56834, and bug 59937). Bug 56831, also listed, has a line through it because it's been resolved. Bug 56834 covers the ability to notify anonymous mobile editors of new messages.
Almost one year after being filed, this bug is still lacking serious blockers: does this mean that the Mobile team is unable to articulate the reasons for editing to be disabled on the mobile site? Bug 56834 probably requires about 1 h coding to restore the traditional message bar on mobile; bug 59937 is not really a blocker. If there were no other reasons to enable editing on mobile, we could do it in a week.
Nemo - See https://www.mediawiki.org/wiki/Mobile_wikitext_editing#Anonymous_editing Apps is launching with this first. The web is a small team and we are not ready to face anonymous editing on Wikimedia sites. Any help with getting the infrastructure their for 3rd parties though is appreciated. The first helpful step towards this would be to get a patch for bug 59937.
I'm going to add some blockers just because this is the tracking bug; it doesn't mean I think they are requirements for anything.
