Talk:Mobile wikitext editing
Anonymous mobile editing
Hi MZMcBride I've added a rough timeline to the wikipage. Please let us know if you agree on the items that need to be completed and then we can work on getting agreement on timelines. We would further like to expand this conversation over the next two weeks. The next stages that we planned were to release on email lists and then post to village pumps. Do you have any thoughts on this communication plan? Thanks. --KWang (WMF) (talk) 01:45, 28 January 2014 (UTC)
- Hi KWang. I see this edit by an anonymous user that added 2013 dates. Is that what you mean? Assuming 2014, I think this rough timeline is unacceptably long.
- bugzilla:53069 (filed in August 2013) is tracking obstacles to enabling anonymous editing, which is my primary focus here. I spoke with Tomasz and everyone seems to be on the same page that enabling anonymous editing via mobile is an important priority, particularly given Wikimedia's founding principles. Speaking from the technical side, I have no idea why it would take more than a month or two to get this resolved.
- Tomasz seemed a lot more concerned with the social side, though my personal opinion is that these concerns are overblown. I did offer to take a look at the concerns that are purportedly being raised about the idea of anonymous mobile editing. Given that it happens thousands of times every day through the desktop interface, I'm personally not particularly worried.
- On the other hand, mobile uploading on Commons was apparently problematic, so perhaps there will be reactionary symptoms here. In my view, we should address actual issues when they actually arise. We simply cannot have an interface, mobile or otherwise, that strips out red links and creates a fictitious requirement to sign in to edit, among other zaniness. That's anti-wiki. We need to address this as quickly and as thoughtfully as possible. --MZMcBride (talk) 03:29, 28 January 2014 (UTC)
- re: MZMcBride 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've recorded this on bugzilla:53069. I know these issues were 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."
- These features must both be built but more importantly an evaluation must be made over time if IP addresses are a reliable enough source for tracking anonymous users on mobile that we can use them for the purposes of notifying and blocking users. On desktop we know about a range of complications in using IP addresses, these issues compound significantly on mobile. The first 2 stages of the rollout focus on this problem and two 3 month stages seems an appropriate length of time for us to make that evaluation while giving time for developers to make appropriate changes to the mobile products, and for the community to make appropriate changes to policy. The third stage which also lasts roughly 3 months is to ensure that we are doing what we need to ensure high quality edits from anonymous mobile editors.
- Could you provide feedback on:
- The technical items that must be completed
- The best way to socialize these changes and get the appropriate engagement from the community to address the IP address question.
- The best way to avoid backlash similar to what we incurred with the logged out mobile photo CTA
(unindent) Hi KWang.
I replied briefly at bugzilla:53069#c26. In short, bugzilla:56834 covers the anonymous user notifications issue. If there are additional technical issues (i.e., additional obstacles to enabling anonymous mobile editing), please be sure to file a bug in Bugzilla and have it block bugzilla:53069.
Regarding the English Wikipedia's block policy, it's tangentially relevant here. For what's worth, while I've never been too involved with user blocking, I have well over 100 blocks and over 100 unblocks on the English Wikipedia (in addition to over 800,000 other administrative actions). I've also been blocked and unblocked several times over there. Needless to say, I'm quite familiar with the policy, there's no need to quote it to me. ;-)
You asked me to provide feedback. I'll address that below.
- The technical items that must be completed: this is covered by bugzilla:53069. I believe the known technical work involved here is minimal (a few weeks at most).
- The best way to socialize these changes and get the appropriate engagement from the community to address the IP address question: Tomasz made similar comments, yet nobody has been able to point to specific complaints or concerns about anonymous editing. There are thousands of anonymous desktop edits made daily. The community has been sufficiently "socialized" because anonymous editing has existed since the dawn of Wikipedia in 2001. Allowing anonymous editing (via mobile) is neither ground-breaking nor novel.
- The best way to avoid backlash similar to what we incurred with the logged out mobile photo CTA: I didn't follow that incident as closely as others, but basically I believe there was a call-to-action from the mobile team that basically encouraged copyright violations to be uploaded to Commons. The answer there is to... not do that. We can enable anonymous mobile editing without any kind of call-to-action. The pencil icon alone should be sufficient. If people want to log in, they will, just as they do via desktop. And, of course, images are different from text. The biggest concern with text contributions is copying and pasting. With photos, the concerns are a lot more varied and hairier (freedom of panorama, personality rights, copyright, fair use, etc.).
Again, we should address actual issues that actually arise. Wringing our hands over the "what if"s isn't really helpful or productive. We have somewhere around 900 wikis. We can surely enable anonymous editing on a few of those and see what happens. If chaos ensues, we can always roll back.
- MZMcBride let me be more specific.
- 1) The specific concern that we want to make sure gets addressed is this: IP address editing is problematic for mobile. This is because in order to leave talk messages for anonymous editors, to notify anonymous editors, and to block anonymous editors which are all important workflows we use IP addresses. Up until now we've known this to be tricky on desktop but workable. I'm not sure that this will be workable for 2 reasons:
- a) IP addresses for mobile users are less permanent so leaving messages or notifications for users on their IP addresses seems dubious as does blocking someone through an IP address
- b) IP addresses for mobile users are more ambiguous (i.e. it's harder to distinguish between multiple users using their IP addresses because wireless networks sometimes assign similar IP addresses to users) so multiple users could now get the same talk messages, notifications, and blocks
- 2) First a point of clarification. When I say "call to action" that call to action can be passive. "We can enable anonymous mobile editing without any kind of call-to-action. The pencil icon alone should be sufficient." It is clear that our language differs because the pencil action is a call to action in our terminology.
- When you say "basically I believe there was a call-to-action from the mobile team that basically encouraged copyright violations" this is not true. What we did is simply show a call to action (in this case a blue button on pages that were missing lead images) to logged out users and then upon clicking on that button we directed those users to log in in order to contribute. Those users then had to create accounts in order to upload images. We did not "encourage copyright violations." What we also did not do is do our due diligence. We released a feature that we did not think would cause a problem, but it did. Likely this feature needed much more testing and development. Users needed to be educated more about their impact as well as how to properly contribute. Maybe additional safeguards needed to be put in place. As a result Logged out CTAs for photo uploads is now a politically sensitive topic, and the mobile team lost political capital with the commons community. For us the lesson has been three fold:
- a) If we make it easy for users to contribute often contributions will go up but perhaps at the risk of quality. In order to preserve quality in these cases we need to carefully evaluate the proper education and training to give users before we let them run loose.
- b) Mobile can be different than desktop. These same sort of problems never arose on desktop because the context is different. Mobile CTAs are more prominent because there is less on the screen. Mobile phones have different affordances, in this case most phones have cameras readily available which resulted in more users posting lower quality or poorly selected photos. At the same time we see the exact opposite phenomenon with the mobile apps. Photos from the mobile apps are extremely high quality showing a lower revert rate than even desktop users. Context matters.
- c) Mobile is big enough to make a significant impact. The volume of photos from the photo upload CTA was high. The commons community was unprepared for this. Policies and procedures needed to be put into place in order to accommodate this additional volume. We are now in a situation where roughly 18% of Wikipedia traffic comes from mobile and 18% of Wikipedia registrations come from mobile. Enabling anonymous editing on mobile could result in a similar uptick in anonymous edits. Without the proper time to put in place policy and procedural changes the Wikipedia community may face similar challenges.
- Given this I do agree with this "Again, we should address actual issues that actually arise. Wringing our hands over the "what if"s isn't really helpful or productive. We have somewhere around 900 wikis. We can surely enable anonymous editing on a few of those and see what happens." Where I want to be careful is "If chaos ensues, we can always roll back." While this is true each time the WMF introduce new features that create chaos we lose political capital. So I am still looking to do this in a more nuanced way, giving us and the community more time to adapt to these changes.
- At this point I think we still need to get all of the technical blockers down so I will create bugzilla tickets and have them block bugzilla:53069. We can then talk about scheduling this work. Right now our mobile web team is focusing this quarter on moving tablets to mobile and may not have time to work on this in ernest for the next two months. But the mobile apps team is planning on doing this work. Also, I would prefer that all of these changes go through our beta site first (hence stage 2) so that we can make sure they work well before rolling it out to broader audiences.
- Then let's go ahead and create a rollout schedule for smaller wikis moving onto larger wikis. I'll create a page that we can start iterating on and post it into the subject-space page. Would you be willing to help us with this rollout schedule?
- Lastly we still need to investigate the IP address issue. I don't think this is something we can gloss over. IP addresses will likely be problematic on mobile. --KWang (WMF) (talk) 22:55, 30 January 2014 (UTC)