C. Scott Ananian

Currently there are a wide variety of "annotations" performed on our content with a plethora of different ad-hoc tools, using either inline markup or a separate linked database. Inline markup can be an extension tag, template, specialized wikilink syntax, or a combination, such as [[mw:Citoid|citations]], [https://www.semantic-mediawiki.org/ Semantic MediaWiki], and [[mw:Extension:Proofread_Page|Proofread Page]]. Annotations which have successfully been moved out of wikitext include [[mw:Interlanguage_links|interlanguage links]] and [[mw:Wikibase/Installation/Advanced_configuration#Mixing_Wikidata_and_local_interlanguage_links|Wikidata]]. Annotations performed on media resources include [[metawiki:Structured_Data_on_Commons|Structured Data on Commons]] and the [[mw:Extension:FileAnnotations|FileAnnotations extension]] (and [[phab:T146397#4451340|related projects]]). This session discusses a general annotation service, for example [[:en:User:Cscott/Ideas/Amazing_Article_Annotations|Amazing Article Annotations]], as it could be applied to transcriptions. In particular, we would like to go through the specialized transcription tools one by one (OCR, [[mw:Extension:Proofread_Page|Proofread Page]], [[c:Commons:Timed_Text|Timed Text]], the [[c:Template:Inscription|Inscription]] template, [[mw:Content_translation|Content Translation]], etc) and determine to what degree they could be simplified and improved with a standard annotation service, built on the [https://www.w3.org/annotation/ W3C Annotation standard]. By moving the annotation out of wikitext syntax perhaps certain new features could also be made possible, which were previously held back by the desire not to bloat the original resource with transcription-specific markup. Further, a general annotation service can provide greater editing support by providing common editing tools and allowing annotations to remain anchored even when the resource is edited.

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.

Other people: S. Subramanya Sastry

The current wikitext template system is a marvel of engineering: conceptually simple yet extensible to allow a huge variety of different tasks to be done on-wiki. It is perhaps ''too'' powerful, templates seem to be used for ''everything.'' [[mw:Extension:VisualEditor|Visual Editor]] has made wikitext editing more accessible to new users. However, it imposes a low ceiling on contributors: only the most basic edits to template invocations are allowed, and you cannot use Visual Editor to author or edit the templates themselves. Let's discuss how the template system could be modernized. I expect discussion along three axes: * Incremental improvements to the current template system, like [[phab:T114432|heredoc syntax]], [[phab:T114445|balance]], or JavaScript support in [[mw:Extension:Scribunto|Scribunto]]. * Specialized/improved alternative mechanisms to accomplish some of the tasks which templates are currently used for, like [[mw:Requests_for_comment/Scoped_language_converter|glossaries]], workflow, or [[:en:User:Cscott/Ideas/Amazing_Article_Annotations|annotations]]. * Rethinking the underlying template mechanism: [[phab:T121470|global templates]], template i18n, or [[phab:T114454|visual templates]] (which allow templates to be authored/edited with Visual Editor).

What will Wikipedia be like in 2030? What could it be like? I'd like it to be '''one wiki'''. Instead of many silos, separated by language and project, we would feel like one community working together. Although under the covers we may still have separate databases and archives, from the user perspective there would be no barrier between projects or languages. Machine translation and network bandwidth will have continued their progress, so any content will be available to any user anywhere in the world, with at least a passable translation into their preferred language. When access and language are removed as roadblocks, everyone can work together as if on a single project: all economic classes, all countries, all languages, nothing standing between us. '''Yet''' we will still respect language and cultural differences. We can talk to each other without barriers, and we can work on shared projects where our goals align, but we will not force our perspective on others. We will still have many projects. For example, there will probably not be peace everywhere in the world in 2030. People will still disagree about "facts" such as countries, capitals, and borders. Within our projects, not everyone will use a single category system! But we are working together, respecting our differences, and being kind. It will be easy to "see an article in a new light" where that is appropriate, with tools that are symmetric (not unidirectional) so that big wikis can draw from smaller wikis and small wikis can draw from big wikis. The user experience ''reveals'' differences without letting these differences separate us. Moving further, my dream is that all of the non-encyclopedia projects have grown up and out at least to the extent that Wikipedia currently has. Wikiversity is working on implementing [[En:The Diamond Age|The Diamond Age]]; Wikibooks are considered standard textbooks in many places; and Wikisource has reached par with libraries and archives in the same way that Wikipedia has reached par with Britannica.