2019:Thriving in Safety/Draft: as a safe space
 | This is an Accepted submission for the Safety space at Wikimania 2019. |
Please have a look at the topics that people want to see in this space before making a submission and describe how your submission connects with those topics.
Description
[edit | edit source]
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 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.
Relationship to the theme
[edit | edit source]This session will address the conference theme — Wikimedia, Free Knowledge and the Sustainable Development Goals — in the following manner:
SDG #10: Reduced inequalities: by providing protections to marginalized groups we can reduce inequalities and facilitate contributions to our projects in knowledge gaps.
SDG #17: Peace, Justice, and Strong Institutions. Protecting the fundamental rights and freedoms of our readers and editors.
Session outcomes
[edit | edit source]At the end of the session, the following will have been achieved:
- An understanding of how different contribution models can impact safety
- A discussion of different ways "safe spaces" might be implemented
- A robust discussion of how/whether WP:UP#OWN is appropriate for safe spaces, or whether additional protections/blinding are required.
Session leader(s)
[edit | edit source]- C. Scott Ananian, Wikimedia Foundation
Session type
[edit | edit source]Each Space at Wikimania 2019 will have specific format requests. The program design prioritises submissions which are future-oriented and directly engage the audience. The format of this submission is a:
- Lightning talk
- Workshop to identify and try to solve problem
- Roundtable discussion forum
Requirements
[edit | edit source]The session will work best with these conditions:
- Room (Please be aware that the main room available will be a 30 person board room. We can try and arrange for other rooms, but cannot guarantee success):
The board room should be fine.
- Audience:
10-20 people; no prior knowledge required.
- Recording:
Yes, appropriate for recording.