Page MenuHomePhabricator

Editing files and contributing changes via web
Open, WishlistPublic

Tokens
"Mountain of Wealth" token, awarded by simon.galkov."Like" token, awarded by mpadourek."Love" token, awarded by quiddity.
Assigned To
None
Authored By
qgil, Sep 1 2014

Description

A web based code contribution process would lower the barrier for new/casual contributors, as well as technically simple improvements such as source code documentation, HTML/CSS files, and so on. GitHub has this feature and it makes a difference.

Phabricator has Diffusion, which allows you to browse code. How far are we from allowing editing a file via Diffusion, and directly from there create a patch for the related project in Differential?

This use case is real for Wikimedia, where we have a big community of gadgets, templates, bots, and docs writers used to a wiki interface but not so much (or not at all) to a Git based workflow and its tools. This could be a potential are of focus for us after we are done with our current Maniphest-centric migration.

PS: see also T5000: Using Differential with plain Git, without requiring Arc, although here the motivation is different.

(WMF ticket: https://phabricator.wikimedia.org/T409)

Related Objects

StatusAssignedTask
OpenNone
Openepriestley
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
OpenNone
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
ResolvedNone
Resolvedepriestley
Resolvedepriestley

Event Timeline

qgil created this task.Sep 1 2014, 7:05 AM
qgil raised the priority of this task from to Needs Triage.
qgil updated the task description. (Show Details)
qgil added a subscriber: qgil.
avivey added a subscriber: avivey.Sep 2 2014, 12:09 AM
chad triaged this task as Wishlist priority.Sep 2 2014, 8:35 PM

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.
scfc added a subscriber: scfc.Sep 4 2014, 9:46 PM
scfc added a comment.Sep 4 2014, 9:54 PM

@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.

qgil added a comment.EditedSep 5 2014, 3:59 PM

@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

qgil moved this task from Backlog to Details on the Wikimedia board.Sep 9 2014, 8:42 AM
Unknown Object (User) moved this task from Details to In Progress on the Wikimedia board.Oct 9 2014, 8:47 AM
epriestley moved this task from In Progress to Details on the Wikimedia board.Oct 9 2014, 11:52 AM
revi added a subscriber: revi.Oct 12 2015, 3:48 PM
vlada added a subscriber: vlada.Oct 20 2015, 1:47 PM
eadler added a project: Restricted Project.Aug 7 2016, 8:10 PM
epriestley moved this task from Backlog to Far Future on the Diffusion board.Dec 13 2016, 4:37 PM
quiddity added a subscriber: quiddity.
avivey updated the task description. (Show Details)Aug 26 2017, 9:08 PM
simon.galkov added a subscriber: simon.galkov.
hskiba added a subscriber: hskiba.May 2 2018, 1:34 AM