Media Wiki API Project: Edit/Protection Spikes Around Corporate Event Time

### Overview

Detect and quantify **edit/protection spikes around real-world corporate events** (e.g., layoffs, scandals) on company Wikipedia pages by aligning pageview spikes with revision, revert, and protection activity. Deliver a reproducible dataset and dashboard showing **time-to-protection**, **revert deltas**, and **content churn** around event windows.

### Action Items

**If this is the beginning (research & design)**

* Scope: 100–200 notable companies (start with tech/finance). Create `companies.csv` with `company, enwiki_title, topic`.
* Event proxy: use **pageviews spikes** to infer event windows (rolling median + MAD z-score > threshold). Optional: seed with categories like “Corporate scandals” for validation.
* Metrics: time-to-protection after spike, Δrevert ratio (pre/post), edits/day, unique editors, size deltas, talk-page activity, and persistence of elevated activity.
* Methods:

* **Wikimedia REST** for pageviews (daily).
* **Action API**: `prop=revisions` (edits, users, sha1, tags), `list=logevents` (protect/unprotect), `prop=info&inprop=protection` (snapshot), plus Talk page revisions.
* Tooling (pick pairs): `requests` or `httpx`; `pandas` or `polars`; `duckdb` or `sqlite`; `altair` or `plotly`.

**If researched and ready (implementation steps)**

1. **Seed & resolve**

* From `companies.csv`, resolve `pageid` via `action=query&titles=`; map `Talk:<title>`; store redirects.
2. **Detect spikes (events)**

* Pull daily pageviews per page for the full window (e.g., 2019→present).
* Compute rolling median + MAD; mark spikes where z-score > k (e.g., 4). Merge contiguous spike days into **event windows** (e.g., ±7 days).
3. **Pull revision & protection context**

* For each event window: `prop=revisions` (ids|timestamp|user|userid|sha1|size|comment|tags) with continuation.
* Reverts: SHA1 revert-to + comment/tag heuristics `(revert|rv|undid|rollback)`.
* Protection history: `list=logevents` (letype=protect|modify|unprotect) and snapshot via `prop=info&inprop=protection`.
4. **Engineer features**

* Per event: time-to-protection (first protect after spike start), Δrevert ratio pre→post, Δunique editors, peak edits/day, net size change, talk-page edits.
* Per page: events/year; share of spikes that lead to protection; median time-to-protection.
5. **Analyze**

* Rank companies by **protection likelihood after spikes**, **median time-to-protection**, and **revert delta**.
* Compare topics (tech vs finance) and spike magnitude vs moderation response.
6. **Deliver**

* Artifacts: `pageviews_daily.parquet`, `events.parquet`, `revisions_windows.parquet`, `protection_events.parquet`, `page_metrics.parquet`, `metrics.csv`.
* Dashboard: timelines with spike/ protection overlays; company leaderboard; per-event drill-downs.
* Methods README: formulas, thresholds, and caveats.
7. **Quality & Ops**

* Caching; polite `maxlag` handling; persist `continue` tokens; store raw JSON.
* Tests: spike detector, revert detection, protection parsing, window slicing.
* Error handling: `try/except` with clear `print()` on I/O (e.g., file-not-found); **raise with a trace** on dtype mismatches; warn for recoverables.
* Optional: scheduled monthly refresh via GitHub Actions.

### Resources/Instructions

**APIs to pin in the repo**

```
MediaWiki Action API (overview): https://www.mediawiki.org/wiki/API:Action_API
Revisions: https://www.mediawiki.org/wiki/API:Revisions
Logevents (protect/unprotect): https://www.mediawiki.org/wiki/API:Logevents
Page info & protection: https://www.mediawiki.org/wiki/API:Info
Query & continuation etiquette (maxlag): https://www.mediawiki.org/wiki/API:Query
Wikimedia REST (Pageviews): https://wikitech.wikimedia.org/wiki/Analytics/AQS/Pageviews
```

**Suggested libraries (pairs)**

* HTTP: `requests` | `httpx`
* Frames: `pandas` | `polars`
* Storage: `duckdb` | `sqlite`
* Viz: `altair` | `plotly`

**Sample queries (copy to notes)**

```
# Resolve pageid
action=query&titles=<TITLE>

# Daily pageviews (REST)
GET /metrics/pageviews/per-article/en.wikipedia/all-access/user/<URL_ENCODED_TITLE>/daily/<START>/<END>

# Protection history
action=query&list=logevents&letype=protect|modify|unprotect&leprop=title|timestamp|details|comment&lelimit=max&letitle=<PAGE_TITLE>

# Current protection snapshot
action=query&prop=info&inprop=protection&titles=<PAGE_TITLE>

# Revisions in a window
action=query&prop=revisions&titles=<TITLE>&rvprop=ids|timestamp|user|userid|sha1|size|comment|tags&rvstart=<ISO_END>&rvend=<ISO_START>&rvlimit=max
```

**Ethics & caveats**

* Spikes proxy attention, not causality; interpret with caution.

* Avoid editor-level profiling; aggregate findings.

* Company pages vary in template/infobox usage; content size deltas are approximate.

* If this issue requires access to 311 data, please answer the following questions:

* Not applicable.
* N/A
* N/A
* N/A

---

## Project Outline (detailed plan for this idea) in details:

<details>

**Research question**
Do company pages experience **faster protections** and **higher revert intensity** around attention spikes (likely tied to layoffs or scandals), and which firms show the strongest moderation responses?

**Data sources & modules**

* REST: pageviews per-article (daily).
* Action API: `prop=revisions`, `list=logevents` (protect/unprotect), `prop=info&inprop=protection`, Talk page revisions.

**Method**

1. Build `companies.csv` and resolve `pageid`.
2. Detect spike windows from daily pageviews via rolling median + MAD z-scores; merge adjacent spikes.
3. For each spike window, pull revisions and talk revisions; detect reverts (SHA1 + tags/comments).
4. Join protection history; compute time-to-protection and pre/post deltas.
5. Aggregate to company- and topic-level metrics; rank and visualize.

**Key metrics**

* **Time-to-protection** (days) from spike start.
* **ΔRevert ratio** pre→post; **Δunique editors**; **peak edits/day**.
* **% spikes with protection**; **events/year** per page.

**Deliverables**

* Clean tables (`pageviews_daily.parquet`, `events.parquet`, `revisions_windows.parquet`, `protection_events.parquet`, `page_metrics.parquet`).
* Notebook + `reports/corporate_event_spikes.md`.
* Streamlit/Altair dashboard: spike timelines, protection overlays, rankings.

**Limitations**

* Not all spikes correspond to layoffs/scandals; they’re attention signals.
* SHA1 detects only exact reverts; partial reverts via comments/tags may miss cases.
* High-profile pages are large; windowing and pagination are essential.

</details>