Community Wishlist Survey 2021/Status report 1

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.

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

• Copy paste diffs
• Bibliographic bot for Wikidata

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

• Warn when linking to disambiguation pages

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.

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:

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.

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

¹ Scale of 1-5, 5 representing highest estimated impact to projects and number of users/readers
² Scale of 1-3, 3 representing highest estimated technical complexity
³ 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!