Page MenuHomePhabricator

Community Tech: Wishlist Survey ideas and Q&aA
Closed, ResolvedPublic


The Community Tech team is starting to scope and define the work for the top 10 wishes in the Wishlist Survey. We're currently doing our preliminary evaluation on all 10 wishes, and there are lots of questions to ask and ideas to explore.

Links to learn more, and contact the team:

Survey results page, with links to each proposal and Phabricator task

Survey Phabricator board, with all 106 proposals

Top 10 working notes page, with current ideas

Etherpad of the session notes

Copied here just in case:

A reminder: all current as well as past content in any pad is public forever. Removing content from a pad does not mean it is deleted.

NEW: please add a link to your new EtherPad to

Session name: Community Tech: Wishlist Survey top 10 ideas and Q+A
Meeting goal: To investigate and address the survey top 10
Meeting style: Education: teaching people about an agreed solution

Phabricator task link:

Link to slides: FIXME

Topics for discussion:

General notes

  • Introducing the team.
  • Background: how the community wishlist survey went (details in slides)
  • Community Tech has commited to investigate and solve the top 10. Being totally transparent during the whole process as opposed to coming back in 6 months.
  • From the product management perspective, how to start 10 big projects at once?
    • Talk with the people already working around these features, discussion, specs.
  • Going through the top 10 (details in slides).
    • The team commits to resolve problems, not to implement specific solutions (this came as a consequence of "Add user watchlist", a controversial solution, even if the problem is understandable).

Q: What happens if a feature requested is really not wanted by the WMF or by a community?
A: (The idea is to identify problems, Community Tech will propose solutions, and discuss them).

Q: If the user(s) who propose that did it for anti-vandalism purpose or to have a way to collaborate in a better way, that is not the same. How can we know that?
A: Again, first we will try to understand the problem that needs fixing, and then we will figure out a solution that respects user privacy etc.

Comment about an unsolicited feature: Most of the concerns are already being highlighted by community members in those proposals.

Q: Have we thought about how to get it out into the world?

  1. Define a problem (or however many are leading them to request a feature)
  2. This is technical difficulty, community difficulty: a rubric

A: [Danny]

  • Page about investigations, public notes
  • Discussions at Hackathon, Dev Summit, Wikimania - talking to folks, getting ideas
  • Publish a detailed assessment afterwards - We have a more formal assessment process (kaldari)
  • It is important that the community is aware of the assessment criteria and understand why a feature requested might not pass.

Q: You said you are talking to the German chapter's team too; how does this survey compare/relate to the two "technical wishes" surveys that WMDE ran on the German Wikipedia in 2015 and 2013? ( )
A: (it was not replied directly, but Community Tech and TCB team have been working in sync for months, they have regular meetings, etc.)

Q: You are a small team and these requests involve very different features, How you plan to address this? And what is the maintenance plan?
A: Tough problem indeed. For tool labs and bots we're actively trying to work with volunteers already working on it. For future, we might try to offload some stuff to other teams, collaborate with Wikimedia DE team.
A: We need to understand that omly ramping up the development of each of these features takes time.
A; One problem that we cannot solve is the fact that currently we have zero designers.
Comment: this is a list of identified tasks that can be handled in different ways: done by Community Tech team, pushed to WMF team priorities, good for hackathons, good for Google Summer of Code / Outreachy, good for Individual Engagement Grants...

Suggestion: This survey is a kind of popularity contest. People without a loud voice are represented. Why not consciously select groups for proposals (one for sysops, one for stewards, etc. etc.)?
A: Yes, possible, later. We do need to take care of projects, like Wikisource who expressed some needs, but don't have the massive userbases.

Q: Are there any tasks blocked by lack of resources in WMF Operations?
A: we believe not (beyond general reliability issues, which are known).

Q: Lydia wants to talk about translatable Commons categories (later!)
Discussion on translatable categories:

  • tried solutions: multiple categories in multiple languages (doesn't scale); category redirects, was shot down at some point (this happens some on Commons, but it's
  • how to track what has been translated/what needs?
  • no UI explaining this is an option
  • Is localized labels an option, like TranslateWiki? Well... you already have this information on Wikidata, it's how to get it out. want to avoid duplication of work.
    • But how do you keep track of correctness of translations? Especially licenses.
  • Question: if you do this with wikidata, what's the future of categories? coexisting systems? tags?
    • Tags are both a technical and social issue.

Q: How is the list refreshed?
A: We are thinking once a year, and being i.e. 17th in one edition doesn't earn any rights in the following edition. We start from scratch in every survey.

Q: What if we keep it open for ongoing voting and freeze it at certain times?
A: - One drawback is older things have a tendency to get more weight.

  • Won't get anything else done if we had to keep track of discussions in voting sections year-round.

Moriel: For Central repo task - RTL will be a problem. Lot of duplicated but modified templates because of language stuff. Maybe do something preliminary first - translatable templates?

Comment: One thing that Community Tech could model for the rest of WMF dev teams is a good way to say No, and why not solving a community request, providing the reasoning -- as opposed at simply not answering or ignoring the problem.

Comment: it is also good to find ways to provide data before/after the implementation of a feature, in order to show the impact, instead of relying only on discussions about a feature.

Comment: encourage the team to work with volunteers to rewrite the titles... (the slide show the short version in fact they are longer) - frame problems consistently

Comment: beyond top 10, the full list contains lots of very interesting ideas, and we hope other developers looks at tem and pick some.

Comment: did anyone mention why only endorsements, no negative votes?
Related comment: editors communities expect more consensus process, but tech community doesn't work like that. This is a good thing.

In progress

  • Migrate links to Wayback Machine
    • Cyberpower's bot works
    • In conversation with Internet Archive

Discussion about User watchlist -

  • Mentor-mentee
  • Taking care of vandals


  • Stalking/possible harassment

Suggested approaches:

  • Have a mutual agreement - follow and agree to be followed

Action items with owners:

DON’T FORGET: When the meeting is over, copy any relevant notes (especially areas of agreement or disagreement, useful proposals, and action items) into the Phabricator task.

See for more details.

Event Timeline

DannyH raised the priority of this task from to Needs Triage.
DannyH updated the task description. (Show Details)
DannyH subscribed.
DannyH claimed this task.

Done, it was great. Thanks, everybody!

Any action items? I think this suggestion from @Elitre deserves investigation, and an own task would help us not forgetting about it:

Suggestion: This survey is a kind of popularity contest. People without a loud voice are represented. Why not consciously select groups for proposals (one for sysops, one for stewards, etc. etc.)?
A: Yes, possible, later. We do need to take care of projects, like Wikisource who expressed some needs, but don't have the massive userbases.

@DannyH: Could you answer @Qgil's last comment, please?

I don't think it's necessary to create a task about that. We're not going to forget about it -- that's the strongest criticism of the Wishlist process that really hit home. :) It's definitely going to inform our planning for the next Wishlist survey, assuming that we're successful with this year's Wishlist.