Adding some subscribers based on the ultimate session matrix (tm): your opinions and your contributions to this sessions are highly relevant!

Where can we start listing our thoughts? Personally, I don't like brainstorming sessions as it requires coming up things on the spot – I prefer doing the thinking myself first, doing some research if needed, and use as much time as it needs, before presenting my thoughts.

Please feel free to add your thought here in the comments on this task. Agreed that it is best to come prepared rather than trying to come up with ideas on the spot. At a minimum, it would be good if participants came prepared with answers to the two Pre-event questions for discussion listed above. An active discussion here before the event can help us more quickly come up with actionable outcomes during the session.

It seems to me that position statements related to installation and deployment, package management, extension management, have been attached to this session. In the light of this, title and scope of this session seem too narrow. Deployment and installation issues should at least be mentioned somewhere.

On the other hand, if such topics are not to be covered here, it has to be made clear when and where they will be covered, and the relevant position statements should be re-assigned.

I think doing ""why am I here?" introductions by each participant" will end up being a big time sinkhole. Getting a general idea of participant expectations beforehand would be way better. We can do that using an etherpad or on this task, whichever people prefer.

We can also use that etherpad for answering -

• What are the important unanswered questions? What are the important strategic goals?
• What critical outcomes must be achieved to answer these questions/achieve these goals?

These are big questions that need time for people to think about and articulate well. Doing this on the spot won't do this topic justice, IMHO.

Niharika writes:

We can do that using an etherpad or on this task, whichever people
prefer.

We'll end up needing an etherpad for the session anyway. I've set up
one so that we can begin working on this before hand:

https://etherpad.wikimedia.org/p/wm-dev-summit-2018-supporting-3rd-party
.

@daniel

It seems to me that position statements related to installation and deployment, package management, extension management, have been attached to this session. In the light of this, title and scope of this session seem too narrow. Deployment and installation issues should at least be mentioned somewhere.

Absolutely, those are all critical issues that we should definitely address in this session. I expected them to show up as goals that would result in "better support", but since they are all key to this session, they should probably be added to the task description to make that crystal clear.

@Niharika

I think doing ""why am I here?" introductions by each participant" will end up being a big time sinkhole.

Yes, we discussed the danger of that in a planning meeting, which is why we settled on having people introduce themselves with "3 hashtags" that indicate what they want to get out of the session. We're open to other suggestions, but I do think it is important to have a short ice breaker, especially since this will be one of the first sessions of the summit.

In T183312#3906807, @CCicalese_WMF wrote:

@Niharika

I think doing ""why am I here?" introductions by each participant" will end up being a big time sinkhole.

Yes, we discussed the danger of that in a planning meeting, which is why we settled on having people introduce themselves with "3 hashtags" that indicate what they want to get out of the session. We're open to other suggestions, but I do think it is important to have a short ice breaker, especially since this will be one of the first sessions of the summit.

Okay, I didn't realize it was also meant to be an icebreaker. I think everyone just saying aloud the "hashtags" could get confusing fast. You have no way to group related expectations nor is everyone comfortable talking amongst a huge group of people. Not to mention - everyone might not be familiar with what is meant by a hashtag in this case.

How about we either make people put down a keyword or two about "why am I here?" on a big whiteboard or use post-its on a wall for that? Then at least we can figure out recurring keywords and get a general idea of what people expect and it's gonna take much less time.

In T183312#3907621, @Niharika wrote:

How about we either make people put down a keyword or two about "why am I here?" on a big whiteboard or use post-its on a wall for that? Then at least we can figure out recurring keywords and get a general idea of what people expect and it's gonna take much less time.

To me, this sounds very much like what is meant to happen with the "three hashtags" except that you're introducing a writing component. I like having a record, so this sounds good to me.

Sounds good to me, too! Thanks!

In T183312#3907670, @CCicalese_WMF wrote:

Sounds good to me, too! Thanks!

I took the liberty to edit the task description. Feel free to modify. Thanks.

My position statement got sorted to this session, even though it's mostly unrelated to third-party use. Fortunately I have to unofficial position statements which are related, so I'll use the opportunity to promote those:

• Make MediaWiki commercially viable
• Turn MediaWiki core into an embeddable library

I think it's important to consider why developers contribute to software in the first place. I think developers have to have some sort of stake in the software.

I've noticed (anecdotally) that the volunteer developers we have are already Wikipedians. It seems like we are asking a lot, for people who are already contributing to an encyclopedia, to also contribute to the software that runs said encyclopedia. We are also taking away time they could be using to build the encyclopedia.

I don't know how many others are like this, but I don't think I've ever contributed to software that I don't use. I've also noticed that most Open Source software gets most of it's contributions (volunteer or sponsored) from it's users.

Therefor, to dramatically increase the number of contributors, we would need to increase the adoption of MediaWiki.

I think we should ask ourselves:

• How do we increase the adoption of MediaWiki in order to increase the number of contributors?
• Is increasing the adoption of MediaWiki part of Wikimedia's mission?
• If increasing the adoption of MediaWiki is not part of Wikimedia's mission... should MediaWiki have it's own mission?
• If MediaWiki has it's own mission, how do we avoid the "Automattic effect" (Automattic controls 90% of WordPress' development, effectively making WordPress its own product)?
• If we cannot avoid the "Automattic effect" would it be better for the mission to join an existing community instead of building our own?

In T183312#3915152, @dbarratt wrote:

• If MediaWiki has it's own mission, how do we avoid the "Automattic effect" (Automattic controls 90% of WordPress' development, effectively making WordPress its own product)?

That sounds like a nice place to be. I wrote this elsewhere on that topic:

Automattic is a convenient example in that it is similar to the WMF in size (in terms of employees, budget and traffic - ~600, estimated $50M and ~70%, respectively). Their 2016 report mentions 350 core commits from 65 staff members; I count 3000 commits for that year on openhub. That would imply a 10% core contribution ratio. I haven't found numbers about the wider development community (I imagine given the popularity of short-term WordPress site development contracts it's a pretty blurry category in the first place) but there are about 50K WordPress plugins, and they sell 20K+ conference tickets a year.

So maybe they "control" most of Wordpress development (not sure what exactly that means) but there's certainly no lack of non-Automattic developers working on Wordpress. Mission-wise, all else being equal, the WMF controlling MediaWiki development would be major a plus (it reduces risk). One could argue that too much centralized control alienates independent developers and thus all else is not equal, but Automattic doesn't look like an example of that.

ok, probably a bad example. what I should say is that Automattic is a privileged group. Not necessarily a bad thing, but Wikimedia is the exclusive privileged group of MediaWiki and I think it would be difficult to change, but I think it's necessary for growth of MediaWiki.

WMDE is doing a fairly major part of roadmap setting and development, and while there were growing pains, these days it seems like a harmonious relationship. I don't fundamentally disagree though, the WMF should seek to involve new parties (including non-Wikimedian ones) more proaactively. I don't think anyone ever did a retrospective on how it came to Wikia deciding to stay with 1.19 forever, but that would be a worthwhile exercise.

Just want to make sure that issues get captured that may affect architecture decisions over in other working group topics -- knowing what's truly important or necessary or difficult for non Wikimedia users will help us make decisions. Is pure lamp stack on shared hosts actually an issue? Is there a middle ground with service deployment, or tools we can help build to deploy them? Do we need cleaner interfaces for customization, different types of page handling and UI, etc?

In T183312#3916015, @brion wrote:

Is pure lamp stack on shared hosts actually an issue?

We don't know if it's an issue because we have never done serious audience research for MediaWiki as a product and thus we don't have any reliable information on who our users are. I don't think it's reasonable to expect a devsummit to come up with answers to questions like these in the absence of data (it sure didn't work for the last four summits or so).

I'd like to put in a plea for an "instant wikidata" feature rather like "instant commons", so that third party users are not required to download, install and keep in sync our large and growing ever larger wikidata repository in order to maintain copies of small wikis or set up their own which rely on the same properties. @Addshore has some old patches that provide this functionality as a proof of concept but they are likely bitrotted by now.

@Addshore has some old patches that provide this functionality as a proof of concept but they are likely bitrotted by now.

They probably still work or would be trivial to get working again.

The relevant ticket is T48556.

For your watchlisting/cleaning/discussion interests the etherpad notes were copied to https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2018/Supporting_Third-Party_Use_of_MediaWiki