In working on T406286: Introduce a subscribable "Updates" section to wishes, I realized for automatic updates, we're effectively doing the same thing that MediaWiki's built-in logging system does. So we might as well make use of it.

This would be great for monitoring meaningful changes to the Wishlist as a whole. All wish/FA creations, status changes, and focus area assignments will be viewable in one place.

In addition, the team has said we'd like to track how long it takes on average for wishes to go from "Under review" (when first created) to a traiged status. Having this data in the logging table would make it possible to query for this.

Acceptance criteria

• See https://www.mediawiki.org/wiki/Help:Log for general information on logging
• There should be a new log type at Special:Log called "Community Wishlist log" (short link Special:Log/communityrequests)
• There should be five "action" types that get logged:
  • Wish creation
  • Wish status change
  • Wish focus area change
  • Focus area creation
  • Focus area status change
• Links to wishes and focus areas in the log entry should include the entity title with the page title in parentheses

Derived Requirements

1. The system must introduce a new MediaWiki log type named Community Wishlist log, accessible via Special:Log/communityrequests, and visible in the general Special:Log interface.
2. The Community Wishlist log must record meaningful lifecycle events for wishlist entities to support monitoring and analytics across wishes and focus areas.
3. The system must log the following five action types under the Community Wishlist log:
   • Wish creation
   • Wish status change
   • Wish focus area change
   • Focus area creation
   • Focus area status change
4. Each log entry must include a link to the affected wish or focus area, displaying the entity title followed by the page title in parentheses.
5. Logged data must be sufficient to support time-based analysis, including measuring the duration between wish creation (initial “Under review” status) and subsequent triaged status changes.
6. Logging behavior must align with MediaWiki’s standard logging framework and conventions as documented in Help:Log.

Test Steps

Test Case 1: Community Wishlist Log Availability and Visibility

Preconditions

• Tester has permission to view Special pages.

1. Navigate to Special:Log.
2. Review the list of available log types.
3. Navigate directly to Special:Log/communityrequests.
4. ✅❓❌⬜ AC1: Verify that a log type named Community Wishlist log is available in Special:Log and that Special:Log/communityrequests loads successfully and displays log entries (if any).

Test Case 2: Logging of Wish Creation and Initial Status

Preconditions

• Tester has permission to create wishes.

1. Create a new wish via the Community Wishlist interface.
2. Note the initial status assigned at creation (e.g., “Under review”).
3. Navigate to Special:Log/communityrequests.
4. Locate the most recent log entry.
5. ✅❓❌⬜ AC2: Verify that a log entry exists for Wish creation, includes a link to the wish, and displays the entity title with the page title in parentheses.

Test Case 3: Logging of Wish Status and Focus Area Changes

Preconditions

• An existing wish is available.

1. Change the status of the wish to another valid status.
2. Assign the wish to a different focus area.
3. Navigate to Special:Log/communityrequests.
4. Identify the relevant log entries.
5. ✅❓❌⬜ AC3: Verify that separate log entries are created for Wish status change and Wish focus area change, and that each entry correctly links to the wish with the required title format.

Test Case 4: Logging of Focus Area Creation and Status Changes

Preconditions

• Tester has permission to manage focus areas.

1. Create a new focus area.
2. Change the status of the newly created focus area.
3. Navigate to Special:Log/communityrequests.
4. Locate the corresponding log entries.
5. ✅❓❌⬜ AC4: Verify that log entries are created for Focus area creation and Focus area status change, each linking to the focus area with the entity title and page title in parentheses.

Test Case 5: Log Data Supports Time-to-Triage Analysis

Preconditions

• At least one wish has progressed from “Under review” to a triaged status.

1. Identify a wish with logged creation and subsequent status change entries.
2. Review timestamps for the Wish creation and Wish status change log entries.
3. Compare timestamps to ensure duration can be derived.
4. ✅❓❌⬜ AC5: Verify that log entries contain accurate timestamps and action data sufficient to calculate the time elapsed between initial creation (“Under review”) and a triaged status change.

QA Results - Meta Beta