Teyora/Risker's Checklist

This is an in progress document on how Teyora aims to meet the requirements set out in w:en:User:Risker/Risker's checklist for content-creation extensions - this page is also a derivative of this. I know this isn't specific to Teyora's space, but the guidelines are useful. Anything in italics is regarding Teyora.

Risker's Checklist

This checklist is created based on my experience as a CheckUser, Oversighter, administrator and editor. I have, in the past, identified and communicated most of the points below, but mainly in relation to specific extensions, or in non-documented discussions.

Minimum viable product

The following are in addition to any product-specific minimum expectations. Note that these apply only to the production wikis, not to test wikis. These apply to products used on any interface to the production wikis (desktop, mobile, mobile app, application programming interfaces, and any other interfaces).

Visibility

• All actions must show up in the appropriate project logs: recent changes, new pages, etc. In some cases, an extension-specific log will be needed; it should be included in the publicly viewable logs absent a legal or security reason to make it non-public.
• All actions must show up in the appropriate user-specific logs: user contribution history, upload log, etc.

• Teyora makes public edits, so are available via all standard logs, in both its own log containing basic information that is publicly available (we listen to the revision deletion API to ensure that deleted/oversighted edits are also oversighted on Teyora, they will also immediately disappear from all feeds). Actions taken by Teyora administrators and systems are visible to all users in an administrator log.

• All actions (including actions related to moderating the content) must show up in non-public logs and tables: CheckUser tables and logs, suppression log.

• Edits are proxied through Teyora for security and technical reasons, especially considering the security implications of the extension system - this may cause some issues for checkusers, but Teyora overlords (equivalent to bureaucrats) can enable IP hashing features that can identify shared or sockpuppet accounts in order to mitigate abuse whilst respecting user privacy.

Curation

• All content must be able to be edited by others.

• Teyora is FOSS, and all extensions must be GPLv3 licensed to be eligible for listing on the extension store. Extension pages cannot be edited by anyone unauthorised.

• All content must be able to be deleted (both revision deletion and full-page deletion).

• Pretty much everything in Teyora can be hidden by administrators (i.e. it basically doesn't exist to end users, this isn't the same as revision hiding in MediaWiki), then deleted from the database with effective permissions

Moderation

• It must be straightforward to be able to review all logs, including contributions logs, recent changes, etc.

• Logs can be accessed either via a Teyora logs workspace or by using the built in log viewer

• All content must be able to be suppressed (either as suppression of individual revisions or by suppression-deletion of the full page).

• See above

• All contributions and actions must show up in the CheckUser tables.

• See above

Do no harm, and be prepared to reverse implementation

Cut irrelevant points

• If making a content edit using an extension results in an *unplanned* warning message, addition/removal of material, or change in markup, consider early rollback until the problem is identified. Many projects do not have sufficient volunteer editors to clean up these errors, and on high activity wikis the result can be overwhelming to editorial volunteers (q.v., initial implementation of VisualEditor to the English Wikipedia as the default editing interface for all users).

• We are implementing opt-in (but very encouraged) error tracking and ensuring all actions are logged prior to edits being made