社群願望清單调查/描述

This page is a translated version of the page Community Wishlist Survey/Description and the translation is 24% complete.
Other languages:
Bahasa Indonesia • ‎Deutsch • ‎English • ‎Nederlands • ‎Türkçe • ‎dansk • ‎español • ‎français • ‎italiano • ‎lietuvių • ‎polski • ‎português • ‎português do Brasil • ‎suomi • ‎svenska • ‎čeština • ‎македонски • ‎українська • ‎עברית • ‎العربية • ‎فارسی • ‎বাংলা • ‎中文 • ‎日本語 • ‎한국어

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

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.

Analysis and prioritization

Each of the popular requests are evaluated for prioritization by the Community Tech team according to the following criteria:

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

Once analysis is complete, a priority will be assigned to the task by the Community Tech team (high, normal, or low).

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.