Page MenuHomePhabricator

SPIKE: review and assess next steps for "Use of no-JS on RecentChanges and Watchlist" request
Closed, ResolvedPublic

Description

The moderator tools team requests data on the use of no-JS on Recent Changes and Watchlist. This ticket aims to assess the feasibility of the task and define next steps.

Request:

  • % of admins that have disabled JS in their user preferences and/or via a browser setting, then:
  • what % of traffic to recent changes/watchlist are from no-js users.
  • Christopher Ciufo: also curious to segment by user roles: do users with extended rights visit these pages with JS disabled vs. casual editors or readers.

Impact

  • Outcome may impact instrumentation decisions

Related tickets / Resources:

      • [2024 REQUEST] Help me understand how often Administrators disable JS. T357439
      • Recentchanges & watchlist:
    • [2019 Hackday] Analyse user interactions with RecentChanges T223206
    • Clarify intent of "non-JavaScript interface" in recent changes and watchlist (T315632) – rcenhancedfilters-disable applies to recent changes and wlenhancedfilters-disable applies to watch lists.
    • patrolled recentchanges daily activity T368352
    • Watchlist and moderation questions on Slack
    • # of users who enable the "safe mode" preference question on Slack, related to T361684
    • Determine level of no JS usage of Event Registration T359112
    • Most recent related analysis in 2021, 2023 No-JavaScript_notes#Metrics
  • Pulling data on admins
    • Admin data queries (needs verification as it may be outdated)
    • Getting global numbers on Slack
    • Explore possibilities... 01/2024 task on Asana & related assess functionary data task on Asana & related Slack conversation on identifying ways to pull admin data.
  • Moderation/patrolling, tangentially related
    • Explore activity at different levels of patrolling T384860

Acceptance criteria:

  • Irene to discuss task details with task requestor, Jack (timeline, needs...)
  • identify available datasets
  • identify available definitions
  • address unknowns, risks, limits
  • review useful possible outputs
  • discuss estimated time needed and complexity vs utility
  • Irene shares recommendation
  • If the request is feasible and the possible outputs are useful, Irene/Jack agree on the deliverables/timeline and document on this task as next steps.
  • Delineated Risk & Mitigation List as appropriate

Event Timeline

I met with Jack on 4/15/25 and we:

  • reviewed existing metrics on no-JS use. This information is helpful for the team.
  • reviewed querying/tables/outputs on % of admins that have disabled JS in their user preferences using the query written by Jason Sherman:
Select
COUNT(rcefdisable_user) as num_rcefdisable,
COUNT(1) as total,
ROUND(100*COUNT(rcefdisable_user)/COUNT(1), 3) as prop_rcefdisable
FROM
(
SELECT up_user as rcefdisable_user
from user_properties as up
where up.up_property = 'rcenhancedfilters-disable'
and up.up_value = 1
) as rcefdisable
RIGHT JOIN user ON rcefdisable.rcefdisable_user = user.user_id
INNER JOIN user_groups ug ON user.user_id = ug.ug_user
where ug.ug_group in ('sysop', 'extendedconfirmed')

We find these counts for the top 5 Wikipedias (as far as monthly active admin counts):

WikiActive Admins (Source: Wiki Comparison)% of admins w/no JS (Source: query)total admins (Source: query)
English387.4075470
German124<5%>50
Italian106~5-10%>100
French87~5-10%>50

Note: according to the latest Movement Metrics snapshot, we have ~2,000 active admins/month.

Additional data to better understand the No-JS picture is needed: Who are the no-JS admins noted in the table above: how many edits|blocks have they made)? Irene will:

  • pull data on edits or edit-buckets for admins that changed their JS settings
  • pull data on blocks for admins that changed their JS settings (have blocked another user, and how many blocks have they issued)
  • focus on active admins... on the top 5 six wikis (as far as active monthly admins)

Also, Jack W will want/need comparison point(s) for this data...so we will meet again to talk through the findings and ensure that the data is clear/understood/contextualized.
Once this data is delivered and reviewed, we can close the request.

Timing: As the immediate need for the initial request has been dropped/changed, Jack's timeline is flexible. Irene will touch base with Jack on timeline.

available datasets:

  • wmf_raw.mediawiki_logging
  • wmf_raw.mediawiki_private_actor
  • wmf.mediawiki_history
  • canonical_data.wikis

available definitions/queries:

unknowns, risks, limits:

  • what time period do we want to investigate?
  • does this data meet the team's needs?

@Iflorez - what % of the active admins on English wikipedia have turned off JS?

I think if we have data for the past 90 days, we'd have enough information.

Said another way, of the 309 admins who've turned off JS, how many of them are "active?"

Hi @JWheeler-WMF
Circling back....
Do you mean that you see benefit to reducing the scope of the task? And that the info that you need is:
Over the past 90 days, what % of the active admins on English wikipedia have turned off JS?

Or are you clarifying the time-period related to previous task-scoping requested?:
Over the past 90 days, how many edits|blocks have the no-JS admins active admins, on the top 5 six wikis (as far as active monthly admins), carried out

My feedback: "Over the past 90 days, what % of the active admins on English wikipedia have turned off JS?" will give you an simple/clear picture that you can use to compare and contrast, on enwiki, to get a sense of needs/impact for this population (and their JS settings).

Hey @Iflorez - hoping to learn Over the past 90 days, what % of the active admins on English wikipedia have turned off JS? !

This ticket can now be closed. On Wednesday April 30th Jack and I agreed on a COB Wednesday May 14th deadline to answer the question: Over the past 90 days, what % of the active admins on English wikipedia have turned off JS.

A new ticket with the deadline and deliverable is the next step. I will share/post the final query used on the new ticket so that it can be reused at a later time.

jsn.sherman moved this task from Doing to Done on the Product-Analytics (Kanban) board.
jsn.sherman subscribed.

thanks!