The contribution model of our projects is built largely around direct edits to the most recent version of content, which are public and visible worldwide immediately upon submission. This model brings a number of beneficial properties—for example, contributors are incentivized when their work is immediately visible and useful to others, and patrollers are spurred to quick review by the immediate impact of vandalism.
However, this model can also breed conflict and discourage new contributors. "Revert first, ask questions later" can be off-putting to new users, who may give up rather than work to have their contributions recognized.
There is an alternative: the "fork-merge" model, which is used in the Draft: namespace and in successful open source projects using github and earlier patch-and-mailing list collaboration models. In the "fork-merge" model every contributor has their own private "fork" of the content, which they can edit however they like. At intervals they (or others) can pick collections of changes to merge into the "main branch", which in Wikipedia's case would make the changes live for the majority of readers. The Draft: namespace has some of the features of a fork-merge model, but would require improved merge and difference tools and a better naming mechanism to refer to/enumerate a given user's drafts.
By sacrificing immediacy, fork-merge tempers conflict. Instead of an immediate revert, a new contributor will instead just have their merge delayed, which has less connotation of "lost work". Further, the forked content provides a forum to incrementally improve a contribution before merge, increasing engagement instead of alienating the new user.
Extending the model further, forks can provide safe spaces to shield disadvantaged or persecuted users from the broader community. Contributions can be made inside a "safe space" draft namespace, and then an ally can be delegated to interact with the broader community to get the contributions merged. This can protect the original author from personal harassment.
In general, all work on Wikimedia projects is done in public. Creating a safe space involves careful trade-offs to shield a subset of that work from harassers, likely a variation on [[:en:Wikipedia:UP#OWN|WP:UP#OWN]] to establish appropriate norms. It is possible that specific technical support for shielding user identities from view by unprivileged users might be worth discussing to strengthen the guarantees of the safe space.
In this session I hope that we will discuss how safe spaces may be created for contribution, aided perhaps by using fork-merge mechanisms in the spirit of the existing Draft: namespace.
Speakers: C. Scott Ananian