Re: [Wiki-research-l] FW: What works for increasing editor engagement?
Scott, That's why the rest of my email focussed on things that we could that would improve editor retention and which would be uncontentious, but also there is a third question, are people's assumptions re newbie behaviour true? This is where research would be useful. Where the problem lies in mutually contradictory assumptions about user behaviour then the best way to break the logjam is with research, now I'm confident that the research will support my assumptions, but if I am wrong then I'm prepared to back solutions that I have previously opposed. Regards Jonathan Cardy On 26 Sep 2014, at 09:56, Scott Hale computermacgy...@gmail.com wrote: On Fri, Sep 26, 2014 at 1:46 PM, WereSpielChequers werespielchequ...@gmail.com wrote: Attn Luca and Scott There are some things best avoided as going against community expectations. I would be happy to see flagged revisions deployed on the English Wikipedia but I'm well aware that there is a significant lobby against that of people who believe that it is important that your edit goes live immediately. And with the community somewhat burned by bad experiences with recent software changes now would be a bad time to suggest such a controversial change. Yes. Completely agree, and that was the exact point of my first email: On Fri, Sep 26, 2014 at 9:15 AM, Scott Hale computermacgy...@gmail.com wrote: And that is the fundamental flaw with this whole email thread. The question needing to be answered isn't what increases new user retention. The real question is what increases new user retention and is acceptable to the most active/helpful existing users. The second question is much harder than the first. ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Re: [Wiki-research-l] Fwd: FW: What works for increasing editor engagement?
Dear James, very well argued, thanks for the insightful post. Saving drafts on the other hand could help avoid many conflicts on less-trafficked pages. Right now, on a page that is edited infrequently, this happens: - User A starts an edit - User A saves not to lose work, not quite done yet. Resumes the edit. - User B (typically an editor) sees the edit by A, and sets to work polishing it. Saves. - User A saves -- conflict The first edit by A woke up B, and led to the conflict. If we allowed saving drafts, the following would be more likely: - User A starts an edit - User A saves a draft, and continues the edit. - User A saves the edit. - User B (typically an editor) sees the edit by A, and sets to work polishing it. Saves. The conflict would occur only if A had second-thoughts about the edit and continues work after saving it, which might happen, but les frequently. Of course saving drafts is also cumbersome to implement at scale (how long would they persist? there would be clean up needed, etc; maybe they could persist for one week then be mailed back to the author and deleted?). Luca On Fri, Sep 26, 2014 at 11:22 AM, James Forrester jforres...@wikimedia.org wrote: [Re-sending as it bounced first time.] On 25 September 2014 22:45, Pine W wiki.p...@gmail.com wrote: FWIW there were sessions at Wikimania about concurrent editing. I think there is community support for the concept. If it helps us retain good faith new editors then that is another good reason to press foward on this subject. Perhaps James Forrester can provide an update on the outlook for concurrent editing capability. Hey. [This is a bit off-topic for wiki-research-l, but I've been asked to answer.] First things first: There aren't any plans right now to try to roll this out any time soon. Collaborative real-time editing is an interesting task in terms of engineering, but an exceptional challenge in terms of product. I think that it's reasonable to talk about it as a possible solution to issues, but the number of problems it raises is so great that people should be careful to not talk of it as some magic pixie dust. :-) For a couple of brief examples: If the objective is to prevent all edit conflicts by making parallel edits them impossible, this means either: * everyone has to use the collaborative editor; * people who can't use the collaborative editor (e.g. old computer, slow network, no JavaScript, etc.) can't edit at all; * people who don't like the collaborative editor are unable to edit ever again; and * bots can't edit at all (because they can't react to prompts from other users) … or: * you have to choose to use the collaborative editor for each edit (how do newbies know, or is it opt-out somehow?) * as soon as someone wants to edit an article collaboratively, everyone else's edits die and they're told so (or they all have to wait for the collaborative edit session to end and then manually resolve the edit conflict); * for people who can't or don't want to use the collaborative editor, and all bots, the article is essentially locked from their editing until the collaborative edit is finished. Neither of these are great options. If instead we're happy to keep having edit conflicts, we can allow parallel edits, but then the benefit for newbies (and, frankly, the rest of us) goes away the second your collaborative edit conflicts with a non-collaborative edit. Whoops. Say that we've decided on a course of action for the above, maybe by biting the bullet and denying people with older computers *etc.* the ability to edit (which I think would be sad and a dereliction of our values); what do you do when there are too many parallel editors of an article? When you're editing in a real-time collaborative editor, that means you see the edits of each of the participants, alongside their cursors/selections and comments in the chat system if there is one (which there normally is). When there's two or three of these, it's relatively easy to see what's happening. But what if there are 1,000 people trying to edit the article at once (e.g. the article of a very famous individual just after they've died unexpectedly; think Michael Jackson or Robin Williams). Showing 1,000 cursors at once isn't just unhelpful – the level of traffic would probably kill most users' browsers. Consequently, there needs to be a limit somehow on the number of participants; maybe call it 10. So, what happens when you click edit on an article where 10 people are already editing? * Do you just get told tough? * Does the least-recently active editor get kicked out so you can join? * Does this mean that all I need is 11 bots requesting to edit an article to DoS it? If you're a special user (e.g. a sysop), can you get into a collaborative edit even if it's at the limit? * If yes, doesn't this go against our values to place some editors above others? * If yes, do we just let
Re: [Wiki-research-l] Fwd: FW: What works for increasing editor engagement?
On 26 September 2014 11:43, Luca de Alfaro l...@dealfaro.com wrote: Saving drafts on the other hand could help avoid many conflicts on less-trafficked pages. Right now, on a page that is edited infrequently, this happens: - User A starts an edit - User A saves not to lose work, not quite done yet. Resumes the edit. - User B (typically an editor) sees the edit by A, and sets to work polishing it. Saves. - User A saves -- conflict The first edit by A woke up B, and led to the conflict. If we allowed saving drafts, the following would be more likely: - User A starts an edit - User A saves a draft, and continues the edit. - User A saves the edit. - User B (typically an editor) sees the edit by A, and sets to work polishing it. Saves. The conflict would occur only if A had second-thoughts about the edit and continues work after saving it, which might happen, but les frequently. Of course saving drafts is also cumbersome to implement at scale (how long would they persist? there would be clean up needed, etc; maybe they could persist for one week then be mailed back to the author and deleted?). Luca, Yes, I agree. We're planning to add a locally-stored drafts feature to VisualEditor, and hopefully we'll also find a way for that to work with WikiEditor, to have a way for people to pause mid-edit. However, storing these drafts on the server would pose some major legal issues that we are keen to avoid. J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Re: [Wiki-research-l] FW: What works for increasing editor engagement?
Hoi, Did you read this [1] the notion that bots are good for increasing the number of editors is contentious. However, numbers from the Swedish Wikipedia experience confirim exactly that bots are good. They not only increase the number of readers but also the number of editors.. BIG GRIN Thanks, GerardM [1] http://ultimategerardm.blogspot.nl/2014/09/wikipedia-to-bot-or-not-to-bot-ii.html On 26 September 2014 14:31, WereSpielChequers werespielchequ...@gmail.com wrote: Scott, That's why the rest of my email focussed on things that we could that would improve editor retention and which would be uncontentious, but also there is a third question, are people's assumptions re newbie behaviour true? This is where research would be useful. Where the problem lies in mutually contradictory assumptions about user behaviour then the best way to break the logjam is with research, now I'm confident that the research will support my assumptions, but if I am wrong then I'm prepared to back solutions that I have previously opposed. Regards Jonathan Cardy On 26 Sep 2014, at 09:56, Scott Hale computermacgy...@gmail.com wrote: On Fri, Sep 26, 2014 at 1:46 PM, WereSpielChequers werespielchequ...@gmail.com wrote: Attn Luca and Scott There are some things best avoided as going against community expectations. I would be happy to see flagged revisions deployed on the English Wikipedia but I'm well aware that there is a significant lobby against that of people who believe that it is important that your edit goes live immediately. And with the community somewhat burned by bad experiences with recent software changes now would be a bad time to suggest such a controversial change. Yes. Completely agree, and that was the exact point of my first email: On Fri, Sep 26, 2014 at 9:15 AM, Scott Hale computermacgy...@gmail.com wrote: And that is the fundamental flaw with this whole email thread. The question needing to be answered isn't what increases new user retention. The real question is what increases new user retention and is acceptable to the most active/helpful existing users. The second question is much harder than the first. ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
