User:Robchurch/Work queue

Idea originated with Brion and seems quite sane.

Thoughts

Trusted users can queue tasks associated with a page (e.g. deletion)
Maintains links to discussion
- Automated mechanism to generate discussion page title (a page might have multiple deletion requests over time)?
- Automated creation of discussion page?
- Could set up the discussion when enqueued using a boilerplate
- Could add a proper banner in the UI when viewing a page?
Informs the creator of the page that it's up for deletion or whatever
- Avoids the whole "no-one told me" culture
- Might inform all recent editors?
  Plus the original creator, and people who have the article on watchlist?
  Hence the "informs creator" line above. robchurch | talk 17:56, 25 June 2007 (UTC)
- Could use Brion's evil plans for notification mechanism?
For some long-term content-related tasks, users could "take" the task. This is not meant to indicate some kind of ownership, but to indicate that someone's on it (and who). Example : "Rewrite section XYZ of this article". --Magnus Manske 18:52, 25 June 2007 (UTC)
Sysops can remove the item from the queue
Sysops review a list of expired items and finalise the task (e.g. deletion) with one click
- Creator/editors etc. are notified
- Anyone else "watching" the item is notified
For less critical tasks than deletion, "normal" users (maybe once they qualify to edit soft-protected pages or something) should be able to close a task.--Magnus Manske 18:31, 25 June 2007 (UTC)
Logs, tracking pages, reports and other goodies
- RSS feed (maybe per task type), IRC notes, so deletionists can subscribe to deletion requests :-)

This would be close in terms of process to the English Wikipedia's "speedy deletion" system, or "proposed deletion". Controversial deletions can (and should) still go through a longer discussion process.

General flow

The general flow of operations is more or less the same, regardless of the class of work item in question:

User creates work item for a page using a special page
Or (additionally) a section in the sidebar, maybe only for minor task types, or with an "are you sure" dialog for major ones like deletion. --Magnus Manske 18:34, 25 June 2007 (UTC)
Work item enters queue and notifications are sent to "appropriate users"
The work item handler class is responsible for determining who these are, e.g. the page creator, editors watching the page, most recent editors of the page, etc.

These will differ between tasks (e.g., no need to notify anyone for a "wikify" task)
That's the point of a work item handler; a class which manages all the decisions relating to a given work item. robchurch | talk 20:59, 25 June 2007 (UTC)
Other users can register their interest and "watch" the queue item
Discussion can take place on a page associated with the work item
Which namespace? "Task:"? --Magnus Manske 18:36, 25 June 2007 (UTC)
It could differ according to the nature of the work item. robchurch | talk 20:59, 25 June 2007 (UTC)
The item is deemed to be resolved in some manner
A user with the appropriate rights confirms the resolution, selecting a specific action to take

Example flow: Deletion

User creates deletion work item for a page or file
Item enters queue, creator/uploader, watchers and last editors are notified
Other users can "watch" the queue item, being notified of changes to item state
Discussion takes place on the associated discussion page
After a period of time, the deletion can be confirmed, cancelled or postponed for an additional length of time for further discussion, etc.
All watching users are notified of the outcome
The outcome is logged with the discussion referenced

Things to address

Notification: In an ideal world, this will use the multiple notification queue Brion would like to see added

Schema

This table holds the queue data.

CREATE TABLE work_queue (

  -- Queue item identifier
  wq_id UNSIGNED INT NOT NULL AUTO_INCREMENT,

  -- Queue item classification
  -- [Maps to a class representing the work queue item]
  wq_type UNSIGNED INT NOT NULL,

  -- Associated page
  -- [FK to page.page_id]
  wq_page UNSIGNED INT NOT NULL,

  -- Proposer
  wq_proposer UNSIGNED INT NOT NULL,
  wq_proposer_text VARCHAR(255) NOT NULL,

  -- Timestamp of proposal (and expiration? do we need this?)
  wq_timestamp VARCHAR(14) BINARY NOT NULL,
  wq_expires VARCHAR(14) BINARY NOT NULL,

  -- Comment relating to the item
  wq_comment VARCHAR(255 ) NOT NULL,

  -- Discussion page
  -- [FK to page.page_id]
  wq_talk UNSIGNED INT NOT NULL,

  PRIMARY KEY ( wq_id ),
  KEY ( wq_type, wq_page, wq_timestamp, wq_expires ),
  KEY ( wq_proposer, wq_proposer_text )

);

This table maintains a "watchlist" for people who are to be notified of changes to the queue item. The creator (and perhaps other editors) are added to this when the queue item is created, and other users can add themselves if interested.

wg_expires could also be expressed as wg_last_action (last action related to the task), which would enable us to sort tasks according to which ones have been unattended the longest. --Magnus Manske 18:38, 25 June 2007 (UTC)
To keep track of closed tasks, wg_closed could carry the time of closing. Also, how about wg_parent, in case a task is reopened? --Magnus Manske 18:41, 25 June 2007 (UTC)
Maybe I sound like a broken record, but if you look at the table from my Tasks extension, you'll see that it matches the above table very closely. --Magnus Manske 18:56, 25 June 2007 (UTC)

CREATE TABLE work_watchers (

  -- Row identifier
  ww_id UNSIGNED INT NOT NULL AUTO_INCREMENT,

  -- Associated queue item
  -- [FK to work_queue.wq_id]
  ww_item UNSIGNED INT NOT NULL,

  -- User identifier
  -- [FK to user.user_id]
  ww_user UNSIGNED INT NOT NULL,

  PRIMARY KEY ( ww_id ),
  KEY ( ww_user ),
  KEY ( ww_item )

);

ww_id strikes me as superfluous. It won't be needed for inserting nor deleting an entry. --Magnus Manske 18:44, 25 June 2007 (UTC)