There's a long discussion on this off-ticket, but the summary is:

• This is blocked, technically, by T182.
• This is generally not a use case we're excited about, although it may be easy enough to implement a simple version after T182 that we end up building some basic support.
• We do not currently plan to ever build a fancy web-based IDE.

I've generally seen three major use cases in discussions about this feature:

1. Typo Fixes: Lightweight usecase where users want to fix typos they spot while browsing code. This is the most common motivation.
2. Nontechnical Users: Midweight usecase where non-technical or semi-technical users edit HTML, documentation, or other resources which aren't really program source code. This comes up occasionally, although the details vary a lot from case to case.
3. Web-Based Development: Heavyweight usecase where semi-technical or technical users edit source code to fix bugs, implement features, etc. This comes up very occasionally.

The major concerns with implementing this feature are:

• In all use cases, the inability to test, run, or preview changes before committing them. After Drydock (T2015) and Releeph we may be able to improve this with a Sandcastle + Pull Request workflow, which would make the lightweight and midweight use cases more palatable.
• In all use cases, the complexity of handling merge conflicts from the web UI.
• For the heavyweight use case, massive technical implementation cost of a web-based IDE compared to little real interest from technical professionals.

@epriestley: In Wikimedia's case (AFAIUI), tests & Co. are run by Jenkins, so that's not an inability to run them. For example, with the existing Gerrit instance, web edits of the commit message trigger new Jenkins runs. (NB: I didn't searched too much what Drydock and Releeph are, but they don't seem to take over Jenkins' role.)

My general concern here is that I want to focus our efforts on building the most valuable features. I don't want to spend a lot of time and effort building something which isn't very useful and takes a long time to build when we could be building something more useful that's easier to build instead.

I don't think these workflows are necessarily bad, or that they don't have a place, but I believe they are very low value and have very high implementation complexity, and that if we did build them they would have a huge ongoing support cost for a very long time. There are many features that I think are simpler to implement, are more valuable, or both, and I'd prefer to build these features first.

It sounds like WMF has some unusual use cases which might make this feature more valuable, but we believe most installs do not have these use cases.

Or, put another way, I estimate the cost of this feature is far greater than all other features WMF has ever asked for combined, and that it's also near the bottom of the list in terms of utility to other installs and overlap with the "natural" upstream roadmap. This makes it very hard for us to get excited about, and if we did prioritize it it would be at the cost of everything else.

@epriestley, understood. We have consensus about the importance of gadgets in the MediaWiki context (they are important), but we don't have consensus about the best way to organize code review for them, since the development process is currently very light compared to the development of MediaWiki core and extensions, with Git, CI, and all. Using Phabricator is one of the options we have on the table, and it is not even the current forerunner (partially thanks to your feedback).

In case you are interested in the Wikimedia discussion, see Implement a sane code-review process for MediaWiki JS/CSS pages on Wikimedia sites