Talk:Requests for comment/Branching

I think I'm actually interested in something similar to you are (or at least related). I personally would really like to look into a flagged-revs type extension that works a little more like how gerrit works - perhaps over the summer when I actually have free time. However, I do find some of this RFC confusing. "Enciclopedia Libre Universal en Español" doesn't seem particularly relevant - There have been thousands of wikipedia forks. While that one is important for historical reasons of being a very early fork, its far from the only fork and doesn't really have anything to do with branching. I personally don't see the connection between release tags and rev tagging. I'm also doubtful that your proposal would exactly kill view source. You don't cover all the use cases of things being protected. (Sometimes things are protected because we literally want nobody to edit them whatsoever). Bawolff (talk) 15:34, 1 January 2013 (UTC)


 * Thank you for the very helpful feedback. I think we're on the same page regarding rev tagging &mdash; would you explain how you envision making an extension which works like gerrit?  Currently, all changes exist in a single branch, and the review process determines which revision is tagged as the "release".  So, it would be more in line with our "gated trunk" source control policy if the master branch of an article contained only reviewed changes, and unreviewed changes had to be rebased to the master branch tip in order to be merged into "production".
 * You might be right about my "forking" tangent, I've expanded that section a bit to demonstrate that they accomplished this fork with virtually no automated tools at all (therefore, such a thing is even more feasible with better tools), but I should give more examples of what would become possible with a flexible history model. Adamw (talk) 20:17, 1 January 2013 (UTC)

Edit page always available
The idea of having the edit page always available, coupled with having every revision displayed in history page, seems infeasible to me. The edit summary would be used for vandalism, spam, obscenity, trolling, etc. This is already a problem, and is dealt with by the liberal use of revision deletion, but the workload for people with revision deletion privileges would be much higher if there were no restrictions on edits to popular articles.

If revision deletion is used more heavily, or if some interface or system is provided for hiding of entire branches from the history page, then that implies a need for schema changes, since either feature would require unlimited row scanning at present. -- Tim Starling (talk) 00:02, 17 July 2013 (UTC)


 * Tim, interesting points. I think the vandalism to popular articles might actually be lessened, because the potential for vandals to profit and gain visibility will be greatly decreased.  If a vandalized revision is on an orphaned branch, the content would be invisible unless a reader intentionally browses to that revision.  Existing bots could be used to screen for offensive or harmful content such as links to attack sites, this is exactly the same problem we face today for unprotected, less popular pages.
 * The schema would have to be changed to support merging, and more advanced relational metadata between revisions. However, for an initial implementation which does not support multiple inheritance, I think the existing schema is workable.  Censoring branches can be done with a constant-time algorithm, if we simply mark each revision with the "oversight" flag, or however we do this task today.  Adamw (talk) 04:43, 7 August 2013 (UTC)