It used to be conventional wisdom that forking was the death of an open source project. We all remembered the emacs -vs- xemacs -vs- Lucid emacs wars, nobody wanted to repeat that. So we took great care to keep our repos centralized and singular.
Then git arrived, and shortly after, github. Suddenly, forking wasn't evil! Instead, creating a fork was the *very first* thing that you did when you wanted to contribute.
There are a lot of benefits to the forking model. Nobody has to ask permission! Instead of "they reverted my edit!" new editors would instead just see "they didn't immediately merge my edit" -- which is less immediately offputting, and allows for additional refinement of the contribution before merge. And further, groups can potentially build a collection of articles over a long period of time, without the need to make their initial work immediately public. (The "diff" and "merge" steps are just as important as the "fork", in order to make this model work well!)
There are number of ways to experiment with "fork-and-merge" models for editing wikimedia projects. Some concrete suggestions are [fleshed out below]( https://phabricator.wikimedia.org/T113004#1656021). Add your own, let's discuss, and we can figure out the best way to start experimenting with fork-and-merge.
Related tasks (thanks, @tgr & @awight): {T108664}; {T26617}; {T91137}; {T40795}.
This is also mentioned on the 2015 Community Wishlist Survey: [Support for version branching for pages](https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey#Support_for_version_branching_for_pages)
**SUMMIT GOALS**
* The primary goal of the summit is to agree on an actionable "next step" (or "steps", if we're ambitious), so that work on improved revision models doesn't continue to stagnate. We should leave the summit with at least one implementable feature or proof-of-concept which will advance or inform the broad goal and can be implemented before the next dev summit. Some concrete suggestions raised in this thread include:
** {T108664} (capable of operating on arbitrary revisions, hence "branch ready")
** "Write an extension which can create and manage branches." (from {T91137})
** Storage support in core ({T40795})
** "If I visit `[[User:cscott/Somepage]]` and it doesn't already exist, then it is transparently mirrored from `[[Somepage]]`. I can then make edits there." (from strawman proposal below)
* A **UX roadmap**. "How should users experience branches/forks/merges?" Since this impacts the community, I expect this to be a set of *experiments* rather than a fixed set of UX decisions. For example:
** Prototype lightweight branches with a JavaScript gadget that forks the page into user space, deploy it on mediawiki.org, and get user feedback.
** Have our design team mock up user-facing branches from T91137 (see wireframes at https://www.mediawiki.org/wiki/Requests_for_comment/Branching) into a form suitable for public comment.
** Re-envision UX for a "saved drafts" feature, which might use branching support semi-invisibly as an implementation mechanism. Perhaps mobile could be the guinea pig here, letting mobile users save edits-in-progress and continue them on their desktop devices.
* A final goal should be broad agreement on a **technical roadmap**. How are branched revisions going to be stored in core; how that in teracts with RESTBase, etc; how to represent a branching revision history. This roadmaps shouldn't dive into UX considerations or overly-specific implementation details (those are part of the "concrete next step" planning, if necessary) but we should have an envelope-sketch plan that we all agree makes sense, and which should help guide future RFC discussions on specific implementation proposals.
Note that the technical and UX roadmaps may be initially somewhat at-odds, as @Pginer-WMF rightfully points out in the comments below. The goal of this summit is just to write a blind first draft for both, so that we can then start a dialog between them. Otherwise both design and implementation get hung up waiting for the other. We don't expect to actually implement the drafts as-is, but we *will* publish and talk about them with the community and start working on reconciliation.