wikimedia-phabricator git:20261003.928fb9aA

Immutable. This exact content never changes and is served at /api/v1/blob/79977a454151b0bb.

---
name: wikimedia-phabricator
description: Use when working with Wikimedia Phabricator — search tasks, read status, and interact responsibly (etiquette, conduct, privacy, security, bot-account rules)
license: MIT
compatibility: opencode
depends_on: [wikimedia-api-access]
last_verified: 2026-10-03
skill_discovery_hints:
  - keywords: ["Phabricator", "Phab", "bug report", "bug tracker", "known issue", "known bug", "feature request", "task"]
  - keywords: ["in development", "being worked on", "project status", "roadmap", "sprint", "workboard", "deployment status"]
  - keywords: ["history of", "when did", "when was", "debut", "first appeared", "timeline", "origin of", "test cycle", "experimental phase", "design goals", "design rationale", "compared to", "comparison", "evaluate this goal"]
  - keywords: ["why doesn't", "why won't", "broken", "not working", "regression", "reported", "submit a bug"]
  - keywords: ["phab:", "tracking ticket", "development tracking", "task status"]
---

> ℹ️ **No User-Agent needed for browser access.** Phabricator tasks are accessed via standard web URLs. For programmatic access via the Conduit API, include a descriptive `User-Agent` header as described in the **[wikimedia-api-access](../wikimedia-api-access/SKILL.md)** skill.

> **When to use this skill:** A user asks why a Wikipedia feature behaves a certain way, whether a bug is known, whether something is being worked on, or wants to report a problem. **Phabricator is the canonical place to check** — it is the WMF's centralized task tracker for all software bugs, feature requests, and project planning across MediaWiki, Wikimedia apps, and Toolforge.

---

## SOP: What Phabricator Is

Wikimedia's **[Phabricator instance](https://phabricator.wikimedia.org)** is the project management and bug tracking system for the entire Wikimedia movement. Every software task — from a DiscussionTools bug to a Toolforge infrastructure request to a mobile app feature — lives here as a **task** (identified by `T` + number, e.g. `T409297`).

Key differences from MediaWiki wikis:
- Phabricator is NOT MediaWiki — it's a different platform with its own query language and interface
- Tasks are not "pages" you edit — they have structured fields (status, priority, project tags, subscribers)
- Anyone with a Wikimedia account can log in and comment, but filing good tasks follows conventions

---

## SOP: Searching Phabricator

### Basic Search (URL)

The quickest way to find a specific task is by URL:
```
https://phabricator.wikimedia.org/T12345
```

### Text Search (Top-right search box)

Accepts free-text queries and returns tasks whose title or description matches. Good for: "talk page usability improvements", "DiscussionTools mobile bug".

### Advanced Search (Maniphest)

Use the **Maniphest** search interface at `https://phabricator.wikimedia.org/maniphest/` for structured queries. Key query language:

| Pattern | Example | What It Finds |
|---------|---------|---------------|
| `project:(name)` | `project:(Editing-Talk)` | Tasks in a specific project |
| `is:open` | `is:open` | Open tasks (not Resolved/Closed) |
| `is:stalled` | `is:stalled` | Tasks blocked or waiting |
| `@username` | `@ppelberg` | Tasks assigned to or mentioned by a user |
| `#tag` | `#DiscussionTools` | Tasks tagged with a hashtag |
| `!project` | Tasks NOT in a project |
| `priority:high` | High-priority tasks |
| `subtype:epic` | Epic tasks (containers for sub-tasks) |

Combine them: `project:(Editing-Talk) is:open priority:high`

### Finding Tasks from a Phabricator URL Reference

When you have a task number like `T346108` from a skill or documentation page:
1. Navigate directly: `https://phabricator.wikimedia.org/T346108`
2. Read the task description for what the task is about
3. Check **status** (top of page)
4. Check **project tags** (right sidebar) for related work
5. Scroll to **comments** for discussion and status updates
6. Check **parent tasks** and **subtasks** (right sidebar) for task hierarchy

---

## SOP: Understanding Task Status

The task status tells you what stage a piece of work is in. This is the single most important thing to check when researching "is this being worked on?"

| Status | Meaning | When You See This |
|--------|---------|-------------------|
| **Open, Needs Triage** | Recently filed, not yet reviewed by the team | New bug reports, fresh feature requests |
| **Open, Needs Triage Public** | Visible to all (default for public tasks) | Same as above |
| **Open** | Reviewed and accepted — needs work | Someone is actively working on it or it's prioritized |
| **Stalled** | Blocked — waiting on another task, decision, or resource | Check comments for what's blocking it |
| **Resolved** | Work is complete | The fix/feature was delivered |
| **Closed** | No further action planned | May have been declined, superseded, or completed long ago |
| **Declined** | Decision not to do this | Check comments for the rationale |

### What "Open, Needs Triage" Actually Means

The project we looked at in this research, T409297 (English Wikipedia Phase 6 deployment), shows `Open, Needs Triage` — which means it's been created and acknowledged but hasn't yet been assigned or actively scheduled. This does NOT mean work has stopped; it means the task is waiting in the queue for the team to scope and schedule.

---

## SOP: Understanding Project Tags

Tasks are organized by **project tags** (shown in the right sidebar). These let you find related work.

### Common Project Tags

| Tag | Used By | Examples |
|-----|---------|----------|
| `#Editing-Talk` | Talk pages project, DiscussionTools | Reply Tool, Usability Improvements, Topic Subscriptions |
| `#DiscussionTools` | The DiscussionTools extension itself | Bug reports, feature requests for the tool |
| `#MediaWiki-General` | Core MediaWiki platform | API changes, infrastructure, performance |
| `#Toolforge` | Toolforge infrastructure | Tool hosting, database access, Kubernetes |
| `#Community-Health` | Anti-harassment, UCoC, moderation tools | Detox, incident reporting |
| `#Mobile-Web` | Mobile web experience | Mobile talk pages, mobile editing |
| `#StructuredDiscussions` | Flow / Structured Discussions (deprecating) | Migration tooling |
| `#WMDE-Engineering` | Wikimedia Deutschland engineering | Wikidata-related development |

### Finding Related Tasks

To find all tasks in a project: navigate to `https://phabricator.wikimedia.org/project/profile/N/` where N is the project ID, or use the search:

```
project:(Editing-Talk) is:open
```

### Task Hierarchy

Tasks can have relationships:

- **Parent task** (Epic): A larger project that contains sub-tasks. Epic tasks often have `subtype:epic` and a `#epic-` tag.
- **Subtasks**: Individual pieces of work within an epic. Each has its own T number and status.
- **Related tasks**: Tasks that are conceptually related but not hierarchical.
- **Depends on**: Task A cannot be completed until Task B is done.

When researching a project, always check the subtask list to understand scope. The epic task may be `Resolved` while individual subtasks are still `Open`.

---

## SOP: Filing a Bug Report

If a user reports a problem with a Wikimedia tool or feature, Phabricator is the right place to file it. But follow these conventions:

### Before Filing

1. **Search first** — Phabricator has a lot of duplicate tasks. Search for your issue before creating a new one
2. **Check if it's a known issue** — look for existing tasks with similar keywords
3. **If you find an existing task** — add a comment with your reproduction case rather than creating a duplicate

### What a Good Task Includes

```
**Title:** Short, specific description of the problem
**Example:** "Reply Tool inserts extra blank line when replying on mobile"

**Description:**
- **Steps to reproduce:** (numbered, starting from a known state)
  1. Open any article talk page on mobile web (e.g. Talk:Example)
  2. Click [ reply ] on the first comment
  3. Type a short message
  4. Click Publish

- **Expected behavior:** What should happen
  Comment appears with proper formatting, no extra blank lines.

- **Actual behavior:** What actually happens
  An extra blank line appears between the previous comment and the new one.

- **Environment:**  
  Browser/version: Chrome 125, iOS Safari 18  
  Skin: MinervaNeue (mobile)  
  Wiki: English Wikipedia  
  Account: Logged in

- **Screenshots/recordings:** (if applicable, attach to the task)

- **Related tasks:** (if you found anything similar)
```

### Project Tags

Tag the task with the relevant project so it reaches the right team. If unsure, add a comment asking for triage rather than guessing.

### Conventions to Know

| Rule | Why |
|------|-----|
| **No "me too" comments** | +1 comments without new information clutter the task. Instead, use the "Subscribe" button (subscribers are listed in the sidebar) |
| **Security issues go to security@** | Do NOT file security vulnerabilities as public tasks. Email `security@wikimedia.org` instead |
| **Bug reports on live tools may go elsewhere first** | For Toolforge-specific issues, check with the tool maintainer before filing a Phabricator task |
| **One issue per task** | Don't list multiple unrelated bugs in one task |
| **Use parent tasks for scope** | If filing a feature request that's part of a larger effort, link to the parent epic |

### ⚠️ Before ANY write action: read `references/responsible-interaction.md`

This agent's default is **read-only**: never file, comment, assign, re-prioritise or attach on someone's
behalf — hand over a draft instead. (Project convention: many editors file their own tasks; agent output is
"inspiration only".) Non-negotiables, from the primary policies:

| Rule | Source |
|---|---|
| **AI/LLM-assisted content**: "you are fully responsible for its content. Your text must be accurate, factually correct, and represent your own understanding" — verify every claim and task ID | mw:Bug management/Phabricator etiquette |
| **Security issues are never public tasks** — security@wikimedia.org or form/75, coordinated disclosure | mw:Reporting security bugs |
| **Status/priority reflect reality, they don't cause it** — comment instead of changing when in doubt | Phabricator etiquette |
| **Don't assign without the assignee's prior agreement**; no "me too"/"Fix this now" comments — subscribe or mention | Phabricator etiquette |
| **No confidential data** (IPs, emails, tokens, NDA/vetted extracts) in tasks, comments or attachments; uploaded files are private only until attached | mw:How to report a bug; mw:Phabricator/Help |
| **Use @usernames, not real names**, and prefer Herald/mentions over mass pings | Phabricator etiquette |
| **Automation needs a registered bot account** (created natively, requested via #Phabricator-Bot-Requests with name/purpose/email/owner; human owner named in the description) — never a personal account for repetitive activity | mw:Phabricator/Bots |
| Conduct is governed by the **Code of Conduct for Wikimedia technical spaces**, which names Phabricator explicitly; reports → techconduct@wikimedia.org | mw:Code of Conduct |

The reference file also covers the read-only techniques (raw transaction pages, why the search UI is JS-only,
the Conduit `ERR-INVALID-SESSION` behaviour) and a pre-flight checklist for any write.

---

## SOP: Tracking What's in Development

To answer "is X being worked on?":

1. **Search** for tasks related to X (by keyword or project tag)
2. **Check status** of top results
3. **Look for epic tasks** with `subtype:epic` — these organize workstreams
4. **Check comments** on epic tasks — they often contain links to quarterly planning docs
5. **Check task dates** — tasks that went silent for 6+ months may be stalled even if not tagged as such

Example workflow (using the Talk pages research from this session):

```
Goal: Find out if section-level watchlisting is deployed

1. Search phabricator for "topic subscription" or "section watchlist"
2. Find T263820 (manual topic subscriptions) and T263819 (automatic)
3. Check status → both Resolved
4. Check parent epic → T263820 is subtask of #Editing-Talk
5. Conclusion: feature was built and deployed. Now check the talk page
   skill or mediawiki.org for end-user documentation.
```

---

## SOP: Programmatic Access When Conduit API Requires Auth

The Conduit API (`api/maniphest.search`, `api/transaction.search`) requires authentication for task details and comments. When working without auth (e.g., from curl in a terminal session), use **raw transaction pages**:

```
https://phabricator.wikimedia.org/transactions/raw/{PHID}/
```

### Extracting PHIDs for Recent Comments

PHIDs for a task's recent comments can be extracted from the task page HTML. Look for patterns like:

```
PHID-XACT-TASK-{hash}
```

These appear in `anchor` attributes and `phid` keys embedded in the page's Javelin init data. The raw transaction page returns the comment as plain text in a `<textarea>` — no parsing needed beyond extracting the textarea content.

### When to Use This

- Bulk extraction of recent comments from a high-activity task
- Researching status when browser navigation is too slow or verbose
- Programmatic monitoring of task updates

This is a workaround — the Conduit API is the proper interface for authenticated access.

---

## Relationship to Other Skills

- **wikimedia-toolforge** — Toolforge infrastructure tasks on Phabricator; this skill helps find them
- **wikipedia-error-handling** — Known API bugs and error conditions are tracked in Phabricator; this skill helps verify whether a 429/403 behavior is a known issue
- **wikimedia-api-access** — API feature requests and bug reports go through Phabricator
- **wikimedia-feature-archaeology** — For full lifecycle investigations (origin → deployment → community communications audit), load this umbrella skill. It orchestrates Phabricator + GitHub + config scraping + comms auditing.
- **All skills that reference specific tasks** — Use this skill to look up referenced tasks and understand their current status (e.g. checking whether a deprecation noted in a skill is still in progress)

---

## SOP: Researching a Wikimedia Feature's Full History

When asked about the origin, timeline, or deployment history of a Wikimedia feature (e.g. "when did Special:PersonalDashboard debut?"):

1. **Start with Phabricator** — search for the feature name. Look for:
   - The **repo-request task** (e.g. "Request a gerrit repository for …") — gives the earliest date
   - The **MVP/launch epic** — gives experiment scope and target wikis
   - **Deployment tasks** — track when code landed on which wikis
   - **Config tasks** — track when it went from silent to live

2. **Extract Event Timelines efficiently** — instead of repeated `browser_scroll` + `browser_snapshot`, use `browser_console`:
   ```js
   document.querySelector('.phui-timeline-view').innerText
   ```
   This returns the full timeline as plain text. For long timelines, substring it:
   ```js
   document.querySelector('.phui-timeline-view').innerText.substring(0, 5000)
   document.querySelector('.phui-timeline-view').innerText.substring(5000, 10000)
   ```

3. **Find the first commit** via GitHub API (Wikimedia mirrors all Gerrit repos to GitHub):
   - Gerrit repo → GitHub mirror at `github.com/wikimedia/mediawiki-extensions-<Name>`
   - Get the last page of commits: `curl -sI "https://api.github.com/repos/wikimedia/mediawiki-extensions-<Name>/commits?per_page=1" | grep link` → extract `rel="last"` page number
   - Fetch that page: `curl -s "https://api.github.com/repos/wikimedia/mediawiki-extensions-<Name>/commits?per_page=1&page=<N>"`
   - The initial commit message often reveals what it was forked from (e.g. "subset of the Homepage feature of the GrowthExperiments extension")

4. **Check the extension page on mediawiki.org** — `https://www.mediawiki.org/wiki/Extension:<Name>` — for:
   - **Release status** (experimental/stable/beta)
   - **Author and team**
   - **Required MediaWiki version**
   - Whether the page is marked as a draft

5. **Synthesize the timeline** — the deliverable is a date-ordered table showing: repo creation → first commit → deployment to pilot wikis → deployment to target wiki → live config activation → current status/epic.

See `references/researching-extension-history.md` for a worked example (PersonalDashboard, 2025–2026).

---

## Quick Reference Card