Community Tech team/Community Wishlist Survey

The Community Tech team will be conducting a cross-project survey to collect technical requests from the Wikimedia communities. If the process proves to be effective for both the community and the team, it may be repeated periodically.

Rationale
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.

Outreach
The team would like to get input from as many editors and as many communities as possible. To accomplish that, we will work with the Community Engagement team and the Communications team to formulate an outreach strategy. This strategy may involve blog posts, site notices, talk page invitations, village pump notices, and/or mailing list posts. We will try to make sure that communities are made aware of the survey well in advance.

Venue
The survey itself will be conducted on Meta-Wiki. There are several reasons for having the survey on-wiki instead of using a 3rd 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.

Scope
Requests should ideally align with the scope of the Community Tech team. (Include brief explanation of scope here.) 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.

Phase 1: Submitting proposals
In the first phase of the survey, we will be soliciting proposals for technical requests. In order to submit a proposal, a user must have at least 100 edits on any project or be an active Tool Labs developer. Proposals will initially be limited to five per person, although this may be relaxed depending on the volume of proposals. The community will be encouraged to organize, discuss, and debate the proposals throughout the first phase of the survey. Proposals must be endorsed by at least one other user in order to be eligible for the voting phase. Similar proposals may be combined to reduce duplication, in which case each duplicate should count as an endorsement.

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.

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

Format of proposals
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? (admins, editors, photographers, all Wikipedia users, etc.)
 * How is this problem being solved now?
 * What are the proposed solutions? (if there are any ideas)
 * Are there any pre-conditions or blockers?

Here is a hypothetical example: Right now, there is no efficient way to find all the articles on Wikipedia that have blurry photographs, so the blurry photograph patrollers have to review every article by hand to find and replace them. It would be great if a bot could be written to analyze all the photographs on Wikipedia and create a list of articles that have blurry photographs. This would benefit the blurry photograph patrollers on all the Wikipedias by making their job easier and would also benefit readers who wouldn't have to see so many blurry photographs. This would only be practical to build if an open source library can be found that can identify blurry photographs. --SharpPhotoEnthusiast632 (talk) 13:19, 20 November 2015 (UTC)
 * I endorse this idea as I hate seeing blurry photographs. --AnotherGuy (talk) 15:37, 21 November 2015 (UTC)

Phase 2: Voting
Once the submission phase is over, we will screen the submissions to remove any that are outside the scope of the survey, are not realistically feasible, or did not receive any endorsements. Proposals that overlap or conflict with projects an existing WMF team's roadmap will be forwarded to the appropriate teams as feedback; they will not be included in the voting phase.

During the voting phase, editors will vote on which submissions they would most like the Community Tech team to work on. Positive votes marked with 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, the top 10 requests with the most Support votes will be copied to a new wiki page, along with their final vote tallies.

Analysis and prioritization
Each of the top 10 requests will be evaluated for prioritization by the Community Tech team according to the following criteria: Of these criteria, support is the most important. Once analysis is complete, a priority will be assigned to the task by the Community Tech team (high, normal, or low).
 * Support
 * How many votes did it get in the survey?
 * Do discussions show consensus for the request?
 * If the task involves working on an existing codebase, are the current maintainers open to us modifying or forking their code?
 * Feasibility
 * How much work is involved?
 * Are there any blockers?
 * Does our team have the necessary knowledge to accomplish the task in a timely manner?
 * Impact
 * How many wiki projects will this benefit?
 * How many editors will this benefit?
 * Will it be a long-lasting solution (or just a temporary fix)?
 * How much will this improve the efficiency and happiness of the communities?
 * Is there existing software that can cover this need? (or software that is already being developed)
 * Risk
 * Are there any potential drawbacks or difficulties?
 * Does it negatively affect any group of editors?
 * Is the task well defined with a clear scope? (i.e. does it have defined acceptance criteria)

Development
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.

A parallel Phabricator workboard called Community-Wishlist-Survey has been created. This workboard will contain task cards for each of the top 10 requests. The purpose of this workboard will be to facilitate internal work organization and discussion of the requests by the team (although community members will also be welcome to participate in the Phabricator discussions).