Hi all,
I'm Rexford, and just posting here for the first time. Please inform if this place isn't the right area to suggest features. I was encouraged to request features here. Please correct me if I'm wrong.
Its about edit conflict on Wikipedia and other projects. It happens when I get into an article to edit, but before I could save, someone else goes into the article, edits and save. It happens to myself and many out there.
Sometimes many minutes work of changes can be lost.
The feature request is this: When a person starts editing an article, and another person tries to edit that same article, he or she gets a message on screen that the article is already engaged. This suggestion is similar to how WordPress informs the second person who tries to edit a page whiles someone else is already editing.
Its likely one wouldn't like to edit a page when he or she knows someone is in it editing. I think its much better that way than allowing multiple edits on the page but allowing one persons edit to go in per save.
Thanks.
rexford | google.com/+Nkansahrexford | sent from smartphone
that would be a hullarious feature! which is btw available in some other opensoure and proprietory wikis.
rupert Am 04.08.2014 11:47 schrieb "Nkansah Rexford" nkansahrexford@gmail.com:
Hi all,
I'm Rexford, and just posting here for the first time. Please inform if this place isn't the right area to suggest features. I was encouraged to request features here. Please correct me if I'm wrong.
Its about edit conflict on Wikipedia and other projects. It happens when I get into an article to edit, but before I could save, someone else goes into the article, edits and save. It happens to myself and many out there.
Sometimes many minutes work of changes can be lost.
The feature request is this: When a person starts editing an article, and another person tries to edit that same article, he or she gets a message on screen that the article is already engaged. This suggestion is similar to how WordPress informs the second person who tries to edit a page whiles someone else is already editing.
Its likely one wouldn't like to edit a page when he or she knows someone is in it editing. I think its much better that way than allowing multiple edits on the page but allowing one persons edit to go in per save.
Thanks.
rexford | google.com/+Nkansahrexford | sent from smartphone _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi Rexford,
This is one of many places where feature requests can be made. Thanks for your interest.
The last I heard is that tools are in development that will make it easier to edit content simultaneously. I am asking Quim to provide us an update.
Pine
On Mon, Aug 4, 2014 at 10:02 AM, rupert THURNER rupert.thurner@gmail.com wrote:
that would be a hullarious feature! which is btw available in some other opensoure and proprietory wikis.
rupert Am 04.08.2014 11:47 schrieb "Nkansah Rexford" nkansahrexford@gmail.com:
Hi all,
I'm Rexford, and just posting here for the first time. Please inform if this place isn't the right area to suggest features. I was encouraged to request features here. Please correct me if I'm wrong.
Its about edit conflict on Wikipedia and other projects. It happens when
I
get into an article to edit, but before I could save, someone else goes into the article, edits and save. It happens to myself and many out
there.
Sometimes many minutes work of changes can be lost.
The feature request is this: When a person starts editing an article, and another person tries to edit that same article, he or she gets a message
on
screen that the article is already engaged. This suggestion is similar to how WordPress informs the second person who tries to edit a page whiles someone else is already editing.
Its likely one wouldn't like to edit a page when he or she knows someone
is
in it editing. I think its much better that way than allowing multiple edits on the page but allowing one persons edit to go in per save.
Thanks.
rexford | google.com/+Nkansahrexford | sent from smartphone _______________________________________________ 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
On Mon, Aug 4, 2014 at 9:50 PM, Pine W wiki.pine@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.thurner@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.
There was some idea to add to VisualEditor Etherpad-like concurrent and real-time editing, but maybe JamesF or marktraceur know better the current status.
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.
Just my 2 cents not even being an expert in this topic.
Thanks for the update Quim. I hope it gets done as soon as possible, as it'll go a long way to help multiple concurrent edits.
I think it's been lacking for a long time now, and can't wait to see it in action.
+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/
On Tue, Aug 5, 2014 at 10:38 PM, Quim Gil qgil@wikimedia.org wrote:
On Mon, Aug 4, 2014 at 9:50 PM, Pine W wiki.pine@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.thurner@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.
There was some idea to add to VisualEditor Etherpad-like concurrent and real-time editing, but maybe JamesF or marktraceur know better the current status.
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.
Just my 2 cents not even being an expert in this topic. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Aug 5, 2014 11:25 PM, "Nkansah Rexford" nkansahrexford@gmail.com wrote:
Thanks for the update Quim. I hope it gets done as soon as possible, as it'll go a long way to help multiple concurrent edits.
I think it's been lacking for a long time now, and can't wait to see it in action.
I think some test cases are in order.
The UI isn't perfect (you could even say confusing if you're not familiar with it) but IME (in my experience) edits are not lost. The conflict is either resolved automatically (so both are saved, not one clobbers the other *OR* it can't be resolved automatically and the 2 versions (current revision and what you just saved) are both sent back to the user for manual intervention. You can then diff ("show changes"), etc.
-Jeremy
On Tue, Aug 5, 2014 at 10:38 PM, Quim Gil qgil@wikimedia.org wrote:
On Mon, Aug 4, 2014 at 9:50 PM, Pine W wiki.pine@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.thurner@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
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 qgil@wikimedia.org wrote:
On Mon, Aug 4, 2014 at 9:50 PM, Pine W wiki.pine@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.thurner@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 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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.pine@gmail.com javascript:_e(%7B%7D,'cvml','wiki.pine@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 <qgil@wikimedia.org javascript:_e(%7B%7D,'cvml','qgil@wikimedia.org');> wrote:
On Mon, Aug 4, 2014 at 9:50 PM, Pine W <wiki.pine@gmail.com
javascript:_e(%7B%7D,'cvml','wiki.pine@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.thurner@gmail.com javascript:_e(%7B%7D,'cvml','rupert.thurner@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
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" nkansahrexford@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.pine@gmail.com javascript:_e(%7B%7D,'cvml','wiki.pine@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 <qgil@wikimedia.org javascript:_e(%7B%7D,'cvml','qgil@wikimedia.org');> wrote:
On Mon, Aug 4, 2014 at 9:50 PM, Pine W <wiki.pine@gmail.com
javascript:_e(%7B%7D,'cvml','wiki.pine@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.thurner@gmail.com javascript:_e(%7B%7D,'cvml','rupert.thurner@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
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" bawolff@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" nkansahrexford@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.pine@gmail.com javascript:_e(%7B%7D,'cvml','wiki.pine@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 <qgil@wikimedia.org javascript:_e(%7B%7D,'cvml','qgil@wikimedia.org');> wrote:
On Mon, Aug 4, 2014 at 9:50 PM, Pine W <wiki.pine@gmail.com
javascript:_e(%7B%7D,'cvml','wiki.pine@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.thurner@gmail.com javascript:_e(%7B%7D,'cvml','rupert.thurner@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
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" bawolff@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" nkansahrexford@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.pine@gmail.com javascript:_e(%7B%7D,'cvml','wiki.pine@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 <qgil@wikimedia.org javascript:_e(%7B%7D,'cvml','qgil@wikimedia.org');> wrote:
On Mon, Aug 4, 2014 at 9:50 PM, Pine W <wiki.pine@gmail.com
javascript:_e(%7B%7D,'cvml','wiki.pine@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.thurner@gmail.com javascript:_e(%7B%7D,'cvml','rupert.thurner@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
It might be worth asking the Editing team if improving the handling of edit conflicts is something that they have on their agenda or if they can add it next to their agenda for the next FY, or if this project would be a good GSOC/OPW project. James, can you comment? I know you're busy with VE and I'm not sure what your capacity and priorities are outside of VE.
Thanks! Pine
The real-time collaboration mock ups that Pau created and we presented at Wikimania have a feature which is similar, where you can see who else is currently editing a given page (and be notified when another edit starts) even if you don't choose to start/join a collaborative editing session.
But even if/when that work is implemented, I think there are better ways to handle merging edit conflicts.
The VE model does actually help here some -- the patches I've been working on for VE real-time collaborative editing do provide a way to "transpose" actions w/r/t each other, which allows you to merge two edit histories in some cases. Possibly an early use of this feature might be to allow VE to provide a nicer edit conflict resolution screen, with the option to automatically merge your edits in certain cases. --scott
On 9 November 2014 01:10, Pine W wiki.pine@gmail.com wrote:
It might be worth asking the Editing team if improving the handling of edit conflicts is something that they have on their agenda or if they can add it next to their agenda for the next FY, or if this project would be a good GSOC/OPW project. James, can you comment? I know you're busy with VE and I'm not sure what your capacity and priorities are outside of VE.
I've mostly answered this in subsequent e-mails, but for clarity, yes, I'm responsible for all editing tools, including the edit conflict resolution process, but we don't have any particular roadmap of improvements in this area. In general, areas with lots of problems and no solutions or guidance are very poor places to push GSoC/OPW projects, and this is definitely one of those IMO.
J.
What's the point in being (allegedly) "responsible" of something you can't influence?
Nemo
On 13 November 2014 06:40, Federico Leva (Nemo) nemowiki@gmail.com wrote:
What's the point in being (allegedly) "responsible" of something you can't influence?
Hey Nemo,
Unfortunately you've accidentally cropped off all the context of whoever's e-mails to which you were responding. What were you trying to say?
J.
I have just lost *two hours* of work due to an edit conflict. I thought using my browser's back button would fix it, but the text is gone forever. Argh.
Pine
*This is an Encyclopedia* https://www.wikipedia.org/
*One gateway to the wide garden of knowledge, where lies The deep rock of our past, in which we must delve The well of our future,The clear water we must leave untainted for those who come after us,The fertile earth, in which truth may grow in bright places, tended by many hands,And the broad fall of sunshine, warming our first steps toward knowing how much we do not know.*
*—Catherine Munro*
On Thu, Nov 13, 2014 at 3:40 AM, James Forrester jforrester@wikimedia.org wrote:
On 13 November 2014 06:40, Federico Leva (Nemo) nemowiki@gmail.com wrote:
What's the point in being (allegedly) "responsible" of something you
can't
influence?
Hey Nemo,
Unfortunately you've accidentally cropped off all the context of whoever's e-mails to which you were responding. What were you trying to say?
J.
James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Please endure. That's the way forward now.
For now, technically, there's no known or brought-forth solution, I'll recommend you endure.
I'm sorry, but that's the reality many people face. On Nov 16, 2014 10:07 PM, "Pine W" wiki.pine@gmail.com wrote:
I have just lost *two hours* of work due to an edit conflict. I thought using my browser's back button would fix it, but the text is gone forever. Argh.
Pine
*This is an Encyclopedia* https://www.wikipedia.org/
*One gateway to the wide garden of knowledge, where lies The deep rock of our past, in which we must delve The well of our future,The clear water we must leave untainted for those who come after us,The fertile earth, in which truth may grow in bright places, tended by many hands,And the broad fall of sunshine, warming our first steps toward knowing how much we do not know.*
*--Catherine Munro*
On Thu, Nov 13, 2014 at 3:40 AM, James Forrester <jforrester@wikimedia.org
wrote:
On 13 November 2014 06:40, Federico Leva (Nemo) nemowiki@gmail.com wrote:
What's the point in being (allegedly) "responsible" of something you
can't
influence?
Hey Nemo,
Unfortunately you've accidentally cropped off all the context of
whoever's
e-mails to which you were responding. What were you trying to say?
J.
James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester _______________________________________________ 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
Doesn't edit conflict show your content at the bottom of the edit conflict page? A bit unintuitive, but should be there.
On Mon, 17 Nov 2014, at 09:07, Pine W wrote:
I have just lost *two hours* of work due to an edit conflict. I thought using my browser's back button would fix it, but the text is gone forever. Argh.
Svetlana: having accidentally tested this "feature" again, yes. I was looking in the wrong place for my text, and I copied the wrong portion of text in my haste to save it. The text is now permanently gone. Judging by the number of times that I hear about edit conflicts, I have plenty of company with encountering this scenario.
James: would it be possible to automatically save the text of a page to a user's sandbox when they encounter an edit conflict? This would overwrite the content of the sandbox, but that could be reverted using the normal history page for the sandbox.
Pine
*This is an Encyclopedia* https://www.wikipedia.org/
*One gateway to the wide garden of knowledge, where lies The deep rock of our past, in which we must delve The well of our future,The clear water we must leave untainted for those who come after us,The fertile earth, in which truth may grow in bright places, tended by many hands,And the broad fall of sunshine, warming our first steps toward knowing how much we do not know.*
*—Catherine Munro*
On Sun, Nov 16, 2014 at 2:10 PM, svetlana svetlana@fastmail.com.au wrote:
Doesn't edit conflict show your content at the bottom of the edit conflict page? A bit unintuitive, but should be there.
On Mon, 17 Nov 2014, at 09:07, Pine W wrote:
I have just lost *two hours* of work due to an edit conflict. I thought using my browser's back button would fix it, but the text is gone
forever.
Argh.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 16 November 2014 22:36, Pine W wiki.pine@gmail.com wrote:
James: would it be possible to automatically save the text of a page to a user's sandbox when they encounter an edit conflict? This would overwrite the content of the sandbox, but that could be reverted using the normal history page for the sandbox.
+1 to something that achieves this effect. (Dataloss = major high-priority bug.)
- d.
It sounds like the data loss here was purely due to user error, David.
Also, Pine, users do not have a 'sandbox' as far as the software is aware. Maybe we could allow saving things to a given subpage of their user page though. I wonder if there would be issues with this idea due to missing history/attribution/etc....
On 16 November 2014 22:41, David Gerard dgerard@gmail.com wrote:
On 16 November 2014 22:36, Pine W wiki.pine@gmail.com wrote:
James: would it be possible to automatically save the text of a page to a user's sandbox when they encounter an edit conflict? This would overwrite the content of the sandbox, but that could be reverted using the normal history page for the sandbox.
+1 to something that achieves this effect. (Dataloss = major high-priority bug.)
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sun, Nov 16, 2014 at 5:53 PM, Alex Monk krenair@gmail.com wrote:
It sounds like the data loss here was purely due to user error, David.
Don't blame the victim.
Maybe we could allow saving things to a given subpage of their user page
Users/{name}/backup/{pagetitle}/{serial number} ? That gets rid of the "wipes out what was there already" problem.
zw
On 16 November 2014 22:58, Zack Weinberg zackw@cmu.edu wrote:
On Sun, Nov 16, 2014 at 5:53 PM, Alex Monk krenair@gmail.com wrote:
It sounds like the data loss here was purely due to user error, David.
Don't blame the victim.
+1. This is precisely the dataloss that needs to be averted.
Maybe we could allow saving things to a given subpage of their user page
Users/{name}/backup/{pagetitle}/{serial number} ? That gets rid of the "wipes out what was there already" problem.
Something like that.
- d.
* Zack Weinberg wrote:
On Sun, Nov 16, 2014 at 5:53 PM, Alex Monk krenair@gmail.com wrote:
It sounds like the data loss here was purely due to user error, David.
Don't blame the victim.
Maybe we could allow saving things to a given subpage of their user page
Users/{name}/backup/{pagetitle}/{serial number} ? That gets rid of the "wipes out what was there already" problem.
I would rather expect an "autosave" feature to use some local storage mechanisms (to keep incomplete edits confidential and to deal with e.g. connectivity problems). Making the recovery process discoverable is a bit difficult, but in any case, wikispace is not a good place to save such content, even if it's done only for edit conflicts for edits that have been submitted.
On Thu, 20 Nov 2014, at 10:22, Bjoern Hoehrmann wrote:
- Zack Weinberg wrote:
On Sun, Nov 16, 2014 at 5:53 PM, Alex Monk krenair@gmail.com wrote:
It sounds like the data loss here was purely due to user error, David.
Don't blame the victim.
Maybe we could allow saving things to a given subpage of their user page
Users/{name}/backup/{pagetitle}/{serial number} ? That gets rid of the "wipes out what was there already" problem.
I would rather expect an "autosave" feature to use some local storage mechanisms
+1 for that. Unfortunately local storage in modern web browsers behaves unreliably. Yet instead of acknowledging that improvement and standardizing of the local storage is long overdue, people develop "native" mobile apps. In my view your post shows where this approach hits a ceiling (as most desktop users don't have a "easily install an app" culture or even a package manager, such as the popular windows platform).
-- Svetlana
Well, judging by the number of occurrences of data loss with edit conflicts and the ease of losing data due to edit conflicts, I would say this is a design problem at least as much as user error. If I get tripped up by this, imagine the number of new users who get confused and give up. If this had been my first experience as an editor, you'd never hear from me again, even more so if I was told that the data loss was my fault. How would you feel if someone told you that after you volunteered two hours of your time and had all your work disappear that it was your fault?
One way to handle the attribution issue with saving a copy of the work in user space is to link to the source article in the edit summary.
Zack's suggestion would be ok. It would be important that the draft is publicly visible in user space.
Pine
*This is an Encyclopedia* https://www.wikipedia.org/
*One gateway to the wide garden of knowledge, where lies The deep rock of our past, in which we must delve The well of our future,The clear water we must leave untainted for those who come after us,The fertile earth, in which truth may grow in bright places, tended by many hands,And the broad fall of sunshine, warming our first steps toward knowing how much we do not know.*
*—Catherine Munro*
On Sun, Nov 16, 2014 at 2:53 PM, Alex Monk krenair@gmail.com wrote:
It sounds like the data loss here was purely due to user error, David.
Also, Pine, users do not have a 'sandbox' as far as the software is aware. Maybe we could allow saving things to a given subpage of their user page though. I wonder if there would be issues with this idea due to missing history/attribution/etc....
On 16 November 2014 22:41, David Gerard dgerard@gmail.com wrote:
On 16 November 2014 22:36, Pine W wiki.pine@gmail.com wrote:
James: would it be possible to automatically save the text of a page
to a
user's sandbox when they encounter an edit conflict? This would
overwrite
the content of the sandbox, but that could be reverted using the normal history page for the sandbox.
+1 to something that achieves this effect. (Dataloss = major
high-priority
bug.)
- d.
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
On 16 November 2014 22:36, Pine W wiki.pine@gmail.com wrote:
I was looking in the wrong place for my text, and I copied the wrong portion of text in my haste to save it. The text is now permanently gone.
On 16 November 2014 22:58, Zack Weinberg zackw@cmu.edu wrote:
On Sun, Nov 16, 2014 at 5:53 PM, Alex Monk krenair@gmail.com wrote:
It sounds like the data loss here was purely due to user error, David.
Don't blame the victim.
What is this nonsense? It was clearly user error, not the fault of the software.
On 16 November 2014 23:03, Pine W wiki.pine@gmail.com wrote:
How would you feel if someone told you that after you volunteered two hours
of your time and had all your work disappear that it was your fault?
Well to be honest I'd think of myself as pretty stupid for leaving two hours worth of work without saving it anywhere safe, but at least I would be able to see that it was my own fault and that the software had returned everything that was needed, making it just a user experience issue rather than a data-loss-major-high-priority bug.
At least we agree that there is a design problem here.
I think blaming users/customers tends to cause unnecessary drama and drive people away. Yes, I should have read the prompts more carefully and checked that I was copying offline what I thought I was copying, which was the wrong version. However, my position is that a user shouldn't be placed in this position in the first instance.
In any case, perhaps we can return to the subject of how to create a better, friendly, more fault-tolerant user experience.
Pine
Pine
*This is an Encyclopedia* https://www.wikipedia.org/
*One gateway to the wide garden of knowledge, where lies The deep rock of our past, in which we must delve The well of our future,The clear water we must leave untainted for those who come after us,The fertile earth, in which truth may grow in bright places, tended by many hands,And the broad fall of sunshine, warming our first steps toward knowing how much we do not know.*
*—Catherine Munro*
On Sun, Nov 16, 2014 at 3:22 PM, Alex Monk krenair@gmail.com wrote:
On 16 November 2014 22:36, Pine W wiki.pine@gmail.com wrote:
I was looking in the wrong place for my text, and I copied the wrong portion of text in my haste to save it. The text is now permanently gone.
On 16 November 2014 22:58, Zack Weinberg zackw@cmu.edu wrote:
On Sun, Nov 16, 2014 at 5:53 PM, Alex Monk krenair@gmail.com wrote:
It sounds like the data loss here was purely due to user error, David.
Don't blame the victim.
What is this nonsense? It was clearly user error, not the fault of the software.
On 16 November 2014 23:03, Pine W wiki.pine@gmail.com wrote:
How would you feel if someone told you that after you volunteered two hours
of your time and had all your work disappear that it was your fault?
Well to be honest I'd think of myself as pretty stupid for leaving two hours worth of work without saving it anywhere safe, but at least I would be able to see that it was my own fault and that the software had returned everything that was needed, making it just a user experience issue rather than a data-loss-major-high-priority bug. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On the second edit conflict, I read the message at the page top. It says:
Someone else has changed this page since you started editing it. The upper text area contains the page text as it currently exists. **Your changes are shown in the lower text area.** You will have to merge your changes into the existing text. Only the text in the upper text area will be saved when you press "Save page".
Emphasis added by me. We all know that people fail to read though. If we can come up with a more colorful error message or a more intuitive edit conflict page layout, I'm all ears.
As to (semi-automatic) conflict resolution, our diff viewer probably has to be fixed first - any conflict resolution starts with identifying the differences, and our diff viewer fucks up at smallest possible edits or problems as soon as an extra line break is involved, i.e. https://test.wikipedia.org/w/index.php?title=User%3AGryllida&action=hist... (Were the first sentence edit and second sentence edits made separately, and with a conflict, the logic would die (esp. with an extra line break change involved inbetween)).
On Mon, 17 Nov 2014, at 09:36, Pine W wrote:
Svetlana: having accidentally tested this "feature" again, yes. I was looking in the wrong place for my text, and I copied the wrong portion of text in my haste to save it. The text is now permanently gone. Judging by the number of times that I hear about edit conflicts, I have plenty of company with encountering this scenario.
James: would it be possible to automatically save the text of a page to a user's sandbox when they encounter an edit conflict? This would overwrite the content of the sandbox, but that could be reverted using the normal history page for the sandbox.
Pine
*This is an Encyclopedia* https://www.wikipedia.org/
*One gateway to the wide garden of knowledge, where lies The deep rock of our past, in which we must delve The well of our future,The clear water we must leave untainted for those who come after us,The fertile earth, in which truth may grow in bright places, tended by many hands,And the broad fall of sunshine, warming our first steps toward knowing how much we do not know.*
*—Catherine Munro*
On Sun, Nov 16, 2014 at 2:10 PM, svetlana svetlana@fastmail.com.au wrote:
Doesn't edit conflict show your content at the bottom of the edit conflict page? A bit unintuitive, but should be there.
On Mon, 17 Nov 2014, at 09:07, Pine W wrote:
I have just lost *two hours* of work due to an edit conflict. I thought using my browser's back button would fix it, but the text is gone
forever.
Argh.
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
On Sun, Nov 16, 2014 at 7:27 PM, svetlana svetlana@fastmail.com.au wrote:
On the second edit conflict, I read the message at the page top. It says:
Someone else has changed this page since you started editing it. The upper text area contains the page text as it currently exists. **Your changes are shown in the lower text area.** You will have to merge your changes into the existing text. Only the text in the upper text area will be saved when you press "Save page".
Emphasis added by me. We all know that people fail to read though. If we can come up with a more colorful error message or a more intuitive edit conflict page layout, I'm all ears.
Perhaps we could look at desktop 3-way diff utilities for inspiration? Something like (pray forgive the ASCII art...)
EDIT CONFLICT
YOUR VERSION OTHER VERSION +-------------+ +-------------+ | (read only | | (read only | | text area) | | text area) | | (background | | (background | | greenish) | | yellowish) | +-------------+ +-------------+
Please merge the two versions into the text area below. +------------------------------+ | (editable text area) | | (background white) | | (prefilled with the best | | 3-way merge we can manage) | +------------------------------+
I have to say I don't understand why the system does such a terrible job -- 3-way merge is a Solved Problem over in the land of version control systems for programmers.
zw
On 16 November 2014 16:27, svetlana svetlana@fastmail.com.au wrote:
On the second edit conflict, I read the message at the page top. It says:
Someone else has changed this page since you started editing it. The upper text area contains the page text as it currently exists. **Your changes are shown in the lower text area.** You will have to merge your changes into the existing text. Only the text in the upper text area will be saved when you press "Save page".
Emphasis added by me. We all know that people fail to read though. If we can come up with a more colorful error message or a more intuitive edit conflict page layout, I'm all ears.
However, any "colourful" message will likely get ignored more, not seen more – a problem which is exacerbated by wikis modifying many of the most common messages to be colourful. See https://en.wikipedia.org/wiki/Banner_blindness for more.
As to (semi-automatic) conflict resolution, our diff viewer probably has to be fixed first - any conflict resolution starts with identifying the differences, and our diff viewer fucks up at smallest possible edits or problems as soon as an extra line break is involved, i.e. https://test.wikipedia.org/w/index.php?title=User%3AGryllida&action=hist... (Were the first sentence edit and second sentence edits made separately, and with a conflict, the logic would die (esp. with an extra line break change involved inbetween)).
Moving to character-level rather than paragraph-level diffing might help here, potentially. I vaguely remember that we attempted that and abandoned it because it caused more issues than it solved back in ?2004, though.
J.
I think it would be ok to have a second "Save page" prompt that offers to save the page in a user's userspace.
The save location could be something like User:Jimbo\editconflicts\pagename
Auto-deletion of the edit conflict save would not be necessary.
I also like Zack's suggestion. I think that could work with differences highlighted between the two versions:
"EDIT CONFLICT. Another user has edited the page between the time that you started your edit and the time that you saved the page. But don't worry, you can reconcile the differences."
YOUR VERSION OTHER VERSION +-------------+ +-------------+ | (read only | | (read only | | text area) | | text area) | | (background | | (background | | greenish) | | yellowish) | +-------------+ +-------------+
"Please merge the two versions into the text area below and then press save." +----------------------------- -+ | (editable text area) | | (background white) | | (prefilled with the best | | 3-way merge we can manage) | +------------------------------+
Pine
On Mon, Nov 17, 2014 at 11:03 AM, James Forrester jforrester@wikimedia.org wrote:
Moving to character-level rather than paragraph-level diffing might help
here, potentially. I vaguely remember that we attempted that and abandoned
it because it caused more issues than it solved back in ?2004, though.
A paragraph-level diff means that you only get an edit conflict if two people change the same paragraph. A character-level diff would mean, then, that you only get a conflict if they change the same character? That sounds a bit excessive. (Stupid example: if I change "sixty-three" to "sixty-five" and someone else changes it to "seventy-three", that should probably be a conflict, but a character-level diff would happily merge them into "seventy-five".) A sentence-level diff would make much more sentence, except breaking text to sentences is a less trivial task than breaking it to paragraphs (lines). It is a very fundamental step in natural language processing though, so I am sure mature algorithms and tools exist for it, we just would have to research them.
Another low-hanging fruit would be to special-case the situation when editor A adds text to the end of a section but does not start a new section, while editor B adds a new section to the same place. This is currently a conflict as they both try to insert to the same "slot" between paragraphs, so a generic merge tool cannot figure out whether those additions conflict and what would be the right order if they don't; however, knowing the semantics of wikitext, inserting the text from A first and the one from B after that seems a pretty safe bet. This kind of conflict is very typical on talk pages where people almost always edit the end of a section, and the few "hot topic" sections get the majority of the edits. (Of course, using unstructured wikitext for talk pages is a bad thing in general, but that's a long-term problem, and this kind of edit conflict could be prevented quickly.)
On 20 November 2014 09:30, Gergo Tisza gtisza@wikimedia.org wrote:
On Mon, Nov 17, 2014 at 11:03 AM, James Forrester < jforrester@wikimedia.org> wrote:
Moving to character-level rather than paragraph-level diffing might
help
here, potentially. I vaguely remember that we attempted that and abandoned
it because it caused more issues than it solved back in ?2004, though.
A paragraph-level diff means that you only get an edit conflict if two people change the same paragraph. A character-level diff would mean, then, that you only get a conflict if they change the same character? That sounds a bit excessive. (Stupid example: if I change "sixty-three" to "sixty-five" and someone else changes it to "seventy-three", that should probably be a conflict, but a character-level diff would happily merge them into "seventy-five".)
Sure, but wikitext "paragraphs" are significantly more extensive and diverse than the NLP concept; to give an example:
Original wikitext:
There are six [[alpaca]] shearers on [[Sunningdale Acers|the farm]].
My changes:
There are six [[*Alpaca fiber|*alpaca]] shearers on [[Sunningdale Acr*e*s|the farm]].
Their changes:
There are six [[alpaca]] shearers on [[Sunningdale Acers|the farm*stead* ]].
Merging these two changes requires character-level merging (or something that natively understand wikitext at a subtle level. The first change would go through as a word-level diff (but not at sentence-level); the second wouldn't go through even then. Of course, we could prompt people to review the diff after saving if we're auto-merging, but that might be something we should be doing even now?
Another low-hanging fruit would be to special-case the situation when editor A adds text to the end of a section but does not start a new section, while editor B adds a new section to the same place. This is currently a conflict as they both try to insert to the same "slot" between paragraphs, so a generic merge tool cannot figure out whether those additions conflict and what would be the right order if they don't; however, knowing the semantics of wikitext, inserting the text from A first and the one from B after that seems a pretty safe bet. This kind of conflict is very typical on talk pages where people almost always edit the end of a section, and the few "hot topic" sections get the majority of the edits.
That seems like a sensible idea. Filed: https://bugzilla.wikimedia.org/show_bug.cgi?id=73667
(Of course, using unstructured wikitext for talk pages is a bad thing in general, but that's a long-term problem, and this kind of edit conflict could be prevented quickly.)
Indeed!
J.
On Thu, Nov 20, 2014 at 10:59 AM, James Forrester jforrester@wikimedia.org wrote:
A paragraph-level diff means that you only get an edit conflict if two people change the same paragraph. A character-level diff would mean,
then,
that you only get a conflict if they change the same character? That
sounds
a bit excessive. (Stupid example: if I change "sixty-three" to
"sixty-five"
and someone else changes it to "seventy-three", that should probably be a conflict, but a character-level diff would happily merge them into "seventy-five".)
Sure, but wikitext "paragraphs" are significantly more extensive and diverse than the NLP concept; to give an example:
Original wikitext:
There are six [[alpaca]] shearers on [[Sunningdale Acers|the farm]].
My changes:
There are six [[*Alpaca fiber|*alpaca]] shearers on [[Sunningdale Acr*e*s|the farm]].
Their changes:
There are six [[alpaca]] shearers on [[Sunningdale Acers|the farm*stead* ]].
Merging these two changes requires character-level merging (or something that natively understand wikitext at a subtle level. The first change would go through as a word-level diff (but not at sentence-level); the second wouldn't go through even then. Of course, we could prompt people to review the diff after saving if we're auto-merging, but that might be something we should be doing even now?
I don't think this is particularly unique to wikitext, but sure, a character-level (or even word-level) diff would often bring better results than the current algorithm. My point is that paragraph-based (and maybe even sentence-based) diffing makes unwanted results rare enough that it can just be applied without any oversight from the user, while the same definitely would not be true of the finer-grained algorithms. They could be applied with some sort of user review, or 3-way merge interface, and those would be cool features in general, but more complex than just tweaking the diff algorithm, I would think.
...which made me wonder: are we logging enough information of edit conflicts that we could just replay them with an alternative algorithm and see how well it performs? None of the EventLogging schemas which look relevant (Edit [1], EditConflict [2], EditDebugging [3]) seem to store the text which could not be saved, and while EditDebugging saves the ids for both old revisions for a successful automatic merge, I'm not sure if those can be connected with id of the new revision.
[1] https://meta.wikimedia.org/wiki/Schema:Edit [2] https://meta.wikimedia.org/wiki/Schema:EditConflict [3] https://meta.wikimedia.org/wiki/Schema:EditDebugging
On 16 November 2014 14:36, Pine W wiki.pine@gmail.com wrote:
James: would it be possible to automatically save the text of a page to a user's sandbox when they encounter an edit conflict? This would overwrite the content of the sandbox, but that could be reverted using the normal history page for the sandbox.
Hmm. Publishing content without the user clicking the "Save page" button a second time feels very icky. Also, would we need to go around and auto-delete these for users once the edit conflict was fixed? This doesn't sound like a perfect solution. There's also the issue with "the user's sandbox" not existing as an actual thing, just a hack that a couple of wikis have invented…
Maybe we should make the (read only) "your content" box more prominent, appearing before the "current content" one? Not sure this would help more than it would hinder everyone for the order to be reversed.
J.
On Mon, 17 Nov 2014 19:56:04 +0100, James Forrester jforrester@wikimedia.org wrote:
Maybe we should make the (read only) "your content" box more prominent, appearing before the "current content" one? Not sure this would help more than it would hinder everyone for the order to be reversed.
I've always thought that the reason for the current ordering is so that people don't blindly press "Save" again and undo others' changes.
On Mon, Nov 17, 2014 at 3:11 PM, Bartosz Dziewoński matma.rex@gmail.com wrote:
I've always thought that the reason for the current ordering is so that people don't blindly press "Save" again and undo others' changes.
Instead they blindly press "Save" again and lose their own changes. Arguably less bad but still bad.
Anyway, the proper solution for this problem is autosaving article drafts. IIRC the Drafts extension https://www.mediawiki.org/wiki/Extension:Drafts is basically ready but needs usability improvements, and development has stalled because when this was found out the Foundation did not have a user testing team yet; maybe James can tell if any further work is planned on that. As far as I can see, it would be the lowest hanging fruit by far WRT editing improvements for non-newbies.
On 20 November 2014 09:33, Gergo Tisza gtisza@wikimedia.org wrote:
Anyway, the proper solution for this problem is autosaving article drafts. IIRC the Drafts extension https://www.mediawiki.org/wiki/Extension:Drafts is basically ready but needs usability improvements, and development has stalled because when this was found out the Foundation did not have a user testing team yet; maybe James can tell if any further work is planned on that. As far as I can see, it would be the lowest hanging fruit by far WRT editing improvements for non-newbies.
No. The Drafts extension (and any feature that puts hidden content on the servers) was veto'ed years ago by Legal. We need to stop beating this dead horse.
J.
My wiki (zeldawiki.org) used to have such an extension to inform people when someone else was already editing the page. However, it was not compatible with newer versions of MediaWiki and was subsequently removed. I would like to voice my support for such features being integrated either into the MediaWiki core or into natively packaged extensions.
---- Justin Folvarcik
On Thu, Nov 20, 2014 at 2:00 PM, James Forrester jforrester@wikimedia.org wrote:
On 20 November 2014 09:33, Gergo Tisza gtisza@wikimedia.org wrote:
Anyway, the proper solution for this problem is autosaving article
drafts.
IIRC the Drafts extension <
https://www.mediawiki.org/wiki/Extension:Drafts%3E
is basically ready but needs usability improvements, and development has stalled because when this was found out the Foundation did not have a
user
testing team yet; maybe James can tell if any further work is planned on that. As far as I can see, it would be the lowest hanging fruit by far
WRT
editing improvements for non-newbies.
No. The Drafts extension (and any feature that puts hidden content on the servers) was veto'ed years ago by Legal. We need to stop beating this dead horse.
J.
James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Nov 20, 2014 at 11:00 AM, James Forrester jforrester@wikimedia.org wrote:
No. The Drafts extension (and any feature that puts hidden content on the servers) was veto'ed years ago by Legal. We need to stop beating this dead horse.
If that is the case, it should be expressed more clearly at T39992 https://phabricator.wikimedia.org/T39992 which right now has some legal arguments (not very convincing ones, in my opinion, but I'll expand on that there), but no mention of any authoritative legal evaluation, and on the whole the discussion is centered on usability.
Anyway, this doesn't really answer the question - whether drafts are stored locally or on the server is an implementation detail (a major one, but still). Is a localstorage-based draft feature on the roadmap, then?
No. The Drafts extension (and any feature that puts hidden content on the servers) was veto'ed years ago by Legal. We need to stop beating this dead horse.
J.
Err, what? Quick don't tell legal about Special:UploadStash, or the "userjs-" options api.
------
As a quick hack I made a little user script that can do auto-merging of edit conflicts. It adds a button to the edit conflict page to auto-merge the conflict.
To try it, add the following to [[Special:MyPage/common.js]] or [[meta:Special:Mypage/global.js]]:
importScriptURI('https://meta.wikimedia.org/w/index.php?title=User:Bawolff/EditConflictAutoMe...');
The script is extremely basic and rather "unpolished". I'd be interested to hear if even something as basic as this is useful to users. Remember if you try and test an edit conflict, you cannot conflict with yourself, so when testing edit conflicts you need to use a different user (or an anon) to conflict with you.
--bawolff
James Forrester wrote:
No. The Drafts extension (and any feature that puts hidden content on the servers) was veto'ed years ago by Legal. We need to stop beating this dead horse.
I seem to remember you making a number of claims about the use of drafts by terrorists and child pornographers and other evildoers, but I don't know what veto you're referring to. Do you have a link to a mailing list post or a blog post or another source to verify the claim you're making?
MZMcBride
On Mon, Nov 17, 2014 at 1:56 PM, James Forrester jforrester@wikimedia.org wrote:
On 16 November 2014 14:36, Pine W wiki.pine@gmail.com wrote:
James: would it be possible to automatically save the text of a page to a user's sandbox when they encounter an edit conflict? This would overwrite the content of the sandbox, but that could be reverted using the normal history page for the sandbox.
Hmm. Publishing content without the user clicking the "Save page" button a second time feels very icky. Also, would we need to go around and auto-delete these for users once the edit conflict was fixed? This doesn't sound like a perfect solution. There's also the issue with "the user's sandbox" not existing as an actual thing, just a hack that a couple of wikis have invented…
Maybe we should make the (read only) "your content" box more prominent, appearing before the "current content" one? Not sure this would help more than it would hinder everyone for the order to be reversed.
J.
Why not just interleave or nest the conflicted edit in the history of the page? So if you are editing revision 1, and conflict with someone elses revision 2, save your revision as 2 and the next person's revision as 3? There's some ugliness in the revision history to resolve (like timestamps), and potentially other ways it could be done, but I see no reason not to slot the conflicted edit into the history while prompting the user to merge into a current revision.
On Wed Nov 19 2014 at 3:50:02 PM Nathan nawrich@gmail.com wrote:
Why not just interleave or nest the conflicted edit in the history of the page? So if you are editing revision 1, and conflict with someone elses revision 2, save your revision as 2 and the next person's revision as 3? There's some ugliness in the revision history to resolve (like timestamps), and potentially other ways it could be done, but I see no reason not to slot the conflicted edit into the history while prompting the user to merge into a current revision.
Except since rev_id auto-increments you'd end up with an out-of-place rev_id in the history. In your example you'd end up with something like:
[[Page]] history: - Latest rev by Joe (rev_id 2) - Previous rev by Jane (rev_id 3) <- This was the edit conflict, inserted after the fact - First rev by Jim (rev_id 1) <- This one was the one Jane and Joe both began editing from
-Chad
On 8 November 2014 22:12, Nkansah Rexford nkansahrexford@gmail.com wrote:
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.
It's been suggested before and discarded for the reason I gave; this isn't lacking progress because of a lack of will, but a lack of easy ideas that can work well.
J.
On 8 November 2014 22:01, Brian Wolff bawolff@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).
Yes, though this is normally triggered because the section isn't called what it used to be; if you're appending a new section to the end of the page I think it works fine.
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.
The normal way to solve this UX problem is "three column diff", but that (a) isn't remotely good for mobile interfaces, and (b) adds Yet Another Interface which may confuse as much as it assists. We'd need a lot of painful UX research and a huge amount of developer time here, I feel.
*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.
This doesn't work for languages without word/sentence/paragraph separators, of course, but has some promise.
There are probably some other improvements we should think about, but this is a good start. Note that the behaviour for IP editors is probably worse, given the special code paths used for logged-in editors (the "you can't conflict with yourself" branch) that aren't open to IPs.
J.
On Nov 12, 2014 9:44 AM, "James Forrester" jforrester@wikimedia.org wrote:
On 8 November 2014 22:01, Brian Wolff bawolff@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).
Yes, though this is normally triggered because the section isn't called what it used to be; if you're appending a new section to the end of the page I think it works fine.
I think there is some cases where if someone adds a new section while you are editing the last line of the previously last section, it will conflict. I guess more research is needed to even enumerate all the common edit conflicts.
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.
The normal way to solve this UX problem is "three column diff", but that (a) isn't remotely good for mobile interfaces, and (b) adds Yet Another Interface which may confuse as much as it assists. We'd need a lot of painful UX research and a huge amount of developer time here, I feel.
I think you're right if we really want to do it well. But this might be one of those cases where we can make it suck much less without quite making it "good", which might be worthwhile in this case. Maybe.
--bawolff
On 12 November 2014 14:46, Brian Wolff bawolff@gmail.com wrote:
On Nov 12, 2014 9:44 AM, "James Forrester" jforrester@wikimedia.org wrote:
On 8 November 2014 22:01, Brian Wolff bawolff@gmail.com wrote:
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.
The normal way to solve this UX problem is "three column diff", but
that
(a) isn't remotely good for mobile interfaces, and (b) adds Yet Another Interface which may confuse as much as it assists. We'd need a lot of painful UX research and a huge amount of developer time here, I feel.
I think you're right if we really want to do it well. But this might be one of those cases where we can make it suck much less without quite making it "good", which might be worthwhile in this case. Maybe.
Oh, sure. I'm not totally convinced that we'll be able to help with HTML/DOM diffing, but that's planned at some point in the future and should at least provide a much better experience for non-wikitext users in navigating changes to documents. It's possible that it will provide a "simple" UX for edit conflicts as well, I suppose.
J.
On 8 November 2014 20:31, Nkansah Rexford nkansahrexford@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 think that that's a fair assessment. Doing real-time collaborative editing is a quite hard engineering challenge, but it's a much bigger issue for how our users would be affected, and working out some pretty fundamental ways in which MediaWiki would need to change. See https://lists.wikimedia.org/pipermail/wiki-research-l/2014-September/003828.... which I wrote a couple of months ago which outlines some of these issues.
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.
It's a superficially attractive option that goes completely against the Wikimedia ethos, though. Allowing users to lock pages so that only they can edit them is anti-wiki. It works for WordPress because that's a totally different product; altering this model would massively change the way that people interact with wikis, and I'm not sure it's a reasonable change to make.
There are some useful points we're going to reach along the path to proper real-time collaboration, however, which might be better things on which to focus – flagging pages currently being edited, DOM diff-based edit merges and so on.
J.
Indeed Forester, your answer on the wiki research list is outstanding and shines light on what collaborative editing entails. I really appreciate pointing those issues out, and I fully agree.
You ended by saying
The short answer is that it's a really interesting area of possibilities, but we're going to want to work through a lot of these issues and come up with an actual proposal about what this would mean.
My question is, is there currently a proposal to handle the issue of Edit Conflicts for the mean time, before the holy grail wikipedia collaborative editing concept presented at wikimania is realized?
Or, we all, new editors and old editors alike, continue to endure, most times, the annoyance that comes with editing conflicts?
Has that actual proposal started?
I fully agree its a daunting challenge with the realtime editing thing, but before that is achieved (perhaps maybe next 10 years time), I believe there should be a quick 'hack' to that.
Can't wait to learn what the proposal finally is. As you explained, I don't think the locking articles like wordpress does will be much sensible in this wikipedia context.
thanks for your explanations
On Wednesday, November 12, 2014, James Forrester jforrester@wikimedia.org wrote:
On 8 November 2014 20:31, Nkansah Rexford nkansahrexford@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 think that that's a fair assessment. Doing real-time collaborative editing is a quite hard engineering challenge, but it's a much bigger issue for how our users would be affected, and working out some pretty fundamental ways in which MediaWiki would need to change. See
https://lists.wikimedia.org/pipermail/wiki-research-l/2014-September/003828.... which I wrote a couple of months ago which outlines some of these issues.
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.
It's a superficially attractive option that goes completely against the Wikimedia ethos, though. Allowing users to lock pages so that only they can edit them is anti-wiki. It works for WordPress because that's a totally different product; altering this model would massively change the way that people interact with wikis, and I'm not sure it's a reasonable change to make.
There are some useful points we're going to reach along the path to proper real-time collaboration, however, which might be better things on which to focus - flagging pages currently being edited, DOM diff-based edit merges and so on.
J.
James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 12 November 2014 14:26, Nkansah Rexford nkansahrexford@gmail.com wrote:
Indeed Forester, your answer on the wiki research list is outstanding and shines light on what collaborative editing entails. I really appreciate pointing those issues out, and I fully agree.
You ended by saying
The short answer is that it's a really interesting area of possibilities, but we're going to want to work through a lot of these issues and come up with an actual proposal about what this would mean.
My question is, is there currently a proposal to handle the issue of Edit Conflicts for the mean time, before the holy grail wikipedia collaborative editing concept presented at wikimania is realized?
No.
Or, we all, new editors and old editors alike, continue to endure, most times, the annoyance that comes with editing conflicts?
I don't see this as an either/or issue; if someone can suggest some improvements in this area, we could experiment with them well ahead of anything on real-time collaboration.
Has that actual proposal started?
C. Scott's excellent code demonstrated at Wikimania "works", after a fashion, but doesn't tackle any of the MediaWiki issues, so… "no", ish.
I fully agree its a daunting challenge with the realtime editing thing, but before that is achieved (perhaps maybe next 10 years time), I believe there should be a quick 'hack' to that.
I'm all ears for ideas. :-)
[Snip.]
J.
wikitech-l@lists.wikimedia.org