Grants:Programs/Wikimedia Community Fund/Rapid Fund/UTRS overhaul (ID: 23759296)
Applicant details
[edit]- Main Wikimedia username. (required)
Chaotic Enby
- Organization
N/A
- If you are a group or organization leader, board member, president, executive director, or staff member at any Wikimedia group, affiliate, or Wikimedia Foundation, you are required to self-identify and present all roles. (required)
N/A
- Describe all relevant roles with the name of the group or organization and description of the role. (required)
Main proposal
[edit]- 1. State the title of your proposal. This will also be the Meta-Wiki page title.
UTRS overhaul
- 2. and 3. Proposed start and end dates for the proposal.
2026-04-03 - 2026-10-25
- 4. What is your tech project about, and how do you plan to build the product?
Include the following points in your answer:
- Project goal and problem you solve
- Product strategy or project roadmap
- Technical approach (infrastructure, tech stack, key tools and services)
- Integrations or dependencies (if any)
On the English Wikipedia, several community-developed systems have risen to the level of core infrastructure because of their impact on our ability to execute our editing mission. A key focus of that infrastructure is providing a way for blocked editors to return to good standing. In that regard, the two principal pieces of infrastructure are: UTRS, the Unblock Ticket Request System, and the on-wiki unblock appeal system. These systems are crucial to the English Wikipedia's mission because they provide a way for innocent editors or potential editors who are subject to technical restrictions as collateral damage from responding to abuse to have their editing privileges restored and serve as the funnel through which formerly disruptive users can return to the project and become active editors in good standing, contributing to our projects once more. The scale and magnitude of these two purposes cannot be overstated. It's likely that a double-digit percent share of all potential editors cannot actually edit when they attempt to do so because they are caught as collateral damage in our anti-abuse systems (including all T-Mobile users in the United States and everyone who — knowingly or not — uses iCloud Private Relay to edit).
Unfortunately, these systems were developed long ago and lack core user experience elements, both for editors trying to appeal their blocks as well as for the administrators that respond to those appeals. For example, to appeal through the on-wiki system on the English Wikipedia, users are instructed to copy template text onto their user talk page — template text that looks like "
|
This blocked user has asked to be unblocked.
Request reason: Your reason here CR-FluxxBot (talk) 00:33, 26 February 2026 (UTC)
|
". There is no intuitive explanation for what a persuasive reason might be, or what the template does, or what a user talk page is, or how to avoid a number of possible mistakes that might lead the user's appeal to be rejected (or worse, never be seen). If a user is unable to use the on-wiki appeal system (often for technical reasons), they are often directed to the Unblock Ticket Request System, which includes a number of user experience issues of its own. Appellants must write down an "appeal key", without which they cannot receive any updates to their appeal or respond to questions from administrators regarding their appeal. The email function is additionally non-functional, making it harder for appellants with less technological literacy to stay updated and respond to administrator concerns in a timely manner.
On the administrator side, the UTRS system is also unintuitive: "accept" and "decline" buttons will automatically close the appeal window without a confirmation prompt, and without the ability to give an explanatory comment (for which a different accept/decline tool is to be found at the very bottom of the page), while the screen is covered in unclear, unexplained icons. This leads to regular mistakes from administrators unfamiliar with the process, where blocked editors may find their requests accidentally denied with little explanation. As we strive to engage more administrators in the still-overburdened unblocks process, the learning curve of UTRS (and the accompanying learning cost) proves to be a major hurdle.
The goal of this grant project is to take steps towards dramatically improving the usability and experience of the latter system, which has been lacking in maintenance for years since a previous grant led to its development by AmandaNP. Improvements on UTRS will be organized along several axes, with the specifics being refined through rapid iteration and development after prototyping. The first and most urgent aspect is the redesign of the UX from the perspective of the blocked user. Email notifications will be re-established, while the appeal key system will be worked on to make it into a more intuitive system, with less risks of blocked users being locked out of their own appeals. Instructions provided to blocked users, both by email and on the platform, will also be clarified.
A second key aspect will be streamlining the message system: the ability to link other appeals or on-wiki pages is still lacking, while basic formatting such as line breaks or Markdown is missing, hindering communication in more complex cases. These will be added, alongside edit-conflict handling replacing the unintuitive "reserve/release" system. Redesigning the user interface for administrators ties into this aspect: requested quality-of-life updates such as confirmation prompts when accepting or declining without a reply, highlighting appeals with unread comments, or hover info-bubbles explaining the meaning of some unfamiliar buttons and icons.
The broader design will also be refined to integrate the Codex design system, offering a more modular framework for future improvements. Among other changes, this will allow the current appeal list visible to administrators to be turned into a functional dashboard, with configuration (e.g. showing or hiding appeals requiring a CheckUser or a UTRS administrator to move forward) and sorting appeals based on their current status, allowing for a streamlined processing.
On the technical level, UTRS is currently coded in PHP, with the frontend being built from the non-jQuery framework Bootstrap 4. The latter will be updated to Bootstrap 5 with an integration of Codex packages through BootstrapVue, while the backend will build on the existing Laravel PHP framework.
- 5. What is the expected impact of your project, and how will you measure success?
Include the following points in your answer:
- Milestones and progress tracking
- Project impact and success metrics
The two groups targeted, blocked editors and administrators, are both a source of relevant feedback, which will be the source of our success metrics. A wishlist of useful improvements has already been circulated among administrators, forming the basis for some of the suggested changes. This will form the basis of our milestone tracking, with advancements in each point of the wishlist being publicized in real time.
While blocked users are harder to directly poll, their feedback is arguably the most essential, and outreach efforts should take into account the various levels of technological literacy among involved users. A two-weeks period of A/B testing (from Sept. 26 to Oct. 9) will involve A/B testing to compare the legacy and improved versions of UTS from the perspective of blocked users and administrators alike, who will both be invited to provide both ratings on several UX aspects and textual feedback. In the case of administrators, the paucity of regularly engaged administrators makes it difficult to envision a truly blind A/B testing without splitting the available administrator pool even more, but administrators will be provided with both versions during the transition period.
A second evaluation period from Oct. 10 to Oct. 25 will be focused on evaluating metrics directly on the improved version of UTRS. Our most basic metric will be the speed of acceptance of a request, both for the mean and median requests, which are expected to substantially differ due to the presence of outliers staying in the queue for an extended period of time, the latter of which are also a target of the improvements. A success metric will be a 20% reduction in processing time for both mean and median requests. Other metrics are being considered, such as an increase in the proportion of accepted requests, or a diminution in the proportion of requests being abandoned, and precise metrics will be established through project iteration.
- 6. Who is your target audience, and how have you confirmed there is demand for this project? How did you engage with the Wikimedia community?
Include the following points in your answer:
- Project demand and target audience description
- Links to interaction(s) with Wikimedia community
- Evidence from community consultation such as the [Community Wishlist]
The main targets are administrators involved in unblocks and blocked users themselves. Administrators have repeatedly made requests for UTRS improvements, citing the unintuitiveness of the current architecture, which have culminated in the current wishlist, mirroring and expanding on many of the concerns with the UTRS interface previously mentioned by administrator Asilvering in their unblocks guide. A concrete example of issues encountered while processing UTRS appeals can be found here. While the second demographic, blocked users, is harder to poll, this will happen iteratively through the development of UTRS, which will offer avenues for users to provide feedback.
Kevin Li (User:L235), who is advising on this project, confirms that the state of the Unblock Ticket Request System, and the need for broad improvements to the technical infrastructure for unblocks, was the subject of a substantial portion of a January 22, 2026, video discussion between eight English Wikipedia functionaries, one Steward, and eight members of the Wikimedia Foundation's Product Safety and Integrity Team.
- 7. How will your team predict and manage potential user security and privacy risks, and what risks do you currently see?
Include the following points in your answer:
- The level of in-house or consulted security and privacy expertise you will have available to you during delivery of this project
- How your development, testing, and deployment processes mitigate the introduction of unnecessary security or privacy risks
UTRS has had a long time role of handling private appeals, and any expansion of the existing framework naturally leads to the same threat models and privacy questions being reconsidered. The main threat model of repeated long-term abuse is currently handled by the tool administrators, and the implementation of the ability to forward problematic appeals directly to tool administrators, closing them from the view of other administrators by default, will facilitate this handling and minimize the potential for harassment.
Privacy issues, alongside other threat vectors such as email harassment and impersonation, will be worked on with advice from experienced UTRS administrators and developers. All data collected for success tracking and feedback purposes will be anonymized, and differential privacy measures will be additionally implemented for the data of blocked users, as the amount of data points will allow for it.
- 8. Who is on your team, and what is your experience?
Include the following points in your answer:
- Your experience as a developer, relevant past projects
- Wikimedia SUL (developer), Gerrit, Github, Gitlab or other relevant public account handles
- Other team members, their roles and expertise
Ilyas Lebleu (User:Chaotic Enby; GitHub, Phabricator) is the principal grantee on this project. Ilyas is an Administrator on the English Wikipedia and the creator of the Unblock Wizard. After noticing that many blocked editors were provided little guidance, and that unblock requests could stay open weeks to months without moving forwards, they have worked to help the unblock process in many different ways. This took the form of advising blocked editors on the expectations of block appeals, helping them give relevant information that helped administrators process the cases more easily, and even negotiating unblock conditions that both the appellant and the reviewing administrator could agree on. As many of these discussions focused on the same aspects, this all culminated with the creation of the Unblock Wizard, which guides editors through unspoken requirements of the unblock process by turning them into explicit questions.
As an administrator, in addition to continuing their previous work, they have acquired more experience with unblocking users, now through both talk page appeals and through UTRS, with the latter often bringing the most difficult cases. They have also worked on many other technical projects, from being a regular contributor to Twinkle (current development forks) to writing the Page Interaction Utility, and hope to bring this experience to UTRS. Ilyas is a graduate of Ecole Normale Supérieure, Paris, having obtained a M.S. equivalency (DENS) there, alongside a M.S. in Computer Science (IASD track) at Paris Dauphine, and is currently a PhD student at Inria.
Kevin Li (User:L235; Phabricator) is a volunteer advisor on this project. Kevin is a longtime English Wikipedia administrator, CheckUser, and Oversighter, and served for four years on the English Wikipedia Arbitration Committee. Kevin coordinates ongoing high-bandwidth conversations and product alignment efforts between the English Wikipedia functionary corps and the Product Safety and Integrity team within WMF P&T. Kevin was formerly an M.S. Candidate in Computer Science (Artificial Intelligence track) at Stanford University.
- 9. How will the project be maintained long-term?
Include the long-term maintenance plan with maintainer(s) in your answer. If you expect the long-term maintenance to incur expenses, please list those and the plan for long-term expense coverage.
The long-term maintenance of UTRS will follow the existing schema. As the code is and will be present on GitHub, any technical issues and improvements may be suggested through Git pull requests or on-wiki proposals. I will remain available to respond to any such suggestions, without further expenses being necessary.
- 10. Under what license will your code be released, and how will you ensure the product is well documented?
Include the following points in your answer:
- Code license and compatibility with Wikimedia projects
- Documentation plan
UTRS is currently released under the AGPL-3.0 license, and this will be continued in this new version. Current documentation on UTRS focuses on developer-first aspects and is only accessible on GitHub, with a brief additional documentation on-wiki, with very little of it aimed towards blocked users (the main audience). This new version will expand this to also provide an accessible documentation for both blocked users and admins directly on the platform, the latter being also available as an onboarding guide in the perspective of recruiting new admins to help in the unblock pipeline.
- 11. Will your project depend on or contribute to third-party tools or services?
The project will exclusively focus on, and build upon, the existing UTRS architecture.
- 12. Is there anything else you’d like to share about your project? (optional)
Budget
[edit]- 13. Upload your budget for this proposal or indicate the link to it. (required)
https://docs.google.com/spreadsheets/d/1LGHBpeOblmelCw2048sefQANre9ituNwPMi6Thrk13Y
- 14. and 15. What is the amount you are requesting for this proposal? Please provide the amount in your local currency. (required)
4125 EUR
- 16. Convert the amount requested into USD using the Oanda converter. This is done only to help you assess the USD equivalent of the requested amount. Your request should be between 500 - 5,000 USD.
4887.84 USD
- We/I have read the Application Privacy Statement, WMF Friendly Space Policy and Universal Code of Conduct.
Yes
Endorsements and Feedback
[edit]Please add endorsements and feedback to the grant discussion page only. Endorsements added here will be removed automatically.
Community members are invited to share meaningful feedback on the proposal and include reasons why they endorse the proposal. Consider the following:
- Stating why the proposal is important for the communities involved and why they think the strategies chosen will achieve the results that are expected.
- Highlighting any aspects they think are particularly well developed: for instance, the strategies and activities proposed, the levels of community engagement, outreach to underrepresented groups, addressing knowledge gaps, partnerships, the overall budget and learning and evaluation section of the proposal, etc.
- Highlighting if the proposal focuses on any interesting research, learning or innovation, etc. Also if it builds on learning from past proposals developed by the individual or organization, or other Wikimedia communities.
- Analyzing if the proposal is going to contribute in any way to important developments around specific Wikimedia projects or Movement Strategy.
- Analysing if the proposal is coherent in terms of the objectives, strategies, budget, and expected results (metrics).
This is an automatically generated Meta-Wiki page. The page was copied from Fluxx, the web service of Wikimedia Foundation Funds, where the user has submitted their application. Please do not make any changes to this page because all changes will be removed after the next update. Use the discussion page for your feedback. The page was created by CR-FluxxBot.