The fact that no one has even tried improving the conflict issue in simplest way possible for years now is even something a bit strange. On Nov 8, 2014 10:01 PM, "Brian Wolff" <bawo...@gmail.com> wrote:
> Honestly i dont think anyone's even tried to improve the conflict screen. > There's probably a lot of low hanging fruit on the usability of edit > conflicts which could be persued that have nothing to do with the hard, > real time editing solutions (as cool as those are). > > If someone is intrested in trying to improve edit conflicts, id reccomend > starting with: > *only showing relavent parts. If your conflict is in a section, and you > were doing a section edit, dont ask user to resolve entire page (this is > particularly painful on VP type pages). > Furthermore: find some way to present only the conflicted lines (ie what > conflict markers show in a source control system) in a user friendly way. > > *better conflict resolution algorithms. This would require experimentation, > but im sure there exists something better for merging natural language > documents than just shoving it to gnu diff3. Perhaps even just adding a > newline after every sentence (period) so that it merges on a more fine > grained level would be appropriate. I imagine there must be papers written > on this subject we could look to for advice. > > I'm unfamilar with what wordpress does for this. Do you have a link > describing its process? > > --bawolff > On Nov 8, 2014 4:31 PM, "Nkansah Rexford" <nkansahrexf...@gmail.com> > wrote: > > > > One session I really looked forward to at the Wikimania was the one on > > Visual Editor and the talk on RealTime Editing (the one presented by > Erik). > > Of course, I enjoyed, seeing some of the nice future goals of how > realtime > > editing could be possible, however with very strong huddles to overcome. > > > > One slide pointed out the number of edit conflicts that happened in the > > month of July only: > > https://plus.google.com/107174506890941499078/posts/NCPzu4G5cbP > > > > There were *120k edit conflicts of about 23k registered user accounts* > > (anonymous conflicts might be higher or around this same value, or even > > less) > > > > The proposals and design concepts of how the concurrent editing could be > on > > Wikimedia projects were/are nice to see, and very hi-tech. However, I > > considered these proposals and design concepts to be far fetched, at > least, > > at least, looking at how pressing the issue of edit conflicts are. > > > > I might be the only person that suffers from that problem, thus I ask > > about. The simple solution to edit conflict in my own opinion isn't that > > complex, as at least, there's a living example of how it could be. > > > > The WordPress* way of resolving edit conflicts, for me, at this point in > > time, will look more promising and do much better than the highly > advanced > > concepts that were presented, which are not even near to realization, at > > least for the next 5 years. > > > > Until those concepts presented are completed, how many more edit > conflicts > > should be suffered? Losing lots (or even a line of edit) of edits because > > of editing conflict isn't something to take easily, at least when one has > > limited time and resources, but voluntarily decided to add content to an > > article. > > > > rexford > > > > **I'm no wordpress dev, neither have I ever even done coding in php. I > > mention the wordpress here because, as someone who uses wordpress a lot, > > and have seen how its editing conflict has been, in a typical way, > > resolved, I find it impressive, and think Wikipedia of all websites, > should > > have implement that approach long time ago, if not just after wordpress > did > > it.* > > On Aug 9, 2014 11:58 AM, "Pine W" <wiki.p...@gmail.com > > <javascript:_e(%7B%7D,'cvml','wiki.p...@gmail.com');>> wrote: > > > > > Rexford, it happens that there are 2 Wikimania sessions about > concurrent > > > editing starting at 17:00 today in Auditorum I. > > > > > > Pine > > > On Tue, Aug 5, 2014 at 10:38 PM, Quim Gil <q...@wikimedia.org > > > <javascript:_e(%7B%7D,'cvml','q...@wikimedia.org');>> wrote: > > > > On Mon, Aug 4, 2014 at 9:50 PM, Pine W <wiki.p...@gmail.com > > > <javascript:_e(%7B%7D,'cvml','wiki.p...@gmail.com');>> wrote: > > > > > > > >> I am asking Quim to provide us an update. > > > >> > > > > > > > > Me? :) I'm just an editor who, like many of you, has suffered this > > > problem > > > > occasionally. > > > > > > > > On Mon, Aug 4, 2014 at 10:02 AM, rupert THURNER < > > > rupert.thur...@gmail.com > > > <javascript:_e(%7B%7D,'cvml','rupert.thur...@gmail.com');>> > > > >> wrote: > > > >> > > > >>> that would be a hullarious feature! which is btw available in some > > > other > > > >>> opensoure and proprietory wikis. > > > >>> > > > >> > > > > TWiki is an open source wiki and also has (had?) a concept of > blocking a > > > > page while someone else is editing. This feature might sound less > than > > > > ideal in the context of, say, Wikipedia when a new Pope is being > > > nominated, > > > > but I can see how many editors and MediaWiki adminis have missed such > > > > feature at some point. > > > > > > > > If I understood correctly, VisualEditor already represents an > improvement > > > > vs Wikitext because the chances of triggering conflicting edits are > > > > smaller, because of the way the actual content is modified and > updated in > > > > every edit. > > > > > > i'd have strong doubts here, from a technical standpoint :) > > > > > > > Rupert, in any case you see that the trend is going in the direction > of > > > > being more efficient handling concurrent edits. Blocking pages while > > > > another editor supposedly is working on them might work in e.g. > corporate > > > > wikis where most f the times the Edit link is clicked for a reason, > but > > > it > > > > could be potentially counterproductive in sites like Wikipedia. > > > > > > > > > > i can only 100% agree, quim, and i am glad you help clarifying the > > > feature request in this direction. the suggestion is "notify" or > > > "show", not "block". if a user presses edit, the page shows other > > > persons who pressed edit in the last, say 15 minutes, and did not save > > > yet. it sounds simple to implement, but big benefit, especially with > > > many users. an additional goodie could be to show it on the edit > > > window of other user as well, so she can quickly save. if a user > > > ignores the notification and is quicker in saving, we have the current > > > situation. additionally these "in work" templates would be made > > > superfluous in many cases. > > > > > > rupert > > > > > > _______________________________________________ > > > Wikitech-l mailing list > > > Wikitech-l@lists.wikimedia.org > > > <javascript:_e(%7B%7D,'cvml','Wikitech-l@lists.wikimedia.org');> > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > _______________________________________________ > > > Wikitech-l mailing list > > > Wikitech-l@lists.wikimedia.org > > > <javascript:_e(%7B%7D,'cvml','Wikitech-l@lists.wikimedia.org');> > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > > > > -- > > +Rexford <https://plus.google.com/+Nkansahrexford> | +CG Central > > < > https://plus.google.com/b/103109918657638322478/103109918657638322478/posts > > > | > > +233 266 811 165 l BFCT > > <http://www.blendernetwork.org/member/nkansah-rexford-nyarko/> > > _______________________________________________ > > Wikitech-l mailing list > > Wikitech-l@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
