Last modified: 2014-08-14 22:25:07 UTC
The current default of $wgMFAnonymousEditing is false in [[mw:Extension:MobileFrontend]] (in MobileFrontend.php). We should re-examine whether this matches expectations of people installing the extension. I guess I see three points to consider: * determining whether the default should be changed (i.e., whether it matches user expectations when someone installs the MobileFrontend extension to automatically have anonymous editing disabled); —— the alternate here would be setting it to true by default and overriding Wikimedia's setting, which is trivial to do; * determining whether this global's implementation is a great idea overall; if it's meant to be temporary (until the resolution of bug 53069), it's completely fine; if this is meant to stay in the software indefinitely, a more granularized array approach may make sense for the global; or perhaps using (or re-using) assigned user rights (user groups "*", "user", etc.) * (tangential to point two) documenting $wgMFAnonymousEditing at <https://www.mediawiki.org/wiki/Extension:MobileFrontend> (I couldn't see any mention of it there)
anon edits being enabled should be higher prio than low,imho. it's a core wiki principle
I've given this additional consideration and having $wgMFAnonymousEditing doesn't make any sense to me. It should simply be removed from the extension. I can't think of any reason that a wiki would install this extension and not want the standard "edit" user right to just work with mobile.
Bug title does not describe a bug but removing functionality. Hence setting priority to enhancement.
(In reply to comment #3) > Bug title does not describe a bug but removing functionality. Hence setting > priority to enhancement. It isn't an enhancement if the current behavior is broken. Right now, a wiki admin would reasonably assume that 'edit' would control editing. This isn't the case given this confusing global configuration variable. Andre: please engage in discussion and collaboration rather than simply blindly reverting any severity or priority change that you happen to disagree with.
Removing this will kill the CTA that has been successfully allowing us to run getting started like experiments on new users and the huge increase in accounts created in the project as general so we need to think carefully about this. I agree however that we should probably give this a higher priority than normal. I'm reverting the status back to enhancement as not enough discussion has occurred to warrant this change in status. MZ: please engage in discussion and collaboration rather than simply blindly reverting any severity or priority change that you happen to disagree with.
(In reply to comment #5) > Removing this will kill the CTA that has been successfully allowing us to run > getting started like experiments on new users and the huge increase in > accounts created in the project as general so we need to think carefully about > this. I agree however that we should probably give this a higher priority than > normal. Experimenting on new users without their consent sounds like a very bad practice, not something we want to encourage. Regarding calls to action, that point hardly seems relevant here. You can have many calls to action without misleadingly giving the impression to anonymous users that an account is required to edit. > MZ: please engage in discussion and collaboration rather than simply blindly > reverting any severity or priority change that you happen to disagree with. Hurrrrrrrrrrrr.
Don't we have, like, an entire repo dedicated to configuration settings different in the code itself and in Wikimedia environment? We could totally use that here I guess.
(In reply to comment #7) > Don't we have, like, an entire repo dedicated to configuration settings > different in the code itself and in Wikimedia environment? We could totally > use that here I guess. We do! But this setting's existence doesn't make any sense on any MediaWiki wiki, from what I can tell.
Well, in that case, we can use the very same repo to create some truly horrific hooks which would achieve the same purpose. This kind of stuff was done before.
(In reply to comment #9) > Well, in that case, we can use the very same repo to create some truly > horrific hooks which would achieve the same purpose. This kind of stuff was > done before. Is there a reason to have $wgMFAnonymousEditing? If you wanted to disable MobileFrontend, wouldn't you just uninstall it? And when installing, I would think it would follow the standard 'edit' permission. Or use its own user right if someone has a decent use-case. I still need to look closer at this. I may end up submitting a changeset of my own.
Change 106851 had a related patch set uploaded by Jdlrobson: Remove wgMFAnonymousEditing https://gerrit.wikimedia.org/r/106851
$wgMFAnonymousEditing is not documented at [[mw:Extension:MobileFrontend#Configuration_settings]], but I assume it is a configuration that can be changed in LocalSettings, right? If this is the case, I think it shouldn't be removed unless there is already another way for admins to limit mobile edits while allowing desktop edits. The fact that it set to false by default shouldn't be a big deal, right? I think the current setting makes sense since all in all the whole concept of editing MediaWikis from your mobile device is quite new both for users and admins. As said, if an admin is unhappy about false then setting it to true is trivial. If the motivation of this report is the policy for mobile editing in Wikimedia projects, then I think such discussion doesn't belong to MobileFrontend but to Wikimedia configuration. I specifically disagree with the idea of removing existing functionality in a MediaWiki extension because of a problem specific to Wikimedia that can be solved setting a variable to "true".
(In reply to comment #12) > If this is the case, I think it shouldn't be removed unless there is already > another way for admins to limit mobile edits while allowing desktop edits. Is there a use-case for doing this? If so, what is it? And is there any way for this potential use-case to be covered by the standard "edit" user right?
(In reply to comment #13) > (In reply to comment #12) > > If this is the case, I think it shouldn't be removed unless there is already > > another way for admins to limit mobile edits while allowing desktop edits. > > Is there a use-case for doing this? If so, what is it? Isn't the question whether there is a use-case to remove an existing feature that doesn't seem to bother anybody in MediaWiki-not-Wikimedia land? The average third party MediaWiki using MobileFrontend is used to the idea of having editable desktop and read-only mobile, since mobile editing is a recent addition. The fact that they installed voluntarily MobileFrontend shows that they were happy with this combination. Now that mobile editing is possible, they can voluntarily enable anonymous editing in their sites with a simple change in the configuration. If $wgMFAnonymousEditing is simply removed, and no technical alternative exists to restrict anonymous mobile editing, then they will be forced to accept it when upgrading MobileUpdate, which sounds like a weird imposition if you are not aware of these Wikimedia-centric debates. I'm very familiar with all this since my personal pet project has been using MobileFrontend since it was quite a wild young beast. We might enable anonymous mobile editing now that we upgraded to last versions of MediaWiki and MF, but it would be nice to be able to apply this change (and revert it if needed) based on our own criteria and actions, instead of being forced as part of a software update. > And is there any way for this potential use-case to be covered by the > standard "edit" user right? No idea, others might know better.
(In reply to comment #14) > Isn't the question whether there is a use-case to remove an existing feature > that doesn't seem to bother anybody in MediaWiki-not-Wikimedia land? Nope. Global configuration variables are similar to user preferences in this way. There should be a sensible default and an option should only be introduced if absolutely necessary. In this case, I (still) don't see a compelling use-case. > If $wgMFAnonymousEditing is simply removed, and no technical alternative > exists to restrict anonymous mobile editing, then they will be forced to > accept it when upgrading MobileUpdate, which sounds like a weird imposition if > you are not aware of these Wikimedia-centric debates. Sorry, this doesn't make any sense to me. You or any other wiki system administrator determine who can edit by modifying user rights in LocalSettings.php. You can restrict anonymous (mobile) editing easily and many wikis do. > I'm very familiar with all this since my personal pet project has been using > MobileFrontend since it was quite a wild young beast. We might enable > anonymous mobile editing now that we upgraded to last versions of MediaWiki > and MF, but it would be nice to be able to apply this change (and revert it if > needed) based on our own criteria and actions, instead of being forced as part > of a software update. MobileFrontend is a mobile front-end. If you're not interested in having a mobile front-end, you can uninstall the extension (or downgrade it, I suppose). If you want to restrict anonymous editing, that's part of MediaWiki core, as stated. I don't see the issue here. In my mind, it's far more disruptive to have an undocumented configuration variable that defies general expectations. If you think of MobileFrontend as a skin, it would never make any sense that it would touch the ability of anyone to edit.
To be clear, you _could_ re-implement this same functionality by creating mobile-specific user rights (e.g., mobile-edit, mobile-upload, etc.). But I don't see a compelling case for making such a distinction in user rights and the additional code complexity isn't particularly cheap.
(In reply to comment #15) > You or any other wiki system > administrator determine who can edit by modifying user rights in > LocalSettings.php. You can restrict anonymous (mobile) editing easily and > many wikis do. To be clear: can MediaWiki sysadmins disable anonymous mobile editing while enabling desktop mobile editing by modifying user rights? If today they can, fine, I'm happy to recommend that approach to MobileFrontend users. If not, then please don't remove $wgMFAnonymousEditing while no better alternative exists. MZMcBride, you say that you don't see a compelling case. The maintainers of MobileFrontend do see the point, to the extent of having developed a solution for it. Bug 52442 comment 14 is probably a good summary of that rationale. This is not a real issue for any 3rd party MediaWiki sysadmin because if anybody disagrees with that rationale they can just set $wgMFAnonymousEditing to true and move on. Going back to your comment 0 and potential steps in the short term, your main motivation in this discussion is this: > setting it to true by default and overriding Wikimedia's setting These are two very different things. Setting $wgMFAnonymousEditing to true by default in Mobile Frontend is indeed trivial, although it is also trivial for sysadmins to change it. Therefore I would say that, as long as the maintainers of MobileFrontend are not confident about the support for anonymous mobile editing, it make sense to give the choice to MediaWiki sysadmins with a conservative default. Setting $wgMFAnonymousEditing to true in Wikimedia projects is a Wikimedia specific discussion. Trying to address it with your patch against MobileFrontend doesn't look like a good approach to me.
(In reply to comment #17) You've been asked repeatedly to provide a use-case and have failed to do so. > MZMcBride, you say that you don't see a compelling case. The maintainers of > MobileFrontend do see the point, to the extent of having developed a solution > for it. You seem to have missed (or you're deliberately ignoring) comment 11. > Bug 52442 comment 14 is probably a good summary of that rationale. No; cf. bug 53069 comment 2. > This is not a real issue for any 3rd party MediaWiki sysadmin because if > anybody disagrees with that rationale they can just set $wgMFAnonymousEditing > to true and move on. This comment makes no sense. > Going back to your comment 0 and potential steps in the short term, your main > motivation in this discussion is this: > >> setting it to true by default and overriding Wikimedia's setting > > These are two very different things. No kidding. However, it doesn't make sense to change the extension default or specify the setting in Wikimedia's configuration if the configuration variable should not exist at all. A global configuration variable requires a use-case, otherwise it should be removed. You still have not provided any use-case here.
The use-case is the following: Number of useful edits from anonymous mobile editors < number of non-useful edits from anonymous mobile editors, but number of useful edits from anonymous desktop editors > number of non-useful edits from anonymous desktop editors. I imagine for most WMF wikis the equation will work out in favor of anonymous editing on mobile, but I'm not as sure about 3rd party wikis (where there is less social cost for non-useful edits). We already know from existing data that editing behavior is different on mobile than desktop, and we also know from existing desktop data that anonymous editing is different than logged in editing. Thus it is reasonable to conclude that anonymous mobile editing will show a unique set of behaviors (and thus wiki administrators should be able to treat them as a unique group in the software). At least that's my 2 cents.
Use case for 3rd party MediWiki sysadmins: "Mobile used to be read-only, now we just upgraded to 1.22 and we got mobile editing. It's quite new, kind of testing. Let's see how it goes. If registered users have problems or cause mess via mobile editing, at least we have a way to contact them. Also, if they are registered then they probably have a higher interest in the site, a higher probability to share opinions about the new feature with us. Motivation and commitment of anonymous users is unclear, and contacting them is between difficult and impossible. Therefore it is good to have an option to block anonymous mobile editing while the whole feature matures. Our wiki doesn't need to be at the forefront of MediaWiki experimentation. We have other problems more mundane, like preventing spam or explaining our users how to edit, discuss, translate. Let's let Wikipedia and others try first, as with many other new features. Let us know when you think the feature is ready form everybody." PS: I don't come here to fight, just to express a personal opinion based on my own experience as humble amateur 3rd party MediaWiki sysadmin. I have said all I had to say in this report.
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
(In reply to Gerrit Notification Bot from comment #21) > 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. Any comment on when "sharing soon" might be?
Preventing IP edits is against the principle of Wikipedia. And it makes no sense to prevent IPs form using the mobile editor, because they can edit withthe desktop editor on their phones too.
> Any comment on when "sharing soon" might be? Is there any news? :)
(In reply to MZMcBride from comment #0) > * (tangential to point two) documenting $wgMFAnonymousEditing at > <https://www.mediawiki.org/wiki/Extension:MobileFrontend> (I couldn't see > any mention of it there) I just did this: https://www.mediawiki.org/w/index.php?title=Extension%3AMobileFrontend&diff=1030618&oldid=1030424
Mobile folks: Could you please communicate when "sharing soon" might be, and what's been going on?
Kenan is no longer with WMF, but his plan (which I thought was documented somewhere, though I can't seem to find it now..) was to gather data on anonymous editing via the two native apps which we just released to market -- the Android release has been live for about a month, and iOS just went out last week, so we're still pulling together the numbers for editor volume, productivity, and quality. We also have some interesting stats coming from the tablet redirect (when we began taking people to the mobile site on tablets) in June; there'll be a presentation on some of this at Wikimania. There's already a patch in alpha that introduces the first step toward a non-logged in editor workflow (big thanks for Florian for working on this!) -- the Mobile Web team is currently a bit under-resourced to work on this, and with Wikimania travel cutting out a big chunk of this month, it's not something we can realistically get to this quarter (i.e., till after September). But if the data from apps + tablets shows that lots of people want to edit without an account on mobile (and do so productively!) we'll probably start building on Florian's patch next quarter (October-December).
