Requests for comment/Branching

This request for comment proposes a MediaWiki extension to allow branching histories for article content.

Overview
Please see the IdeaLab proposal for a human-readable explanation of this initiative.

Implementation
A very basic prototype, Extension:Nonlinear, can track branches and display them in the history log. There is no UI to create branches, yet.

Plan

 * 1) Gather requirements and community feedback, especially looking for help with the UI and finding the minimal useful scope for an initial release.
 * 2) Write an extension to create and manage branches
 * 3) Integrate with protection and antivandalism extensions
 * 4) Extend schema to provide enhanced metadata and multiple inheritance

UI changes
The edit page will always be available.

If the user does not have permission to edit the live version of a page, the "Save" button will change to "Submit for review".

A "Save draft" button may appear in the edit page. The effect would be to save the current text to a user sandbox page, where it will not appear in the site's "Recent changes". When editing is resumed and then completed, it can be saved under its original article name.

Schema changes
It has been pointed out that the current "revision" table already supports arbitrary directed graphs, so our extensions will simply provide extra information about these links. If the extension is disabled or uninstalled, the remaining links should not corrupt the database. Any revisions not appearing in the live article (trunk) should appear in the article's history page with a branch marker.

In later stages of implementation, we will need to improve the schema in order to support merging and other metadata.

Review and merge workflow
We'll have to enhance the review workflow in order to support more complex types of merging.

Divergence
We should build a system which encourages frequent merge/split resolution. The possibility of parallel articles is interesting, but would be a usability disaster. Also, because merging patches in non-line-based documents is not a well-studied problem, and prose is very sensitive to context, the opportunity for merging recedes as branches diverge.

Branching model
There are many options here. I am prejudiced towards a system like Wikimedia's git/gerrit review, where changes are always based on the currently accepted revision, "master". This solves the problem in which vandalism and its rollback are leapfrogged over legitimate changes. A major drawback is that patches can get lost or ignored, and become stale relative to master, causing the divergence problem above.

Complexity
It's probably best if this feature is mostly transparent to editors and readers. Branching is the cause of much confusion in source control systems, and there is little agreement on the best practices, even for the most basic tasks like development and releases. Ideally, a branch is created by the backend whenever necessary (i.e., whenever the trunk does not track the change), according to predetermined logic.

Interwiki / Closed wikis
This concept could be used across wikis, if the schema supported it.

For example, I find a protected page on a wiki which does not have the nonlinear extension. I copy that page onto my home wiki, using a tool which preserves origin metadata. I can edit, and publish the altered page and diff for review, locally.

No common ancestor
If revision metadata is lost or damaged, it would still be nice to have some ability to reintegrate the lost changes. For example, a page is copied into a sandbox incorrectly, then edited. We should be able to diff any pair of articles, and merge on a per-chunk basis.