Re: [Wikitech-l] Feature request.

[MZMcBride]

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



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Brian Wolff]

>
> ​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/EditConflictAutoMerge.js&action=raw&ctype=text/javascript');

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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Gergo Tisza]

On Thu, Nov 20, 2014 at 11:00 AM, 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.
>

If that is the case, it should be expressed more clearly at 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?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Gergo Tisza]

On Thu, Nov 20, 2014 at 10:59 AM, James Forrester 
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*
> ]].
>
>
>
> ​Merg​ing 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Justin Folvarcik]

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 
wrote:

> On 20 November 2014 09:33, Gergo Tisza  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.
> --
> James D. Forrester
> Product Manager, Editing
> Wikimedia Foundation, Inc.
>
> jforres...@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

Re: [Wikitech-l] Feature request.

[James Forrester]

On 20 November 2014 09:33, Gergo Tisza  wrote:

> Anyway, the proper solution for this problem is autosaving article drafts.
> IIRC the Drafts extension 
> 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.

jforres...@wikimedia.org | @jdforrester
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[James Forrester]

On 20 November 2014 09:30, Gergo Tisza  wrote:

> On Mon, Nov 17, 2014 at 11:03 AM, James Forrester <
> jforres...@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*
]].



​Merg​ing 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.
-- 
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Gergo Tisza]

On Mon, Nov 17, 2014 at 3:11 PM, Bartosz Dziewoński 
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  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.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Gergo Tisza]

On Mon, Nov 17, 2014 at 11:03 AM, James Forrester 
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.)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Chad]

On Wed Nov 19 2014 at 3:50:02 PM Nathan  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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Nathan]

On Mon, Nov 17, 2014 at 1:56 PM, James Forrester 
wrote:

> On 16 November 2014 14:36, Pine W  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.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[svetlana]

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  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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Bjoern Hoehrmann]

* Zack Weinberg wrote:
>On Sun, Nov 16, 2014 at 5:53 PM, Alex Monk  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.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/ 

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Bartosz Dziewoński]

On Mon, 17 Nov 2014 19:56:04 +0100, James Forrester  
 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.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Pine W]

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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[James Forrester]

On 16 November 2014 16:27, svetlana  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=historysubmit&diff=218760&oldid=218759
> (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.
-- 
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[James Forrester]

On 16 November 2014 14:36, Pine W  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.
-- 
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Zack Weinberg]

On Sun, Nov 16, 2014 at 7:27 PM, svetlana  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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[svetlana]

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=historysubmit&diff=218760&oldid=218759
 (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* 
> 
> 
> 
> 
> 
> 
> *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  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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[David Gerard]

On 16 November 2014 22:58, Zack Weinberg  wrote:
> On Sun, Nov 16, 2014 at 5:53 PM, Alex Monk  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.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Pine W]

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* 






*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  wrote:

> On 16 November 2014 22:36, Pine W  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  wrote:
>
> > On Sun, Nov 16, 2014 at 5:53 PM, Alex Monk  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  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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Alex Monk]

On 16 November 2014 22:36, Pine W  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  wrote:

> On Sun, Nov 16, 2014 at 5:53 PM, Alex Monk  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  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

Re: [Wikitech-l] Feature request.

[Pine W]

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* 






*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  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  wrote:
>
> > On 16 November 2014 22:36, Pine W  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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Zack Weinberg]

On Sun, Nov 16, 2014 at 5:53 PM, Alex Monk  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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Alex Monk]

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  wrote:

> On 16 November 2014 22:36, Pine W  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

Re: [Wikitech-l] Feature request.

[David Gerard]

On 16 November 2014 22:36, Pine W  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

Re: [Wikitech-l] Feature request.

[Pine W]

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* 






*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  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

Re: [Wikitech-l] Feature request.

[Nkansah Rexford]

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"  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* 
>
>
>
>
>
>
> *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  >
> wrote:
>
> > On 13 November 2014 06:40, Federico Leva (Nemo) 
> > 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.
> >
> > jforres...@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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[svetlana]

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

Re: [Wikitech-l] Feature request.

[Pine W]

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* 






*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 
wrote:

> On 13 November 2014 06:40, Federico Leva (Nemo) 
> 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.
>
> jforres...@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

Re: [Wikitech-l] Feature request.

[James Forrester]

On 13 November 2014 06:40, Federico Leva (Nemo)  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.

jforres...@wikimedia.org | @jdforrester
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[James Forrester]

On 12 November 2014 14:46, Brian Wolff  wrote:

> On Nov 12, 2014 9:44 AM, "James Forrester" 
> wrote:
> >
> > On 8 November 2014 22:01, Brian Wolff  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.
-- 
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[James Forrester]

On 12 November 2014 14:26, Nkansah Rexford  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.
-- 
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Federico Leva (Nemo)]

What's the point in being (allegedly) "responsible" of something you 
can't influence?


Nemo

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Brian Wolff]

On Nov 12, 2014 9:44 AM, "James Forrester"  wrote:
>
> On 8 November 2014 22:01, Brian Wolff  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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Nkansah Rexford]

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 
wrote:

> On 8 November 2014 20:31, Nkansah Rexford 
> 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.html
> 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.
>
> jforres...@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

Re: [Wikitech-l] Feature request.

[James Forrester]

On 9 November 2014 01:10, Pine W  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.
-- 
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[James Forrester]

On 8 November 2014 22:12, Nkansah Rexford  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.​
-- 
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[James Forrester]

On 8 November 2014 22:01, Brian Wolff  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.
-- 
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[James Forrester]

On 8 November 2014 20:31, Nkansah Rexford  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.html
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.

jforres...@wikimedia.org | @jdforrester
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[C. Scott Ananian]

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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Pine W]

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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Nkansah Rexford]

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"  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" 
> 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"  > > 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  > > > wrote:
> > > > On Mon, Aug 4, 2014 at 9:50 PM, Pine W  > > > 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
> > > >
> > > >> 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 tri

Re: [Wikitech-l] Feature request.

[Nkansah Rexford]

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"  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" 
> 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"  > > 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  > > > wrote:
> > > > On Mon, Aug 4, 2014 at 9:50 PM, Pine W  > > > 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
> > > >
> > > >> 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, 

Re: [Wikitech-l] Feature request.

[Brian Wolff]

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"  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"  > 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  > > wrote:
> > > On Mon, Aug 4, 2014 at 9:50 PM, Pine W  > > 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
> > >
> > >> 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

[Wikitech-l] Feature request.

[Nkansah Rexford]

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" > 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  > wrote:
> > On Mon, Aug 4, 2014 at 9:50 PM, Pine W  > 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
> >
> >> 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
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> 
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
+Rexford  | +CG Central
 |
+233 266 811 165 l BFCT

___

Re: [Wikitech-l] Feature request.

[Pine W]

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  wrote:
> On Mon, Aug 4, 2014 at 9:50 PM, Pine W  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 
>> 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[rupert THURNER]

On Tue, Aug 5, 2014 at 10:38 PM, Quim Gil  wrote:
> On Mon, Aug 4, 2014 at 9:50 PM, Pine W  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 
>> 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

Re: [Wikitech-l] Feature request.

[Jeremy Baron]

On Aug 5, 2014 11:25 PM, "Nkansah Rexford"  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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Nkansah Rexford]

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  | +CG Central
 |
+233 266 811 165 l BFCT



On Tue, Aug 5, 2014 at 10:38 PM, Quim Gil  wrote:

> On Mon, Aug 4, 2014 at 9:50 PM, Pine W  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 
> > 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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[Quim Gil]

On Mon, Aug 4, 2014 at 9:50 PM, Pine W  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 
> 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

Re: [Wikitech-l] Feature request.

[Pine W]

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 
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" :
>
> > 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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feature request.

[rupert THURNER]

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" :

> 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

[Wikitech-l] Feature request.

[Nkansah Rexford]

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] Feature request for any future repo system

[Chad]

A pre-push commit hook that keeps people from checking in giant binary
blobs like gigantic 65MB jar files.

That is all.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Feature-request: euro-symbol (TeX)

[Michael Florian Schönitzer]

Hello,

In several Tex-implementations, Euro-sign (€) can be created by \euro,
\EURO \texteuro or \EUR.
This isn't implemented in Mediawiki jet - but several WP-users have been
asking for it.
Could anyone please do this?

Best Regards,
Michi

-- 
Michael F. Schönitzer
Mail: mich...@schoenitzer.de
Homepage: http://www.schoenitzer.de
Jabber: schoenit...@jabber.ccc.de/Home
ICQ: 294808517

Magdalenenstraße 29
80638 München
Tel: 089/152315


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] feature request: hide left navbar

[Michael]

Andrew:
> https://bugzilla.wikimedia.org/show_bug.cgi?id=14501

I see. 

thx !

I agree this to be reopened. 

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] feature request: hide left navbar

[Andrew Dunbar]

2009/2/6 Michael :
>
> I don't know if this is already possible. If so, just forget my question.
>
> Look at the Simple Machines' SMF 1.1.4, they have it implemented, working 
> example is here:
> http://mbreg.de/forum/index.php?action=unreadreplies
>
> Anyway, i miss this feature since long at wikipedia, where i am used to read 
> up texts heavily and i always regret there's only so small space left on 
> non-wide-screens, netbooks, PDAs, or when you need huge fonts (working from a 
> distance).
>
> What do you think about it ?

https://bugzilla.wikimedia.org/show_bug.cgi?id=14501

Andrew Dunbar (hippietrail)

> Greets, Micha
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
http://wiktionarydev.leuksman.com http://linguaphile.sf.net

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] feature request: hide left navbar

[Michael]

I don't know if this is already possible. If so, just forget my question.

Look at the Simple Machines' SMF 1.1.4, they have it implemented, working 
example is here:
http://mbreg.de/forum/index.php?action=unreadreplies

Anyway, i miss this feature since long at wikipedia, where i am used to read up 
texts heavily and i always regret there's only so small space left on 
non-wide-screens, netbooks, PDAs, or when you need huge fonts (working from a 
distance).

What do you think about it ?

Greets, Micha

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l