Closed Bug 1051211 Opened 7 years ago Closed 6 years ago
We should investigate whether this extension will give use the Etherpad integration that we want.
From the description, I think https://www.mediawiki.org/wiki/Extension:EtherEditor would fit our use case better - if it's optional for editing and works well. ;-)
Most likely neither plugin will work to integrate our *current* etherpad.mozilla.org installation with wikimo. This is because we're running the original Etherpad, not the more modern Etherpad Lite. The latter is a total rewrite, and thus anything written to use it (unless it's a very simple iframe integration or something) is unlikely to work. What's the deeper intention here? Are we trying to enable simultaneous real-time wiki editing by multiple parties, or are we trying to somehow integrate content from etherpad.m.o into wiki.m.o (or vice versa)?
We're exploring this as one possible way to enable real-time collaborative editing (see bug 1051204). We may or may not proceed with using this extension on MozillaWiki in production. I don't think we'd try to integrate existing etherpads (from etherpad.mozilla.org) into the wiki as we're aware that's using legacy etherpad rather than etherpad lite. Other options we're looking at include adding TogetherJS.
(In reply to Jake Maul [:jakem] from comment #2) > What's the deeper intention here? Are we trying to enable simultaneous > real-time wiki editing by multiple parties, or are we trying to somehow > integrate content from etherpad.m.o into wiki.m.o (or vice versa)? The former is the intention: to enable real-time collaborative editing.
We're also looking at making it easy to post content from etherpad.mozilla.org to MozillaWiki, but that's a separate task.
Yes, I think the main use case here is meetings where we want to be able to do collaborative editing of the agenda/notes during the meeting and then have them archived on the wiki for the long run. Right now we are doing that by using an etherpad during the meeting and manually copying over to a wiki page later on, which is quite a bit of work and a suboptimal procedure.
(In reply to Jake Maul [:jakem] from comment #2) > Most likely neither plugin will work to integrate our *current* > etherpad.mozilla.org installation with wikimo. This is because we're running > the original Etherpad, not the more modern Etherpad Lite. Of course, there is bug 831448, which tracks us actually migrating to Etherpad Lite.
Whiteboard: [featurerequest][extension][2014q3] → [featurerequest][extension]
Target Milestone: 2014-Q4 → 2015-Q1
* Another way to do this (that will only work with the later versions of Etherpad): embed etherpads directly into a wiki page using an iFrame. This allows for easy "edit in place." * Here's an example of this iFrame embed in a blog post, for example: http://openmatt.org/embed-your-etherpads/
(In reply to Matt Thompson (@OpenMatt :OpenMatt) from comment #8) > * Another way to do this (that will only work with the later versions of > Etherpad): embed etherpads directly into a wiki page using an iFrame. This > allows for easy "edit in place." > > * Here's an example of this iFrame embed in a blog post, for example: > http://openmatt.org/embed-your-etherpads/ Thanks for that proof of concept, Matt. This could certainly be done with a widget, for which we now have the capability. Though, as noted earlier (comment 4 and blocking bug 1051204), our primary goal is to enable real-time collaborative editing of wiki content. While I can see value in allow users to utilize etherpads with one less click, I can also see the potential for a lot of confusion, particularly since the login and authorship states of the wiki and the etherpads will be completely disconnected.
Another thought I just had, separate from the possible user experience context confusion. Etherpads are great in that they have an extremely low barrier to entry because you don't need an account to edit. They are also bad for this reason because it makes them susceptible to vandalism, spam and abuse. We've seen this on Mozilla-hosted etherpads several times over the years. In addition, there are very few user-accessible tools for mitigating spam/vandalism within etherpads. On the mediawiki side of things, our usual tools are completely ineffectual at detecting spam/vandalism in iframe-embedded content because that content lives outside of the wiki. These issues combined make a strong case to not embedding and automatically rendering etherpads within wiki pages.
Agreed. Cost-benefit ratio is too high.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
To be clear, we're still going to look for ways to implement real-time collaborative editing (bug 1051204).
You need to log in before you can comment on or make changes to this bug.