Talked to 6 people specifically about this set of questions at the Hackathon to gather some initial input. Here are the notes copied over from the Etherpad:

Interview 1.)

Main area of contributions: MediaWiki API, extension infrastructure/ecosystem
Tenure: > 15 years
Affiliation: Staff + Volunteer

What is one thing we as engineering teams and MediaWiki developers have been doing well and should continue doing?

• We're getting things done
• challenge: not necessarily as part of the day-to-day job
• People will work together to respond to incidents/fix urgent things (staff + volunteers together)

What is your biggest pain point/concern about MediaWiki?

• Lack of ownership/stewardship.
• Very few actual maintainers
• Teams can just say that they are not/no longer responsible
• No sunset plans

What is one thing you wish you could be doing in MediaWiki?

• Provide configuration as a platform capability and standardise how people can configure features onwiki

What is one thing we should ask you about MediaWiki?

• Bigger issue: How to know whom to consult/talk to about what
• General development practices - tooling, infrastructure we use.
• Knowing where to find things, where the docs are.
• How people do things onwiki, why we do things in a certain way (important to also challenge that)

Interview 2.)

Main area of contributions: MediaWiki reuser; deploying/managing MW instances
Tenure: 8-9 years (different areas of contribution)
Affiliation: Chapter staff + volunteer

What is one thing we as engineering teams and MediaWiki developers have been doing well and should continue doing?

• Things generally work - site is up and running
• Good that it stayed Open Source

What is your biggest pain point/concern about MediaWiki?
MediaWiki for 3rd party seems to receive no official support

What is one thing you wish you could be doing in MediaWiki?
Ideal situation for me would be: I don't need to do anything :-)

What is one thing we should ask you about MediaWiki?
Which functionalities/capabilities should stay in core ("what to platformize"), which should be extension, extra components?

Interview 3.)

Main area of contributions: Growth features, production deployments, implementing config changes
Years involved in MW development: 7 years ago - first config changes; about 4-5 years ago first patches to MW
Affiliation: volunteer, chapter, wmf

What is one thing we as engineering teams and MediaWiki developers have been doing well and should continue doing?
Ability to quickly write Wikimedia related code and get it running on Toolforge; associated support channels work well too

What is your biggest pain point/concern about MediaWiki?

• Finding appropriate reviewers for areas I don't work in very often
• Best case: there is an associated team, or maintainers page is up to date
• Worst case: go through past commits, try to find out who could help
• Would help to have a more granular view on who did what in different parts of MW core; have a dashboard for that

What is one thing you wish you could be doing in MediaWiki?

• A better way to authenticate across the wikis - currently doesn't work well across project wikis.
• Multi-project-actions (stewards need to do that - little support through MediaWiki itself) - some standalone applications exists; most of them may break through IP masking (not making updates etc.)

Both these projects fall into the bucket of working with hundreds of wikis at once. Having better support for cross-project actions in core itself.

What is one thing we should ask you about MediaWiki?

• Configuring MediaWiki from various ankles
• How blocking works in MediaWiki

Interview 4.)

Main area of contribution: Backend MediaWiki; historically: security; multimedia. Usually no frontend work.
Tenure: 13 years (Mw development)
Affiliation: volunteer; MW third party consultancy

What is one thing we as engineering teams and MediaWiki developers have been doing well and should continue doing?

• Is a group where you can join, raise up, just go and do things. Often don't have to ask for permission, just submit a patch (and find someone to review it) - just being able to fix things.
• Product-side: Flexible product. MW allows you to build your own workflow.
• Ability to encapsulate complexity so that less tech users don't get overwhelmed.

What is your biggest pain point/concern about MediaWiki?

1.) Code Review

• Can be very difficult to get it, sometimes code reviews can be random; need to nag people to review.
• Experience from other places: code review happens within 24h etc.
• Code review burden currently unevenly distributed - few folks do most of the reviews
• Resolving code stewardship/clarity on who is responsible for what is key for that
• Unwillingness to say no to things if something is a bad idea - the response often is just silence - better to tell people when their contribution doesn't work for this project etc.

2.) Tech Decision Forum

• Tech Decision Forum feels very frustrating and closed off. In the past a lot of more open/back and forth communication. Also acknowledging that WMF has grown a lot - hard to keep track.
• Most important thing: Knowing what's going on before things are set in stone (not expecting having a veto, but a way to provide input). Having a forum where you can voice concerns, can be evaluated etc. have a design doc repository, etc. Document decisions.

What is one thing we should ask you about MediaWiki?

• Happy to talk about any security stuff
• Knowledge about some of the more obscure extensions

Interview 5.)

Main area of contribution: core platform features, API, bots + gadgets, cross-wiki tools, Toolforge admin, web tools, developer tooling + CI, sys admin/SRE tasks, tech support, admin + onwiki editor

Tenure (MediaWiki development): 11 years, started as an editor, then pywikibot, then MediaWiki

Affiliation: volunteer, chapter

What is one thing we as engineering teams and MediaWiki developers have been doing well and should continue doing?

Recommendation: Tim’s position paper from Dev Summit 2018.

• We tend to pick stable things which pays off in the long run
• MediaWiki is a stable thing, we have a stable stack - PHP, MariaDB, Apache … - no need to learn something new all the time.
• Know who you depend on -> pick things that have solid communities (PHP, Debian …)

What is your biggest pain point/concern about MediaWiki?

1.) Maintenance constantly hangs on efforts of 3-4 people.

Work that needs to be done:

• New features (we do that)
• Bug fixes (maybe we do that)
• Maintenance (?)

Maintenance:

• Get to a place where nothing/little breaks when a new user-visible change is made
• Code style improvements that have been done are helpful, need more of that
• People just do it -> some folks are great at identifying patterns of things that need fixes and then just doing it
• Gerrit facilitates a lot of this maintenance work, not sure yet how to do that in Gitlab
• GCI (= Google Code-In, a contest organized by Google until 2019 that Wikimedia participated in) has been very helpful with this -> show patterns, then have a high number of high school students go fix these across extensions
• Need people to do small changes across code bases
• Need someone updating composer
• A more modern codebase would fasten things up for people

2.) Technical Decision Forum

• TDF failed, provides no actual way to discuss and review ideas. TechCom had flaws too, but had a process for this.
• A RFC process helps to make contingency plans, identify risks, etc. … - is standard in many projects.
• Main issue of TechCom was that it was not integrated with management

What is one thing you wish you could be doing in MediaWiki?

• Global templates/modules/gadgets
• Same kind of problem
• These things are base infrastructure for wikis

Some challenges:

• Copied all over the place
• Need updates in many different places
• Example: Someone did conversion to template styles on ENWP -> now someone would need to update that on all the other wikis

Scribunto should be considered a core functionality
https://www.mediawiki.org/wiki/Requests_for_comment/Shadow_namespaces from 2012 was an RFC to explore a solution for this problem field/use cases.

Shared tools that we already have:

• Global abuse filter
• Global blocks
• Global user page
• Global preferences

What is one thing we should ask you about MediaWiki?

1.) APIs

• Was an API maintainer
• How to get people to update tools and bots
• Does work on Toolforge, knows common patterns + use cases
• “ImageInfo”/”FileInfo” -> there are images you can’t get from the API since metadata is too big
• Add an API that is special recent changes linked
• API hasn’t had a maintainer
• Is generally stable
• A lot of low hanging fruit
• Need to clear out bug fixes

2.) Cross-wiki things

• How to get MediaWiki play well with other wikis
• Global blocks -> patch just sits there

3.) Editor needs
Is a regular editor, talking with editors on a regular basis

4.) What is core functionality
“Core functionality” is not necessarily part of MW core - would consider Scribunto and CentralAuth to be core functionality (“trap of core functionality”)

Interview 6.)

Main area of contributions:

• Mostly deals with things that come up in editing community -> tech ambassador
• Contribute things that are important, but not supported/under resourced (Kartographer, Graph extension …)
• Bug reporting/triage -> possible in a short time frame, regular small contributions

Years of involvement with MediaWiki development: Contributes since 2008, received +2 in 2010

Affiliation: Volunteer

What is one thing we as engineering teams and MediaWiki developers have been doing well and should continue doing?
Attention on linting, automated testing, how to integrate that with Gerrit -> needs continued pushing at the same level. Helps break down problems.

What is your biggest pain point/concern about MediaWiki?

1.) MediaWiki is very inaccessible

• Targeting towards one use case
• Not a very good PHP framework
• Needs better classes, better structured code; currently bad boundaries -> makes it hard to read code
• Made some steps in the right direction, but not cohesive

2.) Code Review for volunteer submitted patches

• Volunteers contribute in a different rhythm than staff -> weekends, evenings, holidays … (especially volunteers who are not students)
• Employees work in their teams, focus on specific products. Volunteers tend to work more on the edges/unsupported stuff that is also important. -> Intentional choice?
• No bigger picture how we do this

What is one thing you wish you could be doing in MediaWiki?

1.) Redo everything about file management

• Hard to test
• Complexity

2.) A better extension platform

• Inaccessible, not easy to understand how to write extensions, how to hook into it
• Might be even harder for UX designers, interface designers to onboard and understand how this works

What is one thing we should ask you about MediaWiki?

• How things touch the community. A lot of knowledge about how the community uses + feels the software. Put things into words so that both parties can understand each other. Ambassador/bringing people together.
• Can help with systemic view, generalist.

Thanks for taking the time to speak with me! - This is helpful input and was also a good test run to check if these types of questions work well for people. I’m closing this ticket now since it was a Hackathon project. Next step on the research side of things is to create a research plan + related umbrella/epic ticket in July - once the actual work kicks off. The input documented here in the ticket is a starting point and will be enhanced by yet-to-come interviews, review of existing material, and other explorations (which ultimately will end up in a first report).