Community Wishlist Survey/Description

This page is kept for historical interest. Any policies mentioned may be obsolete. If you want to revive the topic, you can use the talk page or start a discussion on the community forum.

The Community Tech team is focused on meeting the needs of active Wikimedia editors for improved, expert-focused curation and moderation tools. The creation of the Community Tech team is a direct outcome of requests from core contributors for improved support for moderation tools, bots, and the other features that help the Wikimedia projects succeed.

In November, 2015, Community Tech conducted the first cross-project Community Wishlist Survey, to help identify the features and fixes that are most important to Wikimedia editors. We invited contributors from all Wikimedia projects to submit proposals for the Community Tech team. After two weeks of collecting proposals, we asked them to vote on the proposals they were most interested in. The process has been repeated every year since.

We realize there are many existing community wishlists; however, most of them have not been sorted/prioritized by the community, many are out-of-date, and most of them do not have a clearly defined scope for the requests. In addition, we do not know of any technical request surveys that have actively engaged a large number of Wikimedia projects.

The team like to get input from as many editors and as many communities as possible. To accomplish that, we work with the Community Engagement team and the Communications team to formulate an outreach strategy. This strategy may involves blog posts, site notices, talk page invitations, Village Pump notices, mailing list posts, Tech News, IRC, social media and other venues.

The survey itself is conducted on Meta. There are several reasons for having the survey on-wiki instead of using a third-party survey tool:

• Editors are by definition comfortable using wikis and often prefer the transparency and flexibility of wikis over more specialized software. The community itself almost always conducts surveys and polls on-wiki, even for relatively complex polls such as Picture of the Year.
• Wikis easily facilitate simultaneous discussion and voting.
• Translation of proposals can be more easily handled by community volunteers if they are on-wiki.

Requests should ideally align with the scope of the Community Tech team. In particular, they should be discrete, well-defined tasks that will directly benefit the core community. Tasks that are outside of that scope may be declined or referred to other development teams.

In order to participate in the survey (by submitting proposals, endorsing proposals, or voting), a user must have a registered account, with good-faith edits prior to the start of the survey, or be an active Toolforge developer. Anyone, including anonymous IP users, can participate in discussion, however. Cross-wiki edit counts can be verified at Special:CentralAuth.

In the first phase of the survey, we solicit proposals for technical requests. Proposals are limited to three per person. The community is encouraged to organize, discuss, and debate the proposals throughout the first phase of the survey. As proposals are made, the Community Tech team may offer feedback on a proposal's technical feasibility and whether or not it fits the scope of the team's work. A proposal that duplicates or conflicts with items on another WMF team's roadmap may be flagged by the Community Tech team, and not included in the voting phase. This can also happen to items that are not technical requests but e.g. policy discussions, items we know we won't be able to do, or proposals that we simply do not understand and where the proposer doesn't respond to requests for clarification.

While most of this process is be conducted in English, we invite people from any Wikimedia project to submit proposals. We will be soliciting volunteer translators, to help translate the proposal into English.

Proposals may be submitted in any language, but English is encouraged (in order to facilitate feedback from the Community Tech team and other editors). Ideally your proposal should concisely address the following points:

• What is the problem you want to solve?
• Which users would benefit? (editors, admins, Commons users, Wikipedia users, etc.)
• How is this problem being addressed now?
• What are the proposed solutions? (if there are any ideas)
• Are there any relevant Phabricator tasks?

During the second phase, the Community Tech team and the Technical Collaboration team go through the proposals. We organize them, ask for clarifications, merge duplicates and try to get the proposals in as good shape as possible prior to the voting phase so that editors will know what they are voting for, and make sure the proposal is clear on what the benefits would be. Some proposals that are out of scope, not technical requests or impossible for us to work on are archived.

During the voting phase, editors vote on which submissions they would most like the Community Tech team to work on. Positive votes marked with  Support and signature will be counted as the proposal's tally. Comments marked Neutral or Oppose are acceptable, in order to ask clarifying questions or raise potential problems for discussion, but they will not be counted as negative votes.

When the voting has concluded, a full list of the all the requests will be copied to a new wiki page, along with their final vote tallies.

We've developed a method to help us approach our wish prioritization more systematically and with transparency over the years. There were a few assumptions built into our prioritization process which are helpful to name explicitly:

• 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 consists of going through any wish that scores in the top 30 for a wishlist (we cut off any wishes below that, because realistically, it takes time to investigate every wish and we know we will not be able to grant more wishes for a given year) and scores them based on the following criteria:

Once every wish is scored from every vantage point that impacts its feasibility and impact, we rank 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 means talking to other teams at the Foundation, and investigating if they were already working on projects related to wishes.

As each request advances through the development process, its status will be updated on the wiki page allowing the community to easily monitor the team’s progress and offer feedback.

We also work on some requests that didn't perform well in the overall leaderboard but are still very relevant to smaller projects, though our main focus will be on the global leaderboard.