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

Definitions

edit

Editor

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

Access

edit
  • 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

edit
  • 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

edit
  • 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

edit
  • 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

edit

Public facing

edit

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

edit

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

edit
  • 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

edit

Scale

edit
  • 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

edit
  • 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.