Community Wishlist Survey 2021/Status report 1

From Meta, a Wikimedia project coordination wiki

Hello everyone! As we emerge from annual planning and finish our ongoing OCR improvements, we (the Community Tech) have also undergone a fair set of changes to our team. We have a total of four new team members, with plans to add another.

In addition to the new members, we are also preparing to support two long-standing members of the team as they go on family leave. We are excited to adapt to change, embrace the learning curve as new team members get up to speed, and continue working for the community.

Next Steps for Wishlist[edit]

Starting late July 2021, the team will start engineering work on the following wishes:

We will also begin the product and design research for the following wish:

We fully expect to be able to complete more wishes than the above. The above list is only what is in our plate starting this July.

Prioritization Process[edit]

How did we arrive at our next steps? We recently completed a new 2021 Wish prioritization process.

Historically, the team has prioritized wishes based on a number of factors. These changed as our team learned over time. There was a time when we promised the “top N” wishes and tried to tackle them between July and June. However, that could be improved since sometimes wishes took longer than anticipated due to complexity. Other times it meant we were rushing to put out a solution. Also, this meant we could get into situations of “over-promising” which could limit volunteers' trust. In 2020, we stepped away from promising a total number of wishes we would grant.

So with these lessons from the past, we sat down to ask ourselves the following question: How can we strive for high value and impact on the community's needs, maintain healthy code, and fulfill as many wishes as possible?

We’ve developed a method to help us approach our wish prioritization more systematically and with transparency. There were a few assumptions built into our process, and I’d like to state those explicitly so that everyone has full visibility:

  • Popularity of a wish should be a very important factor in our selection decision, but not the only one.
  • It is best to stagger wishes so that specialists can collaborate with each other as we progress through work-- i.e. as the designer researches the wish and generates visual components for wish, the engineers focus on a wish that is purely technical
  • It is best to communicate transparently with the communities rather than hiding the details. Visibility builds trust and dialogue.

The process consisted of going through any wish that scored above 70 votes (we cut off any wishes below that, because realistically, it took time to investigate every wish and we knew we wouldn’t be able to grant more wishes) and scored them based on the following criteria:

photo of prioritization score
Prioritization Score for Community Tech Proposals

Once every wish was scored from every vantage point that impacts its feasibility and impact, we ranked them. If we tackle those wishes first, we can tackle most wishes. Also, we can optimize for impact while taking maintenance and complexity into account.

This also meant talking to other teams at the Foundation, and investigating if they were already working on projects related to wishes. You will notice that our results have a tab that lists out all the wishes that teams at WMF are working on related work over the coming fiscal year.

Prioritized Wishlist[edit]

Having completed the above scoring process, the Community Tech team is working on delivering as many wishes as possible in the following order:

Prioritized Wishlist
Proposal Prioritization Score Vote Count Community Score1 Technical Complexity Score2 Product & Design Complexity Score3
Copy and paste from diffs 2.1 124 3 1 1
Warn when linking to disambiguation pages 2.43 134 3 1 3
Templates translation 2.73 203 2 2 4
Live preview 2.97 119 4 1 5
Add sorting options in category pages 4 117 5 3 6
Bibliographic bot for Wikidata 4.07 94 2 1 2
(Un)delete associated talk page 4.47 99 4 1 2
Add filters to history pages 4.63 101 4 2 4
Global semiprotection of user talk pages 4.97 95 4 2 3
Better diff handling of paragraph splits 5.13 101 4 3 5
Automatically suggest categories when creating a new article 5.23 93 2 3 5
Anti-vandalism tools for Wikidata 5.37 81 1 1 5
Multiple watchlists 5.67 110 5 3 4
Allow global user rights to expire automatically 5.97 82 4 2 3
Support 360 photo viewing 6.57 91 2 2 3
Allowing VisualEditor to edit by section 7.37 80 1 1 5
Adopt Lingua Libre Bot service as a WMF tool 7.63 79 4 3 5
Show all active sessions 7.67 81 5 3 4
Map in UploadWizard 7.77 74 3 2 3
Automatically Notify a User when ANY of their subpages are edited 8.17 74 5 2 3
Allow table columns and rows to be freely movable in the Visual Editor 8.27 76 3 3 4
Support multilingual category names 8.8 70 4 2 2
Support ISO 8601-2:2019 to specify uncertainty about times 9.13 75 4 3 2
Tool for recording voiced pronunciation of words 9.27 74 3 3 4
Time and date handling improvements 9.5 72 5 3 3
Improve workflow for uploading books to Wikisource 9.6 72 3 3 6

1 Scale of 1-5, 5 representing highest estimated impact to projects and number of users/readers
2 Scale of 1-3, 3 representing highest estimated technical complexity
3 Scale of 1-6, 6 representing highest estimated product/design complexity

Please note that the prioritization score is what guides a given order of tackling wishes, but in addition to that score we are strategically staggering our wishes via Product and Design <> Technical complexity. We stagger specialists so that they do not block each other while completing work, meaning that the designer and product manager conduct user interviews and tests for wishes with a high Product and Design score. Meanwhile, engineers work on wishes with low product and design complexity so that engineers are not blocked by needing the designs & user research finalized. Think about it like a kitchen-- there are three tables waiting for their food at a restaurant. The first table orders a steamed lobster. The next two tables each order salads. Rather than waiting for the cooks to make the lobster before we serve the second and third table, the other kitchen staff are working to prepare the fresh salad which takes unblocked resources to prep while the order for the first table is steaming. You can think of the prioritization score as the number that each order was placed in, but even with that number there is still some staggering strategy to optimize wish completions.


All in all, we believe this new way of prioritizing wishes will allow us to fulfill more wishes and give us a chance to reflect on how to keep improving the process. We welcome your feedback!

  • What do you think of this approach?
  • Would knowing our prioritization process influence how you approach the proposals for 2022?
  • Would more details about each of the score columns be helpful? We plan to publish a list of articles explaining each column over the coming week.
  • What other details would be helpful to know about as you gain visibility into how we select wishes?

Thank you to everyone who participated in the 2021 Community Wishlist survey. We look forward to hearing to reading your feedback!