Design Doc: Actions in WikiLoop Battlefield

[xinbenlv]

Design questions

DQ1: Should Action merge with the current Interaction, or should it be a separate one?

We originally call the "label" of "ShouldRevert", "LooksGood", "NotSure" a judgement or an interaction. Now we are adding Actions to API and database, how should we treat them?

Pro merge:

• Simplified counting, querying and segmenting.
• Reuse existing API interfaces.

Pro separate:

• least breaking change to current API
• more clean logic.

Decision: separate them, (at least for now).

DQ2: How should we avoid abusing the edit power this application enhance

@xinbenlv:

3. We are getting close to open up for login-to-revert/rollback, I noticed both Huggle and STiki chose to require "ROLLBACK" permission to allow a user to even start using Huggle/STiki, would you share with us why it was the case?

@westand The community imposed this restriction on our tools. Indeed, STiki allows for some very efficient editing/reverting. If one were to hold down the "revert" hotkey, they could easily make a couple reverts a second, and you can imagine the damage that would cause.

Design

We will add another set of Action, and it means a user conduct.

Schema

1. DirectRevert: undo a single revision that is the latest of the page.
2. OpenUrlToRevert: the user click on "revert" button but is not eligible to revert a single revision.
3. Rollback: undo multiple consecutive revisions
4. WarnAuthor: warn revision author for intentionally conducting damaging edit
5. RequestForPageProtection (WP:RFPP): request a page to be protected
6. RequestForBlock: request a user or an IP to be blocked

It will carry the following schema

// pseudo code

enum ActionType {
  // ... as specified above
}

interface Action {
  actionType: ActionType;
  wikiUserName:string; // theUserName
  timestamp: Date; // the timestamp this action happens
  wiki: string; // the wiki string identifier of a wikiproject
  committedToWiki:boolean; // if the action is performed onto Wikipedia  
  comment: string // user comment
}

Action Response

The API will respond with a HTTP STATUS 200 for a success result, 400 for general error, 403.

Anti-Abuse

Once we start allowing OAuth login to revert / rollback and perform other edit, it's possible that a user use it to perform actions much faster than the community could handle, we need to create a anti-abuse mechanism that balance user adoption/convenience VS anti-abuse

We will first roll out a Phase 1 beta with the following restrictions . anonymous user, they will be redirected to URL and they could perform undo on a regular Wikipedia webpage. This is equivalent to a standard web user . Wikipedia admin or Wikipedia user with ROLLBACK permission or whitelisted: allow direct revert through calling MediaWiki API *. Regular user, same as anonymous user at this point.

This behavior matches WP:Huggle and WP:STiki

The Phase 2 will allow a regular user the following test drive power:

needing a Wikipedia community consensus discussion after Phase 1 completes

. new user: 5 direct revert quota a day, lifetime total quota = 30 . autoconfirmed user: 30 direct revert quota day, rate limit to 1 revert per 5 seconds (lifetime quota = 210) *. extended autoconfirmed user: 100 direct revert quota day, rate limit to 1 revert per 5 seconds (no lifetime quota limit)

We plan to host a community discussion to form a consensus of finalized Anti-abuse policy.

[Enkreis]

@xinbenlv In the DirectRevert version, when I press the revert now button, a red line appears at the top of the screen, and nothing happens on the page I am trying to revert.

[xinbenlv]

@A-NEUN currently only http://battlefield2.wikiloop.org supports direct revert, did you try this new URL?

[Enkreis]

Yes. It was on this url that I had the issue.

[Enkreis]

@xinbenlv I now have rollback, and the direct reversion is working correctly. Perhaps this was the problem?

[xinbenlv]

@A-NEUN not sure, as long it currently works, that's great