Grants:Project/Rapid/MarkAHershberger/MABS: Multilateral, Asynchronous, Bidirectional Synchronisation (of wikis)

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
statusFunded
Multilateral, Asynchronous, Bidirectional Synchronisation (of wikis)
Provide a MediaWiki extension that implements MABS as a proof of concept. This will let anyone without too much technical expertise see that the technology is capable of synchronizing edits across wikis.
target* (Every wiki has potential users whose internet access is limited or sporadic.)
start dateJune 25
start year2018
end dateAugust 31
end year2018
budget (local currency)2000USD
budget (USD)2000
grant typeindividual
granteeMarkAHershberger
contact(s)• MarkAHershberger
join
endorse


Project Goal[edit]

We're trying to provide better ways to incorporate the work of editors who do not have reliable network access.

WikiFundi has done the initial work of providing the editing experience to offline users, but incorporating their work back into Wikimedia projects is still a manual process.

Multilateral, Asynchronous, Bidirectional Synchronisation (MABS) is a method that is under development to provide a way to automate incorporating the edits into Wikimedia projects, but the technology is not automated and has a steep learning curve.

Project Plan[edit]

Activities[edit]

I, assisted by others of different technical levels, will work to develop and test an extension that will show that automating remote edit incorporation is a feasible goal.

At the end of the project, we plan to have an extension and sufficient documentation available so that interested parties (e.g. WikiFundi or astronauts on the ISS) can see that this is a viable solution to the problem.

Additionally, we hope to use the proof of concept to attract other developers of FLOSS to the project and improve the viability of it over the long term.

Impact[edit]

  1. Number of total participants: 3 (myself and 2 assistants)
  2. Number of articles created or improved: n/a or (over the life of the tool) 1000s.
  3. Number of photos uploaded to Wikimedia Commons: n/a or (over the life of the tool) 100s.
  4. Number of photos used on Wikimedia projects: n/a or (over the life of the tool) 10s.

(Note that content creation is not the target of this grant proposal, but this project will, if successful, enable many, many contributions over the long term.)

Resources[edit]

I will be contributing my own time. This rapid grant will be used to pay for my assistants' time that they will spend testing, documenting, and helping me develop this tool.

I will use my involvement in the Wikimedia movement, my knowledge of MediaWiki, and my contacts with third party MediaWiki users and their use cases to implement and test this proof of concept.

Funding may become available from other sources once they see this proof of concept.

Endorsements[edit]

  • I totally agree with all the points above. This proof of concept will be beneficial to many projects including WikiFundi and NASA's goal of wikis in space. With a working prototype, we can consider how this might be included in these projects or inform the final product. It will help us kick off usability and design conversations. Also it will help us communicate and demonstrate the value of asynchronous wikis to less technical partners. This latter point will allow us to find other funding resources and ensure the larger project's completion. User:DStrine_(WMF)
  • In order to truly have a MABS wiki system, I see two key technologies that need to be integrated with MediaWiki: The ability to synchronize more frequently with just the revised content (not the entire wiki as a whole each time) and the ability to resolve revision conflicts due to changes being synchronized bidirectionally. This prototype will help demonstrate these problems and how they can be solved. In my experience advocating for the use of wikis, a working prototype significantly helps to get the point across to non-technical audiences and increases the chance of support and funding. Darenwelsh (talk) 20:02, 11 May 2018 (UTC)
  • This project has the potential to help in a variety of offline use cases. Before I joined the Foundation, I worked with customers who desired offline editing access. They wanted to be able to edit while in transit or in bandwidth limited environments and then have their edits synchronized to their wikis when they had connectivity. Mark has talked about this capability for a while, but has not had the time or resources to pursue a working prototype. This funding would help jump start this project and prove its feasibility. CCicalese (WMF) (talk) 15:27, 12 May 2018 (UTC)
  • Besides being relevant to some groups who use MediaWiki for extremely high-impact knowledge sharing projects (WikiEm for emergency medicine , WikiFundi for Wikipedia editing in the global South, NASA EVA team for space flight research), this experiment will be useful for two very important technical problems for the Wikimedia community: offline editing (see e.g. T106898) and sharing JS/Lua/template code between wikis (T121470). While we probably want to take a different approach for those, it will still be instructive to see how well this one works and what UX strengths and weaknesses it exposes. --Tgr (WMF) (talk) 07:48, 13 May 2018 (UTC)
  • This project coincides with my own developing toolset at https://dataspects.com/structured-data-management-suite and I am looking forward to cooperating! Lex
  • Synchronization of wikis could have positive impacts to remote users of wikis, as well as provide the opportunity to synchronize similar content between wikis. Jamesmontalvo3 (talk) 15:06, 14 May 2018 (UTC)
  • Bidirectional synchronization of wikis could be very useful for private wikis that would like to publish a limited amount of their content and solicit external (public) feedback (possibly via discussion pages). Bryandamon (talk) 21:12, 14 May 2018 (UTC)
  • I strongly support this. When I use offline Wikimedia content, I rarely contribute back due to the hassle of re-opening in another interface, and if I'm somewhere where my connection is slow or non-existent, I almost never remember to go back and fix problems I've seen. My Kiwix gets horribly out-of-date as the re-downloads are so big. I accidentally re-invented this at Community Wishlist Survey 2019/Mobile and apps/Low-bandwidth editing app, so obviously I want such a program! More importantly, people in areas with expensive, slow and intermittent connections want to contribute to wikis and can't. The high-bandwidth nature of editing is a large source of systemic bias and limits the speed of growth of many wikis. HLHJ (talk) 03:17, 14 November 2018 (UTC)
  • This will help with getting wikis into more and extreme places, where they have the potential to do great amounts of good. Such as the ISS. Or Antarctica. Or the Pitcairn islands. Or Mars. For! --denny (talk) 06:26, 30 November 2018 (UTC)