Hi all. > On Mon, 26 Jan 2015, Mark A. Hershberger wrote: > At the developer summit just now, we've decided to use the tag #mwstake > (for twitter, etc) or the subject line prefix (like I've done here) for > communication on mediawiki-l for the MW stakeholders group. > > The first item we'd like to discuss with MediaWiki users is what should > we actually focus on?
== Introduction == Free software projects stress the freedom to redistribute and modify to suit one's needs as opposed to the so-called open-source camp people suggest that while the code should be open, what mostly matters is ability to edit it and get changes approved by the active maintainers. However, these two neglected freedoms -- to distribute modified copies -- are crucial and work as a means for free software to evolve. Now I am looking back at mediawiki about this. As a software freedom site, and Wikimedia Foundation being a information freedom organisation, it would seem logical for MediaWiki to also do everything it can, like git, to support such distribution freedoms and make merge possible. This text is dedicated to documenting the potential MediaWiki has in this direction. == Problem definition == Specifically, right now, MediaWiki does this with special:import and special:export. People can download a page with its history and put it on another wiki. However, this feature: 1) does not handle merge conflicts at all. it either overwrites, or doesn't import at all. (git handles cherry-picking and merging much better); 2) is not easy to use for a specific page, you have to go download file manually and then upload it to the other wiki; 3) is also not easy to use because you don't see which wikis contain an updated copy of a given article, and how many edits yours is behind (a visualisation of the changes) and you have to compare the history by hand. == Suggested solution == I would expect that, if this suggestion is not a delusion, mediawiki should be improved to include A) a merge conflict handler, B) an interface -- on the page history, and on my watchlist page -- to visualise (see git tree, git log, etc) and merge fresh changes from other wikis, with necessary credit in edit summary, but the edits need to be made under my login name (I do not want us to handle usernames issues between such wikis). C) a pref pane where I link sister wikis (modified copies of the current wiki) which I enjoy copying stuff from. == Side-effects and consequences == I would expect this to also foster development of mediawiki itself by our stakeholders, as individual small wikis would emerge -- say, wikiproject math -- and work on their own extensions, such as a good math editor, within a small community of math anthusiasts who have control of their own wiki and can hack onto extensions without going through the trouble of requesting them from the wmf (esp. hard in early stage of development of an extension, and especially as people have no shell access. They can, of course, run a mirror on wmflabs tools, but there nobody will really test such extension and the development would die somewhere early. Running new extensions in the beta tab currently requires a lot of effort for the wmf folks to supervise that each release of such extension is properly audited, but this is a big overhead and running a small active wiki focused on development of a certain tool while participating in writing content which would then be merged into wikipedia itself would in my view be a better route). People mostly focusing on js stuff but underutilizing the potential of writing their own extensions has been a big problem, plus individual wikis may be configured in some ways these small projects prefer even if such configuration is not in the interests of the majority of other readers and users but lets the small community work through their field more efficiently. -- svetlana _______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
