Hi,
On Fri, Apr 19, 2013 at 5:29 PM, Greg Grossmeier greg@wikimedia.org wrote:
Mostly it is the function of multiple people editing the document together at the same time in the same room. Until that problem can be solved on wiki, then a big wiki table probably won't be functional, at least in the current form that we've taken for this.
But, I also don't know the full capabilities of what could be done, here, so if someone has a suggestion on how to work this on wiki that allows easy multi-user simultaneous editing, please do let me know.
Off the top of my head, and without thinking too much about it:
Solution #1: All the content lives in [[Projectname/Roadmap]] pages, in monthly sections labeled with Labeled Section Transclusion. They can be transcluded into other pages (like a big all-encompassing Roadmap page, or smaller roadmaps per team / subdepartment). A JavaScript gadget allows for easy editing of roadmap items (i.e. cells) directly from the Roadmap page (and other transclusion pages) using a modal overlay, like the StatusHelper does ( https://www.mediawiki.org/wiki/MediaWiki:Gadget-WmfProjectStatusHelper.js )
Pros: * Everything is and stays on wiki. * The roadmap for each project can be maintained by the project's team more easily, because it's closer to the project page. * The JavaScript & template hackery needed to make this work is probably not too complicated and can be inspired by the existing StatusHelper. * No edit conflicts, since people are editing different pages. Cons: * People can't simultaneously edit the same roadmap item (cell for a given month and a given project). * People need to refresh the page to see edits made by other people with the gadget. * Some template / LST / JavaScript dev work is required. Based on my understanding of how the roadmap is currently updated (each Tech director updates the roadmap for the projects that fall under their supervision), the "cons" don't seem unsurmountable.
* Solution #2: All the content lives in a big table at [[Roadmap]] that can be edited simultaneously by users using a yet-to-be-developed round-tripping tool to an ethercalc instance in labs. Someone opens the page for editing in ethercalc, everyone makes their edits, and the content is saved back to the wiki page. Pros: * Everything lives on wiki. * People can simultaneously edit all parts of the document, including the same cells, and immediately see each other's changes Cons: * This requires significant dev work, probably not trivial considering the difficulties encountered when we tried to integrate regular etherpad with wikipage editing a few years back. * How do we handle edit conflicts? * This poses other questions like who is attributed for the edits, etc.
An alternative to #2: the round-tripping is done manually by copy/paste or similar (as it used to be done when tech directors updated the roadmap in etherpad) if the conversion between formats isn't too lossy; This avoids having to develop an integrated round-tripping tool.
Solution #3: A combination of #1 and #2: for example, the content lives in a big table at [[Roadmap]], and there's a round-tripping tool to an ethercalc instance in labs for collaborative editing, but there's also a JavaScript gadget to edit individual cells of the table.
Note: LST can probably be replaced by Semantic MediaWiki if it's available on the wiki we're talking about.
In a nutshell: I understand that the way the roadmap is currently updated (in a meeting of all tech directors each updating their sections) requires simultaneous editing of the /page/, but I'm not sure concurrent editing of /each cell/ is as crucial, so compromising on that may greatly simplify the problem.
HTH,
-- Guillaume Paumier Technical Communications Manager — Wikimedia Foundation https://donate.wikimedia.org