The “Wiki Post” feature is more hazardous than useful on any forum with more than 10 active users at any one time. The fact that users can overwrite one another’s edits when they end up doing edits at the same time is a huge bummer.
Couldn’t we just take a page out of WordPress’ book and implement post edit locking? This can come in handy for that rare event when two moderators end up editing the same post as well.
@erlend_sh It’s a good point. But post locking? Let’s say a user take 30 minutes to edit a post, another users will have to wait 30 minutes? One solution to this is implements ETags in reponse and request.
The way we did this on Stack was that the longer edit overwrote shorter edits. Survival of the fittest.
Long term (as in a few versions out) if wiki becomes much more heavily used there is stuff we could do without needing to resort to locks.
Off the cuff, my initial reaction to “fixing this” would be to add a red highlight around an area that is being edited at the moment by someone else (only in the editor) it would allow you to easily avoid duplicate editing, further more we could apply “diffs” when saving edits to avoid an edit killing an intermediate edit.
Always been facinated by http://sharejs.org/ and stuff like that
I do feel its quite low priority though for now, at least until wiki gets a very big workout somewhere.
Huge bummer is understating it. I can see how this makes wiki post almost useless, in those cases!
How about the way google docs does it? You surely have thought of wikipedia, but while they can somehow work it out for hundreds of people, with moderators and locks and all that, I think their interface is still just outdated.
Here’s a simple idea: just show who’s editing at the same time and/or at the moment of posting. Allow for people to copy & paste and keep their draft saved. Post the latest to hit “post”. Let them fight. Let mods moderate. 
Other design ideas…
Make it clear when you are editing a wiki post that someone else is also editing.
When someone submits changes to a wiki post, if the wiki post has changed (been updated) since they began editing, then show them force them to handle the merge – i.e., show them their version and the updated version and ask them to reapply/copy their edits into the updated version.
It’s a crude but simple approach (similar to Mediawiki). If/when someone writes some merging logic in the future, then the version presented to the user could start including some of their edits auto-merged. In the meantime, you avoid losing your work completely (or overwriting someone else’s without the opportunity to merge). Anything fancier is probably out of scope for Discourse (people can use etherpad if they need to group edit, then bring the result back to Discourse).
The way this works now, edits are being lost. I don’t think I would have enabled the wiki on certain posts if I knew this. A lock + timeout seems like the minimum needed to avoid conflicts. I do like this solution!
Our use case would really benefit from some transparency over when the post is being edited.
Thanks to @nbianca we now show an edit conflict indicator, with the avatar of the user in conflict
