Grants:Programs/Wikimedia Community Fund/Rapid Fund/UTRS User Experience Development (ID: 22215192)
This is an automatically generated Meta-Wiki page. The page was copied from Fluxx, the grantmaking web service of Wikimedia Foundation 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.
Applicant Details edit
- Main Wikimedia username. (required)
AmandaNP
- 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. Please state the title of your proposal. This will also be the Meta-Wiki page title.
UTRS User Experience Development
- 2. and 3. Proposed start and end dates for the proposal.
2023-09-01 - 2023-12-31
- 4. Where will this proposal be implemented? (required)
Canada
- 5. Are your activities part of a Wikimedia movement campaign, project, or event? If so, please select the relevant project or campaign. (required)
Not applicable
- 6. What is the change you are trying to bring? What are the main challenges or problems you are trying to solve? Describe this change or challenges, as well as main approaches to achieve it. (required)
UTRS has always been first and foremost about the users who have barriers to accessing editing on Wikipedia, whether directly or indirectly blocked. UTRS version 1 was built back in 2012 with version 2 being started in March 2020. Other then the rigid wikitext and templates required for an onwiki appeal, the only previous system before this was the Unblock list. The unblock list had many flaws, was untrackable, some people were just ignored, and there was no real way to handle innocent users affected by blocks.
With this proposal, we are just continuing to improve the process and hoops users have to jump through so it’s less time consuming for both administrators and editors.
Translating the user interface - The ultimate goal is for this to be available for any wiki that wants it. Portuguese Wikipedia has been wanting it for years, but the translation support has simply stalled out. We are therefore unable to deploy this system because users can’t access the system in their local language. They would have to use English. Same with any other project. Now that UTRS has extended to global locks, its now more critical than ever that a wide variety of languages be available that people understand and can work in. The base framework already exists, it just needs to become easier to access for translators, and an audit of the tools messages needs to be done to finalize the work on this project.
Allowing ACC transfers - Most users that are blocked don’t find ACC very easily, when in fact, it’s the most important tool when it comes to innocent users affected by large rangeblocks. This tool & team has the capability to respond and create accounts for users.
It’s absolutely critical for UTRS to be able to transfer appeals to ACC because UTRS is the first line of appeal for new users innocently affected by these blocks. We don’t want these users getting so frustrated with the process that jumping between two systems stops them from editing. Beyond that, there is often a discontinuity between users using both platforms and we can’t understand their reason for reaching ACC in the first place, which can require more user interaction before creating an account.
Continuous appeals - Both administrators and users frequently note that it’s hard to maintain any sort of continuity between appeals. This can be simply because they are completely separate except for a link, or it could be the fact that the user couldn’t reply in a timely fashion to an old appeal. By making appeals continuous, users & administrators can easily see the history, and previous conversations, and look for easier ways forward that could ultimately result in a user being unblocked.
- 7. What are the planned activities? (required) Please provide a list of main activities. You can also add a link to the public page for your project where details about your project can be found. Alternatively, you can upload a timeline document. When the activities include partnerships, include details about your partners and planned partnerships.
These GitHub issues are ever evolving to what will occur with the design of them when the work starts. Translating the user interface - https://github.com/UTRS2/utrs/issues/378 Allowing ACC transfers - https://github.com/UTRS2/utrs/issues/634 & https://github.com/enwikipedia-acc/waca/issues/779 Continuous appeals - https://github.com/UTRS2/utrs/issues/635
- 8. Describe your team. Please provide their roles, Wikimedia Usernames and other details. (required) Include more details of the team, including their roles, usernames, Wikimedia group, and whether they are salaried, volunteers, consultants/contractors, etc. Team members involved in the grant application need to be aware of their involvement in the project.
The “team” would just be me. I would be focusing on 3 areas. Actual development would be the primary. Debugging & testing would be secondary. Administration (Community consultation, project management, task updating/documentation) is the final category. Volunteer me, aka work not covered under this grant would handle any server maintenance & deployment issues that occur.
- 9. Who are the target participants and from which community? How will you engage participants before and during the activities? How will you follow up with participants after the activities? (required)
The targetted participants of this work are UTRS users, aka users affected by an interface placed block or global lock. The only way that retention can be measured for this sort of project is successful unblock requests. For users that are blocked for conduct - it’s not meant to be a very high metric to begin with, as there are already issues with the user’s behavoir that got them to this point, but any increase to successful appeals would be considered retention. Further any users that get passed on to ACC will be considered retained as that is the form of a successful appeal. Upon the closure of the UTRS ticket, an email will get generated to the end user already. In that, it will contain a link to a survey about the the design of UTRS using the following points: · 5 point scale – If you were not the target of a block, how much does the automated system requesting an account on your behalf assist you? · 3 point scale – How much did having the page translated into your language assist you? Can you describe how having the appeal being translated into your language helps you? · Is this your first appeal? o Yes - If you had to file another appeal, would you find it easier if the administrator was able to review your response to this appeal? If not, what would you improve about the appeal process through UTRS, the system you used? (Please note we are not asking about onwiki policies, your block or the administrator’s response – we are looking for feedback on the software) o No - Did you find continuous appeals to assist you with your unblock request this time? Can you name one thing about continuous appeals that made this process easier for you?
The improvement work being implemented for this proposal is directly trying to make things more equitable in the wikisphere. There are two sort of paths to UTRS for the end user. 1) being affected by a block prohibiting you from editing in the first place 2) “users first big problem” aka getting blocked. When a user enters at the block prohibiting first edit stage, they are greeted with block messages that eventually lead to UTRS. It’s well understood that people not belonging to majority groups for large countries, first language not being a major language, and IT literacy all being struggles of new users. These new users need assistance which UTRS can provide them, if it is continuously improving the unblocking experience. Right now, translation support & ACC appeal transfers need code fixes to release the pressure on users from these areas to contribute. Translation support removes barriers to language, where as ACC appeal transfers tackle the language and IT literacy barriers of not requiring multiple applications and process understandings to navigate the environment of being blocked. It streamlines and automates this process. When it comes to blocking users, language and cultural barriers can be an issue. Through some of the development work planned, continuous appeals will be the cornerstone that helps this so that administrators can review the entire appeal history to understand the context that might get lost appeal to appeal and administrator to administrator. There are several geographic regions that encounter abnormal difficulties compared to the rest of the world. ISPs are not providing proper infrastructure to the point they get caught in a block or government suppression or cause users to be blocked to feel safe when using VPNs. The whole point of developing UTRS in the first place was to address these barriers, and with this proposal, I would have a chance to address them even further.
- 10. Does your project involve work with children or youth? (required)
No
- 10.1. Please provide a link to your Youth Safety Policy. (required) If the proposal indicates direct contact with children or youth, you are required to outline compliance with international and local laws for working with children and youth, and provide a youth safety policy aligned with these laws. Read more here.
N/A
- 11. How did you discuss the idea of your project with your community members and/or any relevant groups? Please describe steps taken and provide links to any on-wiki community discussion(s) about the proposal. (required) You need to inform the community and/or group, discuss the project with them, and involve them in planning this proposal. You also need to align the activities with other projects happening in the planned area of implementation to ensure collaboration within the community.
There is frequently a lack of community discussion regarding changes to UTRS generically as the niche of supporting blocked users rarely falls on those who administer the blocks. Discussion can occur through the Github issues pages where community members can propose changes and fixes to current process issues. Otherwise, the “consultation” comes from direct 1 on 1 interaction with those complaining about how UTRS does not work, or seeing the struggles happen first hand through the platform. Github link: https://github.com/UTRS2/utrs/issues?q=is%3Aissue
- 12. Does your proposal aim to work to bridge any of the content knowledge gaps (Knowledge Inequity)? Select one option that most apply to your work. (required)
Not applicable
- 13. Does your proposal include any of these areas or thematic focus? Select one option that most applies to your work. (required)
Open Technology
- 14. Will your work focus on involving participants from any underrepresented communities? Select one option that most apply to your work. (required)
Not applicable
- 15. In what ways do you think your proposal most contributes to the Movement Strategy 2030 recommendations. Select one that most applies. (required)
Improve User Experience
Learning and metrics edit
- 17. What do you hope to learn from your work in this project or proposal? (required)
Given this is not a content project or event, there is only really two goals here. 1) To learn how the unblock system can be improved and what we can do about it. 2) To start collecting data and see if we can identify trends in unblock requests, and modify the system or process around it.
That can be done by: How well the user interface works for end users How many users are being “retained” How many appeals get further down the process than they did before
- 18. What are your Wikimedia project targets in numbers (metrics)? (required)
| Other Metrics | Target | Optional description |
|---|---|---|
| Number of participants | 0 | This is not an event |
| Number of editors | 50 | Newly Registered Users: 45 via ACC transfer program
Returning editors: 5 successful account appeals |
| Number of organizers | 0 |
| Wikimedia project | Number of content created or improved |
|---|---|
| Wikipedia | |
| Wikimedia Commons | |
| Wikidata | |
| Wiktionary | |
| Wikisource | |
| Wikimedia Incubator | |
| Translatewiki | |
| MediaWiki | |
| Wikiquote | |
| Wikivoyage | |
| Wikibooks | |
| Wikiversity | |
| Wikinews | |
| Wikispecies |
- Optional description for content contributions.
N/A
- 19. Do you have any other project targets in numbers (metrics)? (optional)
Yes
| Main Open Metrics | Description | Target |
|---|---|---|
| Percent of additional appeals being filled | The percentage increase in the average number of appeals being filled | 5 |
| N/A | N/A | N/A |
| N/A | N/A | N/A |
| N/A | N/A | N/A |
| N/A | N/A | N/A |
- 20. What tools would you use to measure each metrics? Please refer to the guide for a list of tools. You can also write that you are not sure and need support. (required)
In order to evaluate the results of these metrics, we will be using an end user google survey form that the users will receive as part of the final response to their appeal via email. The other method used will be pure data analysis from the database.
Financial proposal edit
- 21. Please upload your budget for this proposal or indicate the link to it. (required)
https://docs.google.com/spreadsheets/d/1bh4n3mouNuAx4xT2vILLtj_l4o7QvSlCxx3w-bXTTpk/edit?usp=sharing
- 22. and 22.1. What is the amount you are requesting for this proposal? Please provide the amount in your local currency. (required)
6032 CAD
- 22.2. 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.
4550 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).