The Wikipedia Library/Processes/Library card platform/Other specs

Definitions

Editor

• An editor on a Wikimedia project who requests access to a partner resource. This is the primary end user.

Access

• When a request for a partner resource is accepted by a coordinator and approved by the partner access is noted on the library card, containing:
  • The partner resource
  • the partner
  • Timeframe for access

Request

• Created when an editor asks for a particular partner resource, containing:
  • (optionally) A free text note from the editor requesting access
  • (optionally) A free text note from a coordinator
  • A status, as described below

Status

• Status can take the following values:
  • Pending
  • Accepted
  • Accepted and activated by partner
  • Accepted and pending partner activation
  • Declined
  • Waitlisted
• Each status is applied at a given time and superseded by any newer status, although a record of all status actions is attached to a request
• A note can be added to an individual status decision

partner resource

• A collection of materials provided by a partner, containing:
  • Information on the resource itself
  • Number of available signups
  • Criteria for acceptance
  • Information on the partner
  • Categories/tagging for internal organization (e.g. natural sciences, etc.)

Components

Public facing

General public views of the library need to be:

• Responsive, accessible and internationalizable.
• Views for partner resources and transparency reports (editor access, resource signups)

Editor

Editors need to be able to:

• sign up and login via OAuth
• Responsive, accessible and internationalizable, with interactions (login/update request) having some reasonable limitations (requiring JavaScript).
• View library card and current requests for access
• Make and update requests for access (And account information)
• contact coordinator page

Coordinator

• View single or multiple items
  • Sort and filter multiple items by specific criteria
  • Single views may have more information, e.g. editor contribution totals across wikis on editor pages
  • Some of which could be tricky to do. contributions aren't exposed to the API, so a frame could be opened with the contributions page and messages passed to the parent frame summing up totals (or just show the frame).
• Act on items in the database one at a time or in batch
• Export specific items into csv
• contact editors and partners (for the latter optionally including an exported csv)
• View pre-generated "report" views, e.g. all editors in the queue for any resource with a certain age.
• These could be "created" by an admin to serve as the queues for individual coordinator (tasking them)

Scale and scope

Scale

• Relatively small sized site. expecting ~ 100 coordinators, up to (and possibly exceeding) 10000 editors, and probably partner resources in the dozens.
• You want to be able to update items relatively contemporaneously (i.e. not "checking out" a block of requests) but it doesn't need to be some high reliability or high throughput store
• You're looking at somewhere in the 10,000s thousands for total requests or access (current editors have on Average 2-3 accesses)

Scope

• A back end (which can be relatively simple) to
  • manage the data store
  • serve the web content
  • send off email
  • Generate and store exported csvs
  • maintain rules to limit abuse (number of emails sent by accounts, accounts registered to editors with few edits can have silent restrictions)
  • run the login systems.
• A relatively simple (but good looking) interface for the public and editors
  • Mostly "semi-static" views of content.
• A relatively complex (but doesn't need to look shiny) interface for the coordinators
  • multiple views for items and actions.