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. Most of them are specific to a particular wiki or are completely dominated by English-language participants.

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. In particular, they should be discreet, 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. As proposals are made, the Community Tech team will offer feedback on their technical feasibility and whether or not they fit the scope of the team’s work. 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. We will be soliciting volunteer translators to translate the proposals into as many languages as possible via the Translate extension.

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 hide or remove any that are outside the scope of the survey, are not realistically feasible, or did not receive any endorsements. Approved submissions will then be grouped into sections and translated by volunteers. Once the proposals have been translated, the survey will enter the voting phase. During the voting phase, editors will vote on which submissions they would most like the Community Tech team to work on. The voting methodology will be left up to the community. When the voting has concluded, the top X requests will be copied to a new wiki page, along with their final vote tallies.

Analysis and prioritization
Each of the top X 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 X 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).