It used to be accepted wisdom that "forking" a community project was a terrible thing to do. Once content was copied, changes to the different copies could never be reconciled. So we pioneered centralized projects with centralized version control: on Wikipedia, there is *one* copy of an article. Every user edits the central copy, and changes are propagated immediately.
Around 2005, that model began to be challenged. Today, "fork and merge" models are prevalent for software development -- there is no centralized authority, instead on sites like github, every user has their own copy of a community project. Excellent tools to visualize changes and contribute them "back upstream" ensure that everyone is working together and the project is not fractured.
One unexpected side effect: since making a personal "fork" was the *first thing* you do when you want to contribute, the pressure of immediate visibility of edits is reduced. New contributors don't get confronted when an immediate (and seemingly unfriendly) revert when they initial attempts are not perfect -- instead they can be encouraged to further develop their ideas in their own personal fork. Thus barriers to entry are reduced and newcomers are not made to feel unwelcome.
This discussion will explore the "fork and merge" model in the context of Wikimedia projects. Can we expand the power of the "Draft" namespace? How do we guide a new editor through preparing a "draft" and submitting it? What's to prevent hostile or biased forks? What are the impacts on our communities and our social mechanisms?
Purpose
To explore decentralized content creation mechanisms and consider how they might be applied to our projects. To find the benefits and potential flaws of this model, and identify promising initial projects that can be done.
Targeted participants
Editors. Those involved in edit wars. Folks who want to build welcoming spaces.
Relevant experts
Those familiar with user studies of newcomers and their experiences first contributing to the project.
Preparatory readings or materials
https://phabricator.wikimedia.org/T113004 contains a technical discussion, which may be useful for those who are familiar with git, github, and the like. However this discussion is intended to be *non*technical!
Questions & Comments 24
Hi en:User:cscott, thank you for your excellent proposal. Maybe you can look at the description again and make sure this won't be a presentation but in fact a discussion? Thanks, --Gnom (talk) 11:04, 17 April 2016 (UTC)[reply]
Although you say that the discussion should not be technical, it feels a lot like it could easily diverge into a technical yes-no discussion. Does this go beyond a pure theoretical discussion? I'm doubtful. Effeietsanders (talk) 09:24, 20 April 2016 (UTC)[reply]
Hi, User:Gnom and User:Effeietsanders! Thanks for your questions. I am assuming that the audience is at least vaguely familiar with the (mis)behavior of the "edit conflict" process in wikimedia projects, or if technical with github and related workflows, so a presentation won't be needed to set the context. I was a bit expository in the discussion description specifically so I *wouldn't* have to set that context in the actual discussion. I have made presentations and had technical discussions of this content before, so I'm not interested in re-covering that ground! What I'm really interested in is hearing from users and editors about their experiences with edit conflicts, with the draft namespace, and with other attempts at mitigating these issues, and to get new ideas which are *not* coming from the "well, git does it this way..." perspective that I've already heard in previous technical discussions. As well, I'm interested in hearing from folks who have worked with forks, hostile or otherwise, and learning what tools they used (or would like to have used) to manage them. Some forks might just be folks who are trying to maintain content in mediawiki whose canonical source is elsewhere, like the winners of some TV program or sports playoff. What tools do we have for synchronizing content and notifying when synchronization is necessary, and what tools could we build? I want to ensure we don't build new solutions that are overly biased toward "the way code developers do things" or "the way code developers thing about the problem", and instead of responsive to editors and the social needs of communities. I'm hoping for a discussion which takes advantage of the unique community present at Wikimania, which wouldn't be possible in a conversation of developers in San Francisco.Cscott (talk) 19:00, 28 April 2016 (UTC)[reply]
@Cscott: hmm, so basically it is about organisations that want to include their information on Wikipedia, and use it elsewhere too. I can't quite imagine usecases for it yet. However, I can imagine them for Wikidata. Would a discussion on that be more likely to result in something constructive? Because if we limit ourselves to 'edit conflicts', I don't think we'll get very interesting discussions :). But even then, the topic remains tricky... Effeietsanders (talk) 14:36, 8 May 2016 (UTC)[reply]
