This page is a translated version of the page Community Wishlist Survey/Description and the translation is 22% complete.
Outdated translations are marked like this.

社群技术团队的首要任务是开发改进的、利于专家使用的用于管理及审核的工具,以满足维基媒体编辑者的需求。此团队正是核心贡献者为改善审核工具、机器人还有其他促成各维基媒体项目成功的功能上的援助,而提出创立的。

2015年11月,社群技术团队进行了第一度的跨项目社群愿望调查,以确认对维基媒体编辑者最需要的功能和修理。我们邀请了来自各维基媒体项目的贡献者为社群技术团队提交建议。两周接受提议后,我们要求众多贡献者为符合自己心意的愿望投票。获票最多的提案将成为团队的优先研究及处理的代办事项。自此,每年都会重复该程序。

理由

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.

場地

該調查本身是在Meta進行的。在維基網頁上進行調查而不使用第三方調查工具,有幾個原因:

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

Participation requirements

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.

Phase 1: Submitting proposals

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.

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? (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?

Phase 2: Reviewing and organizing proposals

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.

Prioritization of Wishes

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:

 
Prioritization Score for Community Tech Proposals

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.

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.

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.