Looked for it and found this doc on it: http://codex.wordpress.org/Post_Locking
Your points are also valid, at least far better than the current diff system which isn't that easy to understand what is actually going on or whatnot. 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
