MediaWiki

Wikimedia Developer Summit/2018/Supporting Third-Party Use of MediaWiki

< Wikimedia Developer Summit | 2018

Dev Summit '18 https://etherpad.wikimedia.org/p/devsummit18

Supporting Third-Party Use of MediaWiki https://phabricator.wikimedia.org/T183312

  • See task for session description, goals, and pre-reading notes

DevSummit event

edit
  • Day & Time: Monday, 10:10 – 12:30 Room: Kinzie
  • Facilitator: Santhosh Thottingal
  • Notetaker(s): ...

Please answer the following questions:

  1. Why are you interested in this session?
  2. What are the important unanswered questions?
  3. What are the important strategic goals?
  4. What critical outcomes must be achieved to answer these questions/achieve these goals?


MarkAHershberger:

  1. I was asked to help lead this session
  2. --
  3. Getting leadership for WMF to recognise the importance of MW as Free Software
  4. Find ways of showing leadership that MW as FOSS helps the WMF


Cindy Cicalese:

  1. I am one of the topic leaders for this session. I spent 10 years maintaining a third-pary MediaWiki wiki farm infrastructure and developing knowledge management applications for government customers on top of it. There are many challenges to using MediaWiki in a third party environment, but also enormous benefits. I am a great believer in the power of MediaWiki - so much so that I became the Product Manager for the MediaWiki Platform Team at the Wikimedia Fundation last year. <3
  2. What should be the minimum necessary platform requirements for running MediaWiki?
    • Can JavaScript be required?
    • Must shared hosting be supported?
    • Should command line access be required for installation?
    • Can container based installation be a requirement?
    • What is considered core to the MediaWiki stack? That is, what should be in a default installation?
    • What should the +2 policy be for gerrit-hosted third-party extensions?
  3. Ease of MediaWiki installation, upgrade, and maintenance
    • Quality control and support of MediaWiki extensions
    • Published roadmap to support future planning and decision making
    • Accurate documentation that supports findability and limits redundancy
    • Active technical support community
  4. An architectural vision for the future of MediaWiki and a plan to implement it
    • Improved MediaWiki documentation on mediawiki.org
    • Improved MediaWiki support channels


Gergő Tisza:

  1. I am a long-term Wikipedian frustrated with the slow pace of technological progress and believing that Wikimedia investment into third-party use will eventually pay off as a strengthened third-party ecosystem invests back. I think opensource projects can rarely be successful on a purely nonprofit basis, and would like to see more commercial use of MediaWiki so that funding for its development is not limited by the number of people donating to Wikimedia. ( In more detail: https://www.mediawiki.org/wiki/User:Tgr_(WMF)/Make_MediaWiki_commercially_viable ) Similarly, I would like to see more third-party enthusiast use so that the Wikimedia community is not the only source of volunteer developers.
  1. What are the viable commercial models for MediaWiki? (Custom development for the enterprise, consultancy, paid hosting, ad-funded hosting etc) Do any of those models require some kind of "bootstrapping" (ie. not viable until some aspect of MediaWiki is improved)?
    • What assurances would be required for buy-in from the Foundation (or another investor, if one exists) to fund such bootstrapping?
    • What is the audience of MediaWiki as a product? What are the features they use MediaWiki for, what do they have, what restrictions do they need to work with?
    • Are there untapped potential audiences that are barred by the lack of some feature (or process, outreach, etc)?
    • A healthy commercial ecosystem around MediaWiki (and other associated software) that's an influx of funding for MediaWiki development on a scale comparable to that of the WMF, and a source of skilled MediaWiki developers.
    • MediaWiki becoming a popular hobbist / enthuasiast tool for setting up communities, resulting in an influx of volunteer developers on a scale comparable to that from the Wikimedia community, and in elevated levels of "wiki awareness" among non-Wikimedian internet users.
    • MediaWiki being an easy-to-use tool for organizations engaged in some form of knowledge curating, that improves the efficiency of like-minded organizations that Wikimedia tends to partner with, and results in elevated levels of "wiki awareness" among knowledge professionals.
  2. Proper audience research into the (existing and potential) MediaWiki userbase.
    • Market research into commercial viability of MediaWiki.
    • A prioritized roadmap for the most important features for bootstrapping the third-party ecosystem(s) and a team (or external org) to work on them
    • An environment that makes it easy for new developers (whether volunteer or professional) to join: good documentation, high-signal and responsive support channels, timely code review, inclusive culture.


Session Notes (on the day):

Unanswered questions

General commitment

edit
  • Why should WMF care about third-party usage of MediaWiki?
    • "The mission of the Wikimedia Foundation is to empower and engage people around the world to collect and develop educational content under a free license or in the public domain, and to disseminate it effectively and globally."
      • I think it indirectly supports the mission, but I don't see a direct link to the mission. However, I think the indirect link is more than enough (imho), but that does not feel like the majority opinion.
    • sharing knowledge is part of WMF mission :)
      • Wikimedia projects have a set scope, and plenty of knowledge is valuable to keep, but out of scope for Wikimedia projects. We need independent wikis to maintain knowledge
      • Is MW "one of the projects"? yes
    • TT: Open-source reusability is one way of ensuring quality control (maintainability, stability, installability, etc.), "good" code leads to natural reusability for third-parties and influx of contributions (issues + commits).
      • Do we consider third-party MW sites spreading knowledge as success for WMF, e.g. knowledge not WMF-hosted. Or do we consider third-parties mostly unrelated to the movement of sharing knowledge (e.g. corporate wikis). if the latter, could we do something to change that balance, to make third-parties feel "part" of the wiki network. This would get significantly better once we change content management into smaller chunks and better wikidata integration, see Commons.
      • If we accept contribitions from people maintaining third party support, is that a workable compromise or still worse of both? Thinking about non-zero overhead for first-party support.
      • Disregard prior two points, but instead taking angle of open-source reusability as one way of controlling quality and ease of operation and usability for everyone. (UX, API scalability, progressive enhancement starting with LAMP, user-generated wiki farm like cloud/incubator/wikia).
      • James (NASA): Improved third-party wikis, even if not for our mission, still helps users familiarise with the system so that if they get to Wikipedia, they might feel more comfortable contributing, because they've done it before at work/school etc.
      • WMF should care about third-party users because it would enable our mission. How?
        • 1. Rather than focussing on third-party usage, we can focus on being a project that is easy to maintain, scale, use, and install/upgrade, with a stable API, then we have a good piece of software for ourselves that naturally would attract third-parties.
        • 2. Because having many third-party MW sites creates a diverse network of knowledge sharing that we couldn't achieve on our own. This leads to an important subquestion: Regardless of what WMF prioritises, why should third-parties even want to use MediaWiki? I think right now the answer is that they have very little incentive. We have many "text storing" competitors. Not many "collaborative editing" competitors, but by itself tends to be a hard sell, especially with our steep learning curve for even achieving that in the first place (hard to edit, hard to install/maintain/upgrade). So I'd propose to instead create new reasons for why third-parties should want MediaWiki:
          • What if having a mediawiki install means you instantly have easy access to integrate lots of multimedia content (Commons), rich data (Wikidata), and an easy way to integrate chunks of from other wikis (wikiHow, Wikia, Wikipedia etc.). This would create an incentive to use MW, not just for creating somethign from scratch, but for having a very high starting point with lots of existing data to start with. This in turn would also allow others to integrate said content back into our projects. Perhaps somewhat similar to the "Decentralised knowledge" ideas and decentralised software (Git), and decentralised social networking (GNU Social).
    • MK: Helps ensure longterm viability of project; helps project scale and reach new audiences; helps achieve mission
    • Third-party users build community, community is a force-multiplier on our core mission (aka, to use donor funds wisely, we should spent part of it making it easier to volunteers to contribute to the mission). Everyone who learned to edit/contribute to "the wiki at work" is another editor primed to edit Wikipedia.
    • Q is not "should WMF support 3rd parties" but instead "how much". My strawman: at least one full-time employee, in a dedicated "External Wikis" team, scored entirely on contributions made by 3rd parties and # of 3rd parties running the standard WMF install of mediawiki. More: https://en.wikipedia.org/wiki/User:Cscott/Ideas/Integrating_MediaWiki
    • Helps recruiting, can recruit developers with experience in MediaWiki
    • Grow the developer community +1 +1 +1 +1
    • A strong MediaWIki community increases chance Wikimedia sites can be recreated in case of disaster.
    • Many project proposals (on Meta, for new sister projects) could be answered in the negative, but with the recommendation that people can install their own MediaWiki. If it were easier to do that.
    • Because the tool they created has this as its central thesis
    • ROI. Speed of MediaWiki development is proportional to size of ecosystem (inflow of money, number of volunteer developers etc.); strategic investment that removes barriers and opens up MediaWiki to new audiences could increase that ecosystem significantly
    • Making it easier on third parties will force us to also make it easier on ourselves +1 +1 +1
    • Not caring left us with a whole lot of technical debt
    • By making it easier on others, we don't have to start every single project that fits within our vision ourselves (can start outside of us).
    • Particapatory use, can scale both external and internal. And we need to scale internally.
    • Forking projects must always be possible - this is an important safeguard for accumulated knowledge.
    • Contra: MediaWiki was created as internal tool for Wikipedia. (contra-contra: but even WMF uses it for other things!)
      • Maybe that is true for phase 2 (Magnus). The current code base (phase3) was imagined as a general tool by its originator Lee Daniel Crocker, like other wiki engines that existed at the time. (Fair enough, but I'll say the installer was not very user-friendly and it had 'WIkipedia' hardcoded in it for a while in a lot of places. ;) All a matter of eventualism perhaps. :D)
      • Lee basically saw it as first a Wikipedia tool, but available for others who found it useful. +1
      • -> leads to question of how much "we" vs "they" (?) do the maintenance work for one's own needs. We haven't yet balanced that. :D
    • Why should 3rd parties use MW?
      • if you're making a "knowledge base" kind of thing that you want to be participatorily-created, you might want a wiki of some sort!
      • If you're choosing a wiki, you might want to use the same tool other people are using. "Hey I saw Wikipedia, I want to do stuff like that." Well now you have it. [but -> get extensions, get templates, blah blah]
      • [Roan] Can we make it easier for smaller free-knowledge wikis to feel part of a network of knowledge wikis? In the same way that commons lets wikis reuse and share media, can we make it easier to share and link other sorts of free-but-not-WMF content.


Audience

edit
  • Who is our user? Why can't we hear his/her voice?
    • brion: we made a mistake making WMF the first-party user. WMF should be just another user of the shared mediawiki platform. We need a project to keep mediawiki healthy for all users to use. We have our internal world where we think of mediawiki as "the tool we use to run our sites". I think that was a big mistake and we need to fix it one way or another. We need to change our thinking. I've love to see more of the third party users/sites participating in that maintenance burden as well. A lot of the work third parties do is creating their own extensions or own skins, and those get shared—but we at the WMF never see it because we don't look at that.
      • CSA: a good start might be to try to come up with a mission statement for a "mediawiki foundation", which would embody the idea that mediawiki's core use is public knowledge, without limiting it to that use. Then, even before such a foundation exists, we could still use this mission as a reference when describing work on core mediawiki.
  • Who are our potential users? Where are they? What are they currently using for this functionality? (Jira? Slack? Facebook Workplace? Something else? Nothing?) Why? Why should they use MediaWiki instead? What are the ways we can frame that? Where are they finding the other tools they use? How does this become part of a stack of tools?
  • Who makes these decisions for organizations? How do we reach them?Is that the audience?
    • Are our users the people who install MediaWiki and maintain it, or the people who edit on it?
    • Concentrating on the site admins/maintainers probably is the best force multiplier—they know _their_ end-users, and can surface pain points and requirements.
  • WMF should also be a user. If our strategy is to give people the tool, than why should WE be the barrier for them to start doing so ?
  • Chapters often run their own wikis. it's a mess.....
  • Shipping a set of default extensions and a default configuration is our opportunity to evangelize these social structures. (Permissive, etc)


Technology stack

edit
  • Will we support plain, limited LAMP stack?
    • What objectives would be hindered by keeping support for LAMP?
    • What costs do we believe can be avoided if we would not need to support the LAMP stack?
    • Relative complexity of a layered system (LAMP core + other services that might be needed by one user but not others)?
  • What should be the minimum necessary platform requirements for running MediaWiki?
    • Can nodejs be required on the server?
      • MediaWiki requires it to be run? (not optional)
    • Must shared hosting be supported?
      • (Define "shared hosting")
        • . I think the defintion is pretty clear. Host where you only have ftp access to a folder and apache and php is setup to serve files from your folder. i.e. anything without root access?
          • Yeah, non-root is not the same as LAMP-only. If this is meant to be about LAMP/FTP, then perhaps merge with the first question.
        • It would be easier to redefine shared hosting as "no root access", "served out of one directory", "low memory limits", "no command-line access" and then discuss which of the attributes are problematic for moving MediaWiki development further.
        • Who is our audience, and can we get away with not supporting shared hosting in light of the audience and mission? If so, we should justify that.
    • Should command line access be required for installation?
      • saying yes makes security potentially easier, saying no makes things easier on the person doing setup. is a tradeoff!
    • Can container based installation be a requirement?
      • I would say no +1 +2 (This really depends on if your talking about pure mediawiki or mediawiki+)
    • Given that container based installation is increasingly popular in the world in general, what are the remaining use cases for shared hosting? For whom is container based installation overkill, but MediaWiki not?
  • What is considered core to the MediaWiki stack? That is, what should be in a default installation?
    • Despite it being called "MediaWiki core", most people think the base set of bundled extensions are part of "core" functionality
      • I don't think most developers feel that way. I don't at least
    • Can we mitigate some of the technology challenges by providing services; for example, allowing/making it easy to get a Parsoid service running on Cloud Services for 3rd Parties to use easily, etc
    • How can we provide a minimal set of services to have a wiki that is usable by any final user (a good tool to edit and a good tool to discuss)?


Update / installation

edit
  • Goal: Make MediaWiki as easy as WordPress/NextCloud to update for security patches without being pwnd as easily.
    • And take on the security burden it will bring? (how many WP installs are exploited by being able to modify PHP files from the web? Answer: A lot)
    • security burden > optional security burden
    • Related goal: make so your custom extensions/skins don't break when you update core. (-> clean APIs)
      • Deprecation policy should take care of this; but sadly using LTS means those users don't get that benefit
    • Can we make it easier for 3rd parties to install the latest WMF features?
    • Can we make it easier for 3rd parties to keep their wikis up-to-date?
    • Can we make it easier for 3rd parties to configure their wikis?
      • Are we going to have to manually edit LocalSettings.php forever?
    • Are we going to have to manually install extensions and skins forever?
    • Can we limit installation/upgrade to CLI ? "limit"?? It is possible, do we want it to make it *only* cli? why? e.g. Composer usage


Support / resources

edit
  • Do we support amateur sysadmins? i.e. people who install MW without knowing all that much?
    • Do we have data about that? Is is the majority? (I think that's the majority.)
  • What are the potential audiences (users, developers, customers) for MediaWiki? Which of those groups require "bootstrapping" (someone needing to invest into adding the features they need to MediaWiki before they are willing to invest their own time/money)?


Documentation

edit
  • End-user documentation vs site admin documentation. Do we have clear maintenance of such docs and tools?


Extension quality

edit
  • What should the +2 policy be for gerrit-hosted third-party extensions?
    • It should be whatever the extension author wants it to be +1 +1
  • We are eager to break backwards compatibility of extensions, but not backporting bug fixes. That causes problems when you inevitably enocunter a bug in an extension that is fixed in latest version, but that latest version depends on latest core/something else.
    • related goal ^ Cleaner APIs for extensions that can be more future-proof.
    • Also encourage better(?) development practices


Ecosystem

edit


Other

edit
  • How users can know what are the last changes and the coming ones? What is the core roadmap? Whare are main extensions' roadmap?
  • What are the barriers to access? (Microsoft Office license? eh?) What do we need to know about them? What technical/social/other barriers? How should they feel?
  • What do we envision for onboarding?
  • How should potential users feel?
  • VE???
  • How can we get better maintained extensions?
  • Access control / integration with external identity services
  • Page-level access control would be very attractive to lots of corporate 3rd party uses.
  • Who does the work to make the 3rd party experience better?
  • Having a network of wiki content


Goals:

  • Involve ops and devs folks from third-party users in MW development decisions and work. Share maintenance burden of MediaWiki between not just WMF/WMDE but with our fellow
    • What about volunteer developers (who are not necessary 3rd party users)?
  • Establish a MediaWiki installer beyond the basic web-based installer that provides a full installation with all the bells and whistles like Visual Editor, Cirrussearch, etc, and doesn't require years of technical experience.
  • Advertise MediaWiki as a software that supports many languages and multilingual content.
  • Rise awareness of third party uses of MediaWiki within WMF (highlight different kinds of 3rd party MediaWiki installations)
  • Ease of MediaWiki installation, upgrade, and maintenance
  • Ease of MediaWiki configuration
  • Quality control and support of MediaWiki extensions
  • Published roadmap to support future planning and decision making
  • Accurate documentation that supports findability and limits redundancy
  • Active technical support community
  • Suckless lifecycle of managing wiki
  • Usability for non-developers
  • Complete experience with mediawiki (ie, "all the extensions and cool features" not "some stripped down wiki")
  • Make a fresh wiki not a blank starting point:
    • User accounts: Easy 3rd party identity service integration, so that 3rd party users don't need to create all new accounts.
  • Treat third-parties as part of the community, Wikimedia movement
    • Perhaps expand scope of Community liaisons to include third-party site-admins (not just end-users of WMF sites)
    • Team working on developer tools (eg. MediaWiki-Vagrant) could include Installer in its scope.


What next? Actionable steps

edit
  • MWStake: Identify who is the target user
    • Types of 3rd party users
    • Small instances are part of this and we should recognize this
  • MWStake: Identify needs / issues
  • MWStake: Survey to find out, similar to MWStake survey (##link)
    • More data than before
  • Low hanging fruits
    • Improving installation -> extensions, services
      • Who and how?
      • Where is the funding coming from?
      • Writing browser tests
      • List of what do we want to install
    • Improving documentation
      • What are you allowed to do? coding norms, commit norms
      • recommendations and ...
    • Best practices for extension +2 and change on mw documentation: who is allowed to do what? what are the processes?
      • Special interest groups would be the right place to discuss this
    • Organize different groups doing the same thing -> streamline development
    • Medium of communication for 3rd party developers with WMF devs (IRC is not the solution)
  • Explain what we want to do with MW to the rest of the community and why we need to do it (convince non-tech people)if I'm repeating.)
    • How do we prioritize work?
    • who is responsible for installer
    • be bold and edit documentation
      • we need to define a way to edit that documenttion to unify it
    • Don't speak about third party wikis anymore. It is like considering Wikipedia and "other wikis".
    • Who does it and who funds it? Must decide between:
      • WMF (on its own or via contract?)
      • Community (the users who need it do it)
      • External people (the users who need it contract someone who can submit fixes upstream)
    • There should be community liaisons speaking with other users than WMF ones.
    • Third parties as first-class citizens in dev planning/work -> don't just have a 'third party team', but let cross-cutting issues be handled generally ("liaisons", "developer tools", etc.)
    • 'Seal team six' for wikimedia chapter wikis: make sure they get fixed (-> community liasons + fixing)
    • MWStake could be an actor in some of these cases...
      • surveys etc so far...
      • still needs to find its place in the wikiverse
      • stakeholders can be entities to assign tasks to: streamlining efforts, collect and articulate third-party needs
    • re services issues—docker vs other orchestration and isolation systems? (setup, maintenance, deps)
    • Evangelist to go to the entities using MediaWiki
    • Get a bullet point in the Wikimedia movement strategy about MediaWiki 3rd-party support
    • Improve developer tooling
    • Improve feedback and help loops (on Mediawiki? on https://discourse-mediawiki.wmflabs.org/?)


How to proceed

  • copy condensed version of this list on wiki and continue process there
  • Transcription:
    • Mark: "The medium is the message" when it comes to mediawiki, lots of folks look at wikipedia—third party users tend to see that message, "i want that"—the software is how you do that... on wikipedia, the message is "we trust you. we'll verify it, but we trust you to put it out there." people want to adopt that, use it in their organization... The wiki didn't create knowledge, or hyperlinks, but did create a way to trust (and verify) people/information and sharing it. Want to spread knowledge in their own organization in the same way. Discuss how third-party users can use this message.
    • [Write 3 hashtags on the board]that represent your thoughts about mediawiki]
    • extension quality, reuse (+3), clean API (+2), awesome, free knowledge (+1), free software (+2), free society (+2), documentation (+1), money, algorithm, ROI, international, mission, removing barriers (+2), growth, performance, ecosystems, open source (+5), security, installation (+4), humans, media, wiki, wikis for everyone (+2), better tech support, innovation, knowelege equity, ease of use, stability, dissapointment, standards, open, participatory (+2), facts, configuration, extension management (+1), multilingualism/18n, communities (+2)
  • [cindy] Open questions: is it necessary for third-party users to keep the core stack as simple as possible (pure LAMP) or is it ok to use non-boring things?
  • [thedj] let's start with "why should WMF care?" let's all try to answer it in the etherpad
  • [cscott] WMF mission is Wikipedia, and focusing on software by itself not in service of Wikipedia is a misuse of donor funds - not what I believe, but that's the position
  • [cindy] sum of all knowledge is more than just Wikipedia
  • [mark] Wikipedia is not the core, [train analogy]
  • [cindy] third-party developers who use MediaWiki could contribute and improve the ecosystem, and benefiting WMF. Potential for market penetration of MediaWiki, people who do it currently through a labor of love, hard to upgrade/install/maintain, hard extension development. HIgher MediaWiki penetration is better for everyone.
  • [matanya] if we take for granted fact that WMF should care, who is the user? who should we care about?
  • [thedj] what are the basic features needed by communities? why do we still have incubator wiki? why don't we have a "cloud" where you click create a wiki, and then have your own experiment/incubator. within limits of course. it should be a lot easier to enable/disable specific features, not because of 3rd party user, but because it makes [WMF] a 3rd party user. By not supporting the 3rd party users, we are hurting ourselves because these things are not logical for ourselves
  • [dbarratt] WMF mission is "educational content under a free license"...way I read it, mission prevents us from caring
  • [mark] meta comment
  • [cscott] interesting question is how much should WMF care? I think we should have 1 FTE be in charge of the "external wikis department" judge # of users running full featured WMF install (incl. VE, etc.) and # of external contributors to MediaWiki code. Those people who learn how to edit wikis in their corporate wikis are now ready to be Wikipedia editors. [applause]
  • [markus] (re: dbarratt) lots of small wikis that are under free license, need more data. [...I missed this part]
  • [moriel] I want to challenge that this isn't out of our mission. What other tool do people have to do this besides wikis? It sounds to me that this is absolutely our mission. People with low resources want to upload something, how do they do it? wikis. Debate on MediaWiki vs MediaWiki plus, ok. Giving people a tool to do this well (spread knowledge) is definitely part of our mission.
  • [james from NASA] wouldn't it be great if people who had never edited Wikipedia could look at it and say "oh I know how to do this" because they've done it at work? That is part of the mission.
  • [kaldari] if we liberally interpret our mission, we should develop MW because its the best way to disseminate free knowledge. If we follow that, there are plenty of things that WMF should be doing to spread free knowledge, which may be more beneficial than the same amount of money developing MediaWiki.
  • [krinkle] Do we consider 3rd party MW installs as part of spreading knowledge? Is that a success that we can take credit for? Or is just that they could have used a tool and they picked ours. / What are our typical 3rd party wikis? Corporate wikis? Or are they directly competing with Wikipedia e.g. wikiHow/Wikia. Our content model is long form text and you can use many different tools for that. Not really a wiki network, and text model makes that hard.
  • [melody] MediaWiki has to fit in an organization's stack of tools, and how it integrates with their documentation platform, communication platform, email, and so on. How does it fit into our existing stack, and what about the other things? e.g. jira/fb workplace/slack/etc.
  • [lesek] We're all fine with the mission, no one is trying to challenge it I think. Other people use our software and show that it works, and WMF can use it ourselves
  • [moriel] re: kaldari, yes other things we can do, but we're already developing MediaWiki. Other tools like Drupal/WordPress/joomla, but wiki is a way of communicating. WordPress you're talking to your users. Wikis are inherently a collaborative tool, even if you lock it. We're doing a bad job of saying publicly what is the wiki model and cultural concept. People will make their stuff collaborative rather than one-sided.
  • [cindy] agree with moriel. made prototype in MediaWiki, people asked for it in confluence, but nope because MW extensions are so powerful.
  • [dbarratt] don't conflate knowledge with educational content. Doing something b/c we're already doing something is sunken cost fallacy, [something about pidgeons]
  • [brigit] [collaborative software (Mediawiki) is our USP, and this is missing in the movement strategy - we should start advertising the use of Mw as a tool to share knowledge and collaborate]
  • [mark] re: dbarratt, disagree you can use anything other than MediaWiki to run Wikipedia.
  • [tgr] If you don't think 3rd party usage is important, you're not here. How do we convince skeptical people to agree with us. Two main arguments, 3rd party wikis are part of mission is a value choice. second, if you see mission is just for Wikipedia, supporting 3rd party wikis is a business case that you get new users, more contributors, etc. Let's move in a more productive discussion. How many Wikipedians started on third-party wikis? How many volunteer developers started on third-party wikis?
  • [thedj] +1 tgr, not impossible to use something other than MW. look at MW as a platform for knowledge sharing, look at the APIs we provide. Everyone should be able to make their own installer that optimizes for their environment
  • [cindy] There is a session about architecture this afternoon.
  • [markus] wat is the cost to have a mediawiki in the case of a third party user? How many people have been recruited in other companies to take care of a mediawiki? How can we use this leverage to get more for mediawiki? Gather instrad of having multiple developements from multiple organizations?
  • [cscott] little dangerous to justify 3rd party usage, just preaching to the choir, sufficient to use current metrics that contributions from 3rd party users are good. Mention in strategy that we recognize and support 3rd party users.
  • [brion] mistake early on that we think of Wikimedia Foundation is first party user. They should be another third-party user who contributes to MediaWiki ecosystem. What makes a healthy open source project? Need multiple contributors...WMF hired everyone, see MW as thing to run our sites, and not seeing MW as its own product. Would like to see more involvement in the developmentmaintenance burden from other users too.... Other users *have* created some extensions highly used elsewhere but the WMF don't even notice it, as it's not in our interese area... Someone needs to think about how to maintain MediaWiki for multiple users. Not sure yet how to solve, but it needs solving.
  • [cindy] There's not much money in release process, but wow what could we do if we did improve that process. Another organization of doing MediaWiki as a software platform.
  • [mark] MW Foundation comes up, how many people see it as useful. (maybe half hands go up, some were not sure)
  • [cscott] What would be the position statement for that Foundation?
  • [matanya]
  • [cindy] follow-up: is this self-selection bias in that we're all on board with supporting 3rd party?
  • [thedj] I don't trust foundation to act in best interest of MediaWiki as a software platform. It's cynical and bad that I have to say it, but its not that crazy. Would be healthy if Foundation didn't have to make choice of taking on development of MW as a software platform.
  • [cscott] I could trust WMF to do that, but it has to be explicitly stated in mission/etc. Right now be ignored not out of malice, but oversight.
  • [krinkle] Not doing it well right now, but WMF really could. question of resourcing, even accepting other people's contributions have a non-zero cost, question of archi direction, etc. Now that we're agreed that WMF should care, why should 3rd party users care and use MW? Not because of marketing, its the software. Something about making it more decentralized. Instead of starting with a blank slate when you install a wiki, connect it to other things somehow. (cf: Mastodon/GNU Social connects you to other instances)
  • [samwilson] 3rd party users are Wikimedia chapters. Not outside Wikimedia movement at all,
  • [leszek] if we say WMF mission is Wikipedia, then ....
    • : Break
  • [cindy] discussion going forward is actionable steps on how to move forward
Retrieved from "https://www.mediawiki.org/w/index.php?title=Wikimedia_Developer_Summit/2018/Supporting_Third-Party_Use_of_MediaWiki&oldid=3632573"