I've (at least temporarily) added this to the "Handling wiki content beyond plaintext" in case we want to morph this to a discussion of Page Forms/Cargo as core features of "wiki content". As written this proposal currently seems to be something different, more "WMF should start hosting Enterprise Wiki Conferences" or something like that. That probably belongs in the "growing the community" topic.

This proposal isn't about hosting conferences, it's about managing data better.

"Enterprise MediaWiki" is a vague concept, and this might lead to a vague discussion here. The different extensions mentioned point to very different use cases and target audiences.

If the topic is about managing data better (beyond plaintext), then that is a clearer discussion.

If the topic is "not developed by the WMF", that is also touched in another session proposal T147892: How to unleash the power of 3rd party extension developers.

If we want to address specific use cases like organizing calendars or conferences with MediaWiki, then maybe specific sessions about those would make more sense?

@Qgil - I don't think "Enterprise MediaWiki" is that vague; the way I use that term, it refers to a fairly specific set of extensions. Of course, others might use the term that different (not that it's a term in widespread use).

Do you mean that the different extensions I listed (Cargo, Page Forms, etc.) each have their own use cases? If so, that's not true - these extensions are meant to be, and generally are, used together.

Yes, this is about managing data better within the WMF. I wouldn't use the term "beyond plaintext", though, since the wikitext being used consists contains of just standard components like templates and parser functions. The difference comes in how the wikitext is edited, and queried.

Yes, this topic covers 3rd-party software, just like that other proposed session, though that one is about developing software, while this one is about using it.

I don't think specific sessions about managing calendars, conferences etc. would make sense, since the software being used, and the way in which it be used, would be quite similar in all cases. It seems gratuitous to take up more than one session explaining this software.

In T149612#2776085, @Yaron_Koren wrote:

@Qgil - I don't think "Enterprise MediaWiki" is that vague; the way I use that term, it refers to a fairly specific set of extensions. Of course, others might use the term that different (not that it's a term in widespread use).

Could you define how you use it, then? It's just a set of extensions? What is the purpose of that set and what makes them "enterprise". There's a missing step here :)

@greg - yes, it's a set of extensions, or MediaWiki plus that set; the key extensions being Page Forms, Cargo and Semantic MediaWiki. To quote from the proposal itself, "I collectively refer to such extensions as 'Enterprise MediaWiki', since they can be used internally by organizations for various data management purposes." Yes, I made up this term, and I admit it's rather self-indulgent of me, since I wrote Page Forms, Cargo and some of the other, smaller extensions that I would classify in that group. On the other hand, we had the first-ever "Enterprise MediaWiki Conference" earlier this year (we're now planning the one for next year), and these extensions were a frequent topic of discussion, so there's at least some factual basis for saying that these extensions are correlated with the use of MediaWiki as enterprise software.

https://www.mediawiki.org/wiki/EMWCon_Spring_2016

If "MediaWiki Enterprise" is basically a product, there is a conference already about it, and an interest in proposing it for use in Wikimedia, then I think a wiki/web page somewhere explaining the product, features, existing users... would be useful. Even a demo instance somewhere i.e. Wikimedia Labs?

That's "Enterprise MediaWiki", and I don't know if I'd call it a product per se, but certainly more marketing-type documents would be useful, yes. But most of the extensions I listed have their own listings of notable users, demo sites, FAQs and so forth. Here's one example:

https://www.semantic-mediawiki.org/wiki/Wiki_of_the_Month

I dont know if I agree with Yaron's premise, but i think this sort of thing is an important conversation to have, so count me as interested in this session

Expected outcome

• Increase ease of data entry, findability, calendaring etc. on Wikimedia sites like mediawiki.org and the Wikimania sites.
• Decrease creation and use of custom, limited-purpose software.

This is not the expected outcome of this session, but the expected outcome several steps further down the line. What do you expect to achieve between now (with the online discussion) and the end of the Summit (with the session in San Francisco)?

"Expect" is probably too strong a word, but ideally, this talk could help convince the necessary people to:
(a) install some or all of these extensions on "internal" WMF sites like mediawiki.org, the Wikimania sites and Meta,
(b) make greater use of MediaWiki (plus these extensions) for non-project-management tasks currently done with Phabricator (like managing this developer summit), and
(c) make greater use of MediaWiki for tasks that would otherwise be done with custom coding, like the Wikipedia Library Card Platform.

I think this discussion would be a lot simpler if we would look at MediaWiki.org, Meta, the Wikipedia Library, the organizers of Wikimania, the Wikimedia Hackathon, the Summit (and whoever else you want to add) as different potential customers, and then sell them Enterprise MediaWiki or the specific extension that each of them could benefit from.

They really are different customers. I am not aware of any person significantly involved in all of these teams. It's not even limited to the Wikimedia Foundation, since many of these spaces are are run by chapters and/or their own communities / volunteers. Having a common directive for all of them in a single stroke would require something like a strong recommendation from the WMF Board & ED, which is unlikely to happen.

The approximation to these potential customers could be done basically in commercial terms with a Wikimedia community flavor: identification of problems, value proposition explaining why this product is the best solution, running a demo (i.e. a Tech Talk showing what Enterprise MediaWiki can do, and/or demonstration of new features in the CREDIT Showcase...)

I know all this sounds utterly commercial, but ultimately we have a pretty standard situation here: a software development organization wants that a top Internet site adopts their product. Following this pretty standard path, the chances of reaching to a resolution (deal or no thanks) are imho high.

Yes, I'm aware that "the necessary people" are a different set in each case, and that for some cases, like adding these extensions onto mediawiki.org, it's a pretty large set. My sense, though, is that increasing awareness if and interest in these tools among the overall MediaWiki developer community will help to open a lot of these doors. And yes, I'm aware that this is basically a commercial proposition - though it should be noted that I'm not representing an organization here (WikiWorks is not the developer of Page Forms, I am), and of course there's no money involved. Running a demo and explaining the features are indeed what I hope to accomplish with this talk.

@Yaron_Koren This sounds to me like a good and useful session, even if it does come across slightly self-serving (your words, not mine ;)

I personally would like to understand how these extensions work together to build data entry forms and avoid custom coding.

In T149612#2821442, @Yaron_Koren wrote:

Running a demo and explaining the features are indeed what I hope to accomplish with this talk.

Why wait until the Summit for this? It would be better to provide this information beforehand, which would help starting the discussion beforehand. The Wikimedia Developer Summit is mostly about discussions, not presentations or tutorials.

The idea is to have a good conversation moving forward well beyond the Summit, allowing you to focus on the key discussions during the event (from the call for participation).

My goal is for the talk to lead to a discussion about whether this is a good idea, and related topics like the merits of Phabricator vs. MediaWiki for different tasks, and to hopefully reach some sort of consensus on these topics. I don't know if an alternate forum, like a "tech talk", could serve the same purpose, though I'm certainly willing to also give a tech talk or whatever else you're thinking of.

The only WMF wiki using semantic forms is wikitech (for VM documentation), and it is not regarded as a successful feature. Maybe @demon or @bd808 has more to say on this.

In the past there's been many concerns about enabling SemanticWhatever extensions on Wikimedia wikis. I don't think any discussion should focus on the particular implementation, but if we want features "like" these (i.e. Focus on use cases first)

In T149612#2823676, @Tgr wrote:

The only WMF wiki using semantic forms is wikitech (for VM documentation), and it is not regarded as a successful feature. Maybe @demon or @bd808 has more to say on this.

I don't particularly like the implementation of it on Wikitech, no. I'm also not super interested in this conversation.

In T149612#2823837, @Bawolff wrote:

In the past there's been many concerns about enabling SemanticWhatever extensions on Wikimedia wikis. I don't think any discussion should focus on the particular implementation, but if we want features "like" these (i.e. Focus on use cases first)

I think on a very high level everyone agrees that MediaWiki needs to get better at handling structured data; T107595: [RFC] Multi-Content Revisions will be a big step in that direction. (Its use case list also has relevant things.)

Re: the use cases mentioned in this task:

• for extension management and other structured MediaWiki documentation, we can probably just use Wikidata which is much better integrated with WMF wikis, both technically and socially (see also wikidata:MediaWiki.org)
• calendars and events: I guess this could go both ways, as integration with Phabricator tasks and integration with wiki pages both have their uses. Using tasks for tech conference submissions makes a lot of sense but wikimania wikis could definitely use something more structured.
• other: some things are really clunky right now, e.g. the deploy calendar on wikitech (then again, wikitech does have semantic forms, but nobody attempted to use it for the deploy calendar, which I guess says something about its usability) or the new repo requests. OTOH not everything has to be handled by Wikimedia. Having an on-wiki audit trail is important, but the user interface could easily be handled via one-off external tools (which then update the wiki page via OAuth). With good frameworks and project templates (there is at least slimapp for PHP) setting up such a tool should not be any more difficult than setting up a set of semantic forms and templates on-wiki.

I think on a very high level everyone agrees that MediaWiki needs to get better at handling structured data;

I think the debate is ultimately around if users should be defining the structure, or if developers should be defining the structure.

In T149612#2823896, @Bawolff wrote:

I think the debate is ultimately around if users should be defining the structure, or if developers should be defining the structure.

Also whether development should happen in MediaWiki template syntax or something saner :)
MCR + JsonSchema + PageForms + Lua would be a path towards user-defined structure without all the parser function insanity, for example.

In T149612#2823896, @Bawolff wrote:

I think the debate is ultimately around if users should be defining the structure, or if developers should be defining the structure.

Also whether development should happen in MediaWiki template syntax or something saner :)
MCR + JsonSchema + PageForms + Lua would be a path towards user-defined structure without all the parser function insanity, for example.

Thank you all for these comments. There's a lot to respond to here; I'm not sure where to start. In my view, this discussion underscores, in a few different ways, why having this talk would be so important. First, it would (hopefully) help to dispel a few myths that keep popping up about this software:

1. The software I'm talking about is the "Semantic *" suite. That was true until 2015, but now there's also Cargo - an alternative to Semantic MediaWiki; and the Semantic Forms extension was recently renamed to Page Forms, and no longer relies on SMW. I don't think there's anything wrong with using Semantic MediaWiki, but my planned main focus will be on different software.
2. The WMF decided a long time ago not to use Semantic MediaWiki on its wikis. This is a pernicious one that keeps coming up. It's very important to note that "Wikimedia wikis" can refer to two very different things: the massive, multilingual wikis like Wikipedia and Wiktionary, and the much smaller, quasi-internal wikis like mediawiki.org, Meta and the Wikimania wikis. The decision to not use SMW was in fact made, but it related only to the first group - it was decided to use Wikidata for those, and rightly so. But that's a very different decision from what should be used on, say, mediawiki.org.
3. The Wikitech wiki's desire to switch away from SMW proves that this software is not a good fit. First of all, Wikitech is not entirely the only Wikimedia wiki to make use of SMW - translatewiki.net, which is a quasi-Wikimedia site, makes use of it successfully (see https://translatewiki.net/wiki/Map_of_translators). Second, as noted before, I'm actually focusing on Cargo, an easier-to-use alternative to SMW. Third, Wikitech has their own set of requirements and technologies, due to being an operations site, which do not apply elsewhere. Fourth, their usage of the software could certainly be improved (they've never asked me about it, as far as I can remember). And fifth, for all the discussion they've had about moving away from SMW/SF, they are still using it.

But there's another point here, about the nature of decision-making at the WMF, which I think again is a strong argument for hashing out this discussion in person. There's a certain amount of "analysis paralysis" that happens, I guess due to the WMF being at the same time both so open and so technical, which can sometimes make it hard to implement what I see as common-sense solutions. (I don't think this is a controversial statement.) @Tgr - I don't mean to single you out, because the decision-making problems are certainly not due to you, but you do happen to provide what I see as a good example. You've brought up Wikidata, MCR, JsonSchema, Lua and SlimApp as alternative technologies to use, in place of (I think) my suggestion of Cargo + Page Forms. Now, Cargo and SMW can in fact both work with Lua, but in general I think my suggested extensions are the better approach. But, in part due to the sheer number of possible alternative solutions, no decision has been made; and so, in 2016, users on mediawiki.org and elsewhere are still hand-editing infobox calls and doing primitive text searches to try to find information, while non-technical organizations with basically none of the WMF's collective MediaWiki knowledge have been successfully using better MediaWiki-based data solutions for nearly a decade now.

For the purposes of the developer summit, I think concentrating on a particular use case would be helpful. Which particular extensions are you proposing to install on which particular wikis, and what would be the benefits of doing so? Pick one or a small number of wikis as examples. Then we can reasonably structure a discussion about whther (say) Cargo + Page Forms is a better solution to <problem X> than Wikidata or Lua or whatever @Tgr would suggest.

I'd avoid getting into Semantic MediaWiki -- even mentioning it has the potential to derail the conversation. AFAIK it wasn't "just" features which made semantic mediawiki a bad fit, but performance and maintainability issues as well. Let's just put all that to one side if we can, since you indicate that Semantic MediaWiki is not a dependency of your extensions, and that Cargo is your preferred implementation of that functionality any way.

Also, it seems like it would be clearer to call this session "Page Forms + Cargo", not "Enterprise MediaWiki", since the latter misleads people into thinking they know what the session is about.

I took the liberty of modifying the session title and description slightly to focus it on Page Forms and Cargo.

@cscott - were those rhetorical questions, or questions you want me to answer here? I feel like I basically provided all that information in the talk proposal...

Thanks for the suggestions about Semantic MediaWiki. Do you have any personal experience with SMW, or is your knowledge just hearsay? This is the first I've heard about SMW performance being an issue for the WMF, for instance.

Am I allowed to change the talk's title back if I want to, or is it fixed now?

You can change the talk's title if you feel strongly, but as the session facilitator I'm trying to help you. ;) Folks have fixed ideas about what "Enterprise" and "Semantic MediaWiki" mean, so I think you'll stimulate better discussion if you concentrate on the specific extensions you are proposing, instead of letting the discussion wander into whether or not MediaWiki is "enterprise software" and war stories about SMW.

Can I confirm you are planning to attend the dev summit?

I'm not trying to shut down the discussion, and sure, it would be nice to have a showcase of those extensions, but IMO there is no decision paralysis at all, Wikimedia has simply chosen a different path. SMW was evaluated and decided against when Wikidata was planned; we are preparing to deploy Wikibase to Commons for handling local structured data; the MCR RfC has been accepted and the WMF is pursuing a grant which would, amongst many other things, fund its development. The use cases of these tools are not quite the same as semantic forms, but have significant overlap, so a strong justification would be needed to have both deployed.

Specifically for mw.org infoboxes, I was hoping to create Wikidata properties from their parameters, and then move the data there (admittedly the main reason is that no new software needs to be installed that way - although I think that's a decent reason, every new extension adds to the maintenance burden). I was planning to bring that up in the T149372: MediaWiki Documentation session.

@cscott - alright, cool; I just changed the title back. I think this is the better title because (a) I think it's useful for WMF people to get a sense of how MediaWiki is often used in the enterprise, (b) I think "enterprise MediaWiki" is a useful term to get into more widespread circulation, and (c) I do also plan to talk about other MediaWiki extensions, like Semantic MediaWiki and External Data.

As for war stories about SMW - I would actually love to hear these, since I don't think I've ever heard from anyone at the WMF about it. Though my guess is that this wouldn't take up a lot of time during the talk, since as far as I know there have only been around five people at the WMF who have any kind of firsthand experience with SMW.

If this talk gets accepted, I do plan to attend the dev summit; otherwise I'm not sure.

@Tgr - alright. For mediawiki.org infobox data, I do think Page Forms and Cargo is the much better solution than Wikidata, for at least these reasons:

1. Users wouldn't have to go to a different site to make changes.
2. Page Forms provides a highly intuitive data-entry form, whereas the data entry within Wikidata is obscure and complex.
3. Similarly, doing queries within Cargo is fairly straightforward (and queries can be embedded inline), whereas queries in Wikidata are complex and their results can't be embedded.
4. Cargo provides an easy-to-use drill-down interface for browsing through all the data to find specific pages (see http://discoursedb.org/wiki/Special:Drilldown/Items , for example), whereas Wikidata/Wikibase has no such functionality.
5. Using Wikidata puts you at the mercy of a separate community, which can decide which entities (i.e., extensions) are worthy of inclusion and which aren't, and which properties/attributes can be specified.
6. Installing Page Forms and Cargo on mediawiki.org will also allow better handling for data that will most likely not includable on Wikidata, like Wikimedia talk proposals and events.

As for using MCR, i.e. moving infobox data out of page wikitext and into storage attached to each page (if I understand it correctly) - I have my doubts as to whether this will happen any time soon, but if/when mediawiki.org (and other MW sites) ever switch to it, they would still benefit from having data-entry forms and queryable data storage. Perhaps by the time MCR is working and starting to get usage, Page Forms and Cargo will support it as an alternate storage method.

I just changed back the task description - I admit that "How to grow our technical community" is not a perfect fit for this topic, but on the other hand, "Handling wiki content beyond plaintext" doesn't seem to make sense, since these extensions all just deal with standard wikitext (other than the form definition syntax, though that's also plaintext).

...plus, the "beyond plaintext" topic implies that this a discussion about future software development, though it's really just about making greater use of existing software.

In T149612#2833879, @Yaron_Koren wrote:

If this talk gets accepted, I do plan to attend the dev summit; otherwise I'm not sure.

Note that the "acceptance" is only about sessions to be pre-scheduled. All proposals will have enough time and space to be run as Unconference sessions.

In terms of room capacity and configuration, what would be your preference?

• The biggest room in theater configuration (up to 200 people, only chairs, no tables) and required video recording (meaning also that people have to wait for the mic to speak etc).
• A big room in classroom configuration (up to 70-80 people, chairs and tables) and required video recording (meaning also that people have to wait for the mic to speak etc).
• A big room in classroom configuration (up to 70-80 people, chairs and tables) and optional video recording (i.e. only recording the initial introduction but then relaxing things during the discussion, or no recording at all).
• A smaller room, flexible configuration, optional video recording...

Alright. Any of the first three sound fine - I definitely want the talk to be recorded. I guess a bigger room is always better, but I don't know if more than 80 people will be interested in hearing this talk.

So I'm inclined to give it a scheduled slot, in the "beyond plaintext" topic area. It would be helpful if you'd keep that topic in mind when structuring your talk, and you don't seem to be paying attention to my hints about how to focus your presentation and give it a title which will attract a useful audience.

It seems WikiApiary will become a Labs project (T149874), making improvements to it easier. Currently it is a prime example of a wiki made very user-unfriendly by (mis?)application of Semantic X extensions. How that situation might be improved could be an interesting topic.

@Tgr - what do you find unfriendly about it? This sort of feedback is helpful in planning my talk.

Just a gentle reminder that "beyond wikitext" is one of the focus topics for this dev summit. I expect those attending will be most interested to learn more about Cargo and Page Forms, especially in terms of work flow and other use cases not covered by wikidata/wikibase's representation of structured data. You will be fighting an uphill battle with the "Enterprise MediaWiki" title; many may have preconceived notions of what "enterprise" means.

Well, I guess we should talk about it, because I still don't think this talk relates to the concept of "beyond wikitext". Page Forms modifies template calls within pages, and both Page Forms and Cargo define parser functions - this is all strictly standard wikitext. It's true that Page Forms has its own syntax for defining forms, but that's really just an implementation detail, I think. "Beyond wikitext" to me implies storing stuff like XML, image data and other specialized information within wiki pages, which is not what this is about.

As for preconceived notions - dispelling those notions is part of what I hope to achieve.

I know I'm late to this, and my contribution is going to be tangential, but...

In T149612#2823896, @Bawolff wrote:

I think the debate is ultimately around if users should be defining the structure, or if developers should be defining the structure.

Providing users with that power is a big selling point for PageForms, Cargo and SMW. This allows the people who are making actual contributions to the wiki to rapidly iterate over prototypes for data storage structures.

Yes, this means that some things they develop will not be ideal or close to it. However, if they can get past the learning curve, this gives them the power to implement what they need when they need without relying on developers and worrying about communication failures.

This is a big reason for the adoption of the extensions mentioned here. It all comes down to cost: the extensions are less expensive than a developer and provide flexibility that the people who are using MW to capture knowledge need. Enterprises are able to make better use of their current people by providing them with these tools instead of investing in the overhead of developing custom software.

To the owner of this session: Here is the link to the session guidelines page: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Session_Guidelines. We encourage you to recruit Note-taker(s) 2(min) and 3(max), Remote Moderator, and Advocate (optional) on the spot before the beginning of your session. Instructions about each role player's task are outlined in the guidelines. The physical version of the role cards will be made available in all the session rooms. Good luck prepping, see you at the summit! :)

Note-taker(s) of this session: Follow the instructions here: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Session_Guidelines#NOTE-TAKER.28S.29 After the session, DO NOT FORGET to copy the relevant notes and summary into a new wiki page following the template here: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Your_Session and also link this from the All Session Notes page: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/All_Session_Notes. The EtherPad links are also now linked from the Schedule page (https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Schedule) for you!

Session Notes: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Bringing_%22Enterprise_MediaWiki%22_to_the_Wikimedia_Foundation

Hi @Xephyr826 - here are the Etherpad notes taken during this session: https://etherpad.wikimedia.org/p/devsummit17-enterprise-mediawiki - Would you mind folding them in, or linking to them on the MediaWiki page, so we have a single reference point for this session? Thank you!

Well, just the installation of Page Forms and the rest, on mediawiki.org and other sites. But I don't know if that counts as an outcome for this task specifically.

In T149612#2930679, @MelodyKramer wrote:

Hi @Xephyr826 - here are the Etherpad notes taken during this session: https://etherpad.wikimedia.org/p/devsummit17-enterprise-mediawiki - Would you mind folding them in, or linking to them on the MediaWiki page, so we have a single reference point for this session? Thank you!

I dumped the etherpad notes into mediawiki.org, but it still needs some formatting love.

In T149612#2967913, @Yaron_Koren wrote:

Well, just the installation of Page Forms and the rest, on mediawiki.org and other sites. But I don't know if that counts as an outcome for this task specifically.

The creation of the tasks requesting the deployment of these extensions in MediaWiki would be the direct outcome of this session. Do you want to create them?

In T149612#2975881, @Qgil wrote:

The creation of the tasks requesting the deployment of these extensions in MediaWiki would be the direct outcome of this session.

If extensions have not been deployed on the WMF cluster before, see https://www.mediawiki.org/wiki/Review_queue for the process.