Talk:Community Wishlist Survey 2021

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

For information about the translations, see Community Wishlist Survey 2021/Translation hub.

New format[edit]

Maybe I'm just tired but I do not understand this new format. Am I correct that if the community wants section name in diff, named references in VE, and insert attestation as a corpus the community will have to vote for them again?

I also don't understand what happens after the vote. Some proposal gets the most votes. Is anything promised to happen then? Do I understand correctly that if even the foundation decides to research a project that nothing might happen? Best, Barkeep49 (talk) 05:00, 6 November 2020 (UTC)

@Barkeep49: It has always been true that if our team decides to research a project, it may turn out to be too much work for our small team or for some other reason beyond our control we are unable to take it on. We discuss every wish before we enter the voting phase, but sometimes the unknowns don't surface until we actually start work on the project. This has happened time and time again, where we have to postpone or decline a wish after we promised we would do it in a given year. One or two other wishes always end up taking too much time, and then we are expected to conduct a new survey and commit to yet another new 10 wishes when we haven't finished the previous ones. The system unfortunately just didn't scale. So, under the new system, every year we ask the community what they would like (some are reconfirmations from previous years), and we pick out as many as we can fit throughout the course of the year, piecemeal. This way there are no more broken promises, but we stay just as busy and we know we're working on things people want (and not what they said they wanted from X years ago).

The other advantage is we will have a separate page showing the top wishes in each category. While the global backlog is our priority, some smaller projects don't have the voting power to ever get their wishes addressed. With a separate backlog for say, Wiktionary, we can freely pick out the easy wins that topped that leaderboard. Again, the global backlog/leaderboard is still the focus and makes up the bulk of the work we do in a single year.

In a nutshell: nothing really has changed except we don't commit to the top N, because we've never successfully been able to do that in a single year. Your participation in the survey is just as important. The survey is not just for us, either; other teams may see a popular wish in their scope and take it on, or it may turn into a Hackathon project, Google Summer of Code, etc. The survey is a means to reflect the wishes of the community to the broader movement, while Community Tech's job is to work exclusively off of the survey results.

To answer your actual question, under the new format, yes, we are asking for reconfirmation of the three wishes you point out as we were unable to get to them in 2019/2020 as we had hoped to. They don't necessarily have to make the top 10 though, for the reasons stated above, but the more votes the better the chances it gets, of course, also bearing in mind that smaller projects have their own backlog so-to-speak (such as the Wiktionary wish). More at the Status report for 2019 wishlist.

Hopefully this satisfies your concerns. We will update the documentation on the landing page accordingly to better clarify this. MusikAnimal (WMF) (talk) 21:30, 9 November 2020 (UTC)

I am not a fan. When I worked with this team for changes around en:WP:NPP, I found you great collaborators and on the whole a pleasure to work with. However, the community has now gone from having one way to actually get some developer time for things it thinks important to zero ways. In order for a community desired change to happen it needs to pass an initial screen to be allowed onto the community wishlist. It needs to attract some level of support (but not necessarily the most support since it's neither a vote nor a discussion). It then needs to be selected, by whatever method the team feels like using, for research. Then the research needs to be positive. Then the development needs to be completed successfully. That is, by my count, 5 different places where, no matter how much the global community desires a change, that the it could simply not happen. The fact that the team is small is not an indictment of you but of the leadership who allocates funds, including the board. But the rest of this are changes I'm dispirited to see and I am not at all reassured by the idea that if I'm really lucky some other benevolent entity will do a wish. Best, Barkeep49 (talk) 22:00, 9 November 2020 (UTC)
This is not a good system.
I would recommend just not running the wishlist this year, and for the team to just continue working on the uncompleted wishes from the past two years. We already have a community-voted wishlist full of things that would probably take longer than the coming year to complete. The cost of having another run of voting (including volunteer time spent, advertising measures, and amplifying general frustration with the team) outweighs whatever slight possible benefits might come of updating the list for any change in preferences. (In practice, I expect the new list to not match previous lists, but more because of issues with expectations of the team than anything to do with the wishes themselves.)
If the team can't handle a whole new list every year, we'll have to manage, but over-promising while falling further behind isn't really helpful. --Yair rand (talk) 22:11, 9 November 2020 (UTC)
I mean this is clearly their plan to not fall behind. If we want past wishes to be done we need to vote for them again so there is no backlog. They no longer promise to do any set number of wishes. They have complete discretion about which wishes to do. Best, Barkeep49 (talk) 22:57, 9 November 2020 (UTC)

@Barkeep49 and Yair rand: Hello! We just met as a team to discuss some of the feedback we received, and we’ve decided to clarify and change some things, in light of the feedback.

First, we added to the documentation that we will evaluate wishes in order of the number of votes they receive. This means that the wishes with the top number of votes will receive our attention and focus first. The votes of the community matter, and top wishes are still top wishes. We’re just not committing to a number in advance.

Second, we understood the frustration people felt about the 3 remaining wishes from the 2019 & 2020 surveys. People wanted us to evaluate and consider the wishes, rather than be asked to vote on them again. For this reason, we have decided to include the remaining 3 wishes in our backlog. This means that we’ll consider them high-priority wishes, along with the top 2021 wishes, and we’ll try our best to evaluate them in the coming year.

Third, about why we’re having the annual survey: We had extensive conversations about whether or not to have the survey this year. This was something we took seriously. While we knew we had limited capacity and resources, we also knew another truth: the wishlist survey is a time, once a year, when people can share what’s important to them and what they want us to work on. If we don’t do it, we miss out on a crucial venue for people to share this information. Sometimes we work on wishes; other times, volunteers or other teams work on wishes. But the wishlist survey is powerful not only because of its direct collaboration with the community, but also because of its regularity. This is what we do—we connect with and learn from volunteers every year—and we wanted to keep on doing that.

Finally, this process is very similar to the old one. The main difference is that we’re not committing to a number of wishes in advance. However, we'll share with everyone how we pick wishes to work on next and why, and we'll collect feedback on these choices. So, with all that being said, thanks for all of your feedback so far; it's helped us rethink some things. We sincerely hope that you give us a shot with this new system and let us demonstrate our values of communication & collaboration. --IFried (WMF) (talk) 01:22, 10 November 2020 (UTC)

Thanks Ilana, this is very encouraging. I appreciate that some of my concerns stemmed from a misunderstanding and in other pieces you decided to quickly reverse course. Both speak well of you and the team. Know that I am definitely supportive of the idea of the team being able to have a system that lets you manage expectations and I appreciate your commitment to facilitating the community process, which as you note is important. Best, Barkeep49 (talk) 01:48, 10 November 2020 (UTC)
Thank you, Barkeep49, for your response and for your flexibility, as we continue to grow as a team. We're happy to hear that our message helped clarify and improve the situation. We look forward to seeing you hopefully participate in this new year's survey and thank you again for sharing your feedback! --IFried (WMF) (talk) 03:32, 10 November 2020 (UTC)

Ranking? Whose choice? Limited key points? And 2 year backlogs?[edit]

I'm really confused by this - the entire thing seems to have so many caveats, that it's going to be impossible to know which ones will get chosen (even if the actual number of items on that list wouldn't be decided until later).

It really needs clarifying.

We also need summary on why those items from 2 years ago remain non-complete - part of the reason last year's massively truncated set was accepted was because it would allow completion of all of the backlog, and now we seem to have multiple items carrying through. That is immensely offputting. Nosebagbear (talk) 14:30, 8 November 2020 (UTC)

@Nosebagbear: An update on the 2019 wishlist can be seen at Community Tech/Status report for 2019 wishlist. We agree it is off-putting that these wishes have gone unaddressed (though investigations were completed). This is why we want to remove the "top N" aspect from the survey, since that never seemed to work for a single year, as we have no idea what that year will bring, or how big each wish will actually turn out to be, etc. My reply to Barkeep49 above may also answer some of your questions. In the end, we're confident this new system will be better for you and for us. There is no sure-fire 100% way of knowing what will get worked on in a year, but as time has proven, this was already the case. The difference now, we hope, is that we don't disappoint anyone by making broken promises. If your wish didn't get addressed, simply re-propose it for the next survey. Rest assured, though, the same familiar concept applies: the more votes a wish receives, the better the chances it has. We are working to clarify this in the documentation and apologize for the confusion. MusikAnimal (WMF) (talk) 21:50, 9 November 2020 (UTC)

Fairly good for readers

Somhat Senday (talk) 15:04, 21 November 2020 (UTC)

Why just for this tiny team?[edit]

I got some technical wishes for the devs here disallowed, because they were "out of scope". The scope is imho the whole dev-team at WMF, I could not care less how they organize, they are all working for us, the community, and should all listen to these wishes. They got paid by us, they should listen to us. It's completely irrelevant, which technical wish will be worked on in which team, that's just minor technicalities in the organisation structure. This should be a plattform for technical wishes by the community, full stop. I don't care, and I don't want to care, which department will work on it, it's completely irrelevant for a technical wish of the community. Grüße vom Sänger ♫(Reden) 15:49, 10 November 2020 (UTC)

I second this opinion. This is a wishlist, specifically what wishes the community has. Who is going to solve the problem is totally irrelevant. --Dirk Beetstra T C (en: U, T) 10:30, 17 November 2020 (UTC)
@Sänger and Beetstra: Thanks for sharing this feedback. We need to sometimes mark wishes as "out of scope" because we want to share the findings of our analyses, and we want to inform volunteers on whether or not we can fulfill wishes that came out of the survey. This way, volunteers can understand what options may be available, if they want a wish to be fulfilled, rather than giving an inaccurate sense of what may get done by our team. However, we acknowledge that other teams or volunteer developers may be able to do such work in the future, so we don't close any related Phabricator tickets. As for other product teams at the Foundation, they typically work on initiatives and priorities set by the organization and movement strategy. Meanwhile, Community Tech is the team that is explicitly set up to do work directly related to community requests. However, other product teams definitely *do* look at the wishlist. While they may not regularly or directly work on wishes from the wishlist, the wishes inform their thinking and understanding of community needs. Thanks again & we hope to see you participating in this year's survey! --IFried (WMF) (talk) 21:56, 18 November 2020 (UTC)
All of the WMF is just a service organisation for the (online) community, all of them have to listen to the wishes ans needs of those people, who generate the wealth of the WMF, the editors and volunteer devs. Two years ago a wish was denied, because it somehow interfered with some department within the WMF devs, that should be impossible. This are wishes for all the devs, and they all have to listen, not only can listen. Or you should make clear in the naming and description, that this is just some wee crumbs for their community to keep calm and don't disturb the devs with their unwanted pet projects like FLOW etc. Grüße vom Sänger ♫(Reden) 05:16, 19 November 2020 (UTC)
Most of the exclusion points in Community_Tech#Scope should be removed, this is the wishlist for all technical wishes towards all devs, all departments have to work with this, they are all just service departments for the community. Grüße vom Sänger ♫(Reden) 05:20, 19 November 2020 (UTC)
@IFried (WMF): that is not a real answer to our concerns. As Sänger is saying, these are wishlists of things that the community wants resolved. One of my proposals is a suggestion that has been dormant in Phab for something like 13 years (10 years since dev Brion stated I'd recommend ripping out the current "giant list of regexes" and use some actual data structures to record the blacklist entries, as we do for the more heavyweight but flexible AbuseFilter). If the community wishes something to be solved, then that needs to be solved. If you think it is out of scope for this small team (as has been suggested for this proposal[1], and for other proposals ([2][3]) in the past), then you should find another way to solve this, because the community wants (nay, for some it is: needs) this. Phab tickets stay dormant for years because no-one works on it, and this wishlist is restricted to a small scope so that real problems stay and we solve small problems or mere gadgets. --Dirk Beetstra T C (en: U, T) 07:49, 19 November 2020 (UTC)
I fully understand that some problems are 'too big', but IMO you should remove all selection rules from the wishlist, but you are free to mark the proposals as, e.g. 'to be solved by global developers', 'to be solved by wishlist team', ... and then in the end rank them, and push for the top 5 of 'big problems' with the existing developers and a top 10 for the wishlist team. But at least you get a fair reflection of the community. --Dirk Beetstra T C (en: U, T) 07:56, 19 November 2020 (UTC)
Yes, that's exactly what I was trying to say. This is the community wishlist, it's the wishlist of the community towards the WMF. It's not the wishlist for some tiny team, it's for the whole Wikiverse. If it really should be just some small wishes for this small team, it should not be named in a way, that only can have one meaning, that it is the technical wishlist of the community. Grüße vom Sänger ♫(Reden) 08:38, 19 November 2020 (UTC)

@IFried (WMF): I think Beetstra and Sänger are not only hitting the nail on the head, they are also echoing some concerns I and others such as Barkeep49, Nosebagbear, and Insertcleverphrasehere have been voicing ever since the concept of the Wish List began. The WMF exists to serve the Community - let this be clear: the Community does not work to provide employment and salaries for the WMF. The Community is nevertheless appreciative of the excellent work by staffers/devs such as, for example, MusikAnimal (WMF), but those who need to be addressed are those who decide on the size of the developer group(s) and their budget. That said, some required developments, like those for New Page Patrol, blacklists and abuse filters, are not for mere comfort and convenience applications, but are crucial to the operation of the project and therefore should not belong in the Wish List at all and should be a major, standing Foundation priority. NPP for example, as the only firewall against unwanted new articles, affects the whole principle of what Wikipedia is all about: making an encyclopedia and maintaining quality, accuracy, neutrality, and above all, appropriateness of its content. Who is going to solve the software problems is indeed totally irrelevant, to infer that funds are limited, as has been claimed in the past, would be a very lame excuse, please just get it done and if necessary, push this further up the hierarchy until someone does. Thanks. Kudpung (talk) 01:39, 21 November 2020 (UTC)

@Sänger, IFried (WMF), Barkeep49, Insertcleverphrasehere, Nosebagbear, and Kudpung: And then you get Community_Wishlist_Survey_2021/Archive/Ability_to_use_gadgets_crosswiki after a suggestion from user:JMVR1, declined as 'out of scope' by User:MusikAnimal (WMF). That should just run, and if it is a favorite it should be assigned to the right team (yes, maybe not this team, but then another). --Dirk Beetstra T C (en: U, T) 08:16, 22 November 2020 (UTC)

We talked about opening the survey up to all proposals, broadening the scope to be for all of WMF, hackathons, Google Summer of Code, etc., but felt this was a big change. We already made a big change this survey by removing the Top N aspect, and we felt that was enough for this go around.
We definitely agree it would be nice to have an accurate reflection of the community's wishes, no matter how big or small, but we have to balance expectations. If many top wishes are well beyond the ability of Community Tech, and if no other teams happen to pick them up, that doesn't look great for the survey process. The fact is we don't have control other teams backlogs or priorities. We invented the survey (well, technically stole the idea from WMDE :), and we are the only team that explicitly works off of it. Advocating otherwise is certainly fine, but I don't think here is the right place as we obviously can't do anything about it. We also agree renaming the survey might be another solution to help clarify the scope, but at any rate, it's far too late to make such changes this year. So for now, we ask you to go along with the status-quo, with the understanding we will incorporate your feedback in planning for next year. Thanks for your understanding and cooperation, MusikAnimal (WMF) (talk) 19:25, 23 November 2020 (UTC)
@MusikAnimal (WMF): I haven’t read through this huge section, so I reflect only to your comment—what about just tagging wishes CommTech can’t implement instead of declining them? This way people can vote on them and thus developers have a feedback on how important it is, but the tag explicitly states that CommTech won’t implement it however high it ranks, so people won’t have wrong expectations. —Tacsipacsi (talk) 22:47, 23 November 2020 (UTC)
Good idea! I think something along those lines is probably how we'll need to approach it in future surveys. We might also offer a separate Tracking page just for the ones we know we can tackle, so it's easy to see which proposals end up on our backlog. MusikAnimal (WMF) (talk) 22:58, 23 November 2020 (UTC)
@MusikAnimal: Why just for the future? It is a completely non-intrusive way of tagging and you get data a year earlier. --Dirk Beetstra T C (en: U, T) 05:28, 24 November 2020 (UTC)
  • @Samwilson: re: Community Wishlist Survey 2021/Archive/Watchlist of users. Yes, it was declined as a top 10 case 5 whole years ago. Things have changed, wikis have moved on. Yes, this could possibly be used to harass an editor, but it also has advantages. It is time that the community has a new word on 'old proposals that were rejected', they may come up with new ideas on how to solve things, they may come up with ways how any harassment can be visualized and avoided. I could possibly agree if this was proposed, discussed and declined 1 year ago, but this blanket declining of 'declined old proposals' is wrong. --Dirk Beetstra T C (en: U, T) 05:27, 25 November 2020 (UTC)
  • @Beetstra: That's true, but this is a particularly well-known example of a feature that on the surface seems really good but which actually can result in all sorts of nastiness. You're right though, perhaps it is time to revisit it: I think to do that, however, it'd be best to have the proposal actually spell out how it'd resolve the issues with harassment that have been highlighted. As it stands, it's leaving the "how" to us and our answer is already known: "we don't know how to do this in a good way". :-) So feel free to elaborate on that proposal page, and move it out of archive, if you have a vision for how it can work. —Sam Wilson 05:59, 25 November 2020 (UTC)
  • @Samwilson: That could be something for the community to discuss (which was not done in the first place). And I don't disagree with the concerns per sé, I do disagree that we are blanket declining and are not willing to discuss about it. If it is something that the community (still) wants (this is a community wishlist) then that is something that we need to assess. --Dirk Beetstra T C (en: U, T) 06:14, 25 November 2020 (UTC)
  • @Samwilson: I got an error message moving it back, I am not allowed to move it since 'The voting phase has begun!'... --Dirk Beetstra T C (en: U, T) 13:06, 25 November 2020 (UTC)
  • @Samwilson: ^^, please. --Dirk Beetstra T C (en: U, T) 12:43, 30 November 2020 (UTC)
  • @Beetstra: Sorry, I didn't realise that archived items are protected against being moved. But anyway, I don't think it's ready for voting: the issue here sees to boil down to there not being any new proposal (i.e. mainly around how to avoid harassment), and so the old reply still applies. There's no point in getting people to vote on it if we already know that it can't be worked on. —Sam Wilson 21:26, 30 November 2020 (UTC)
  • @Samwilson: so you persist in not wanting community input on a community wishlist. You are now pre-vetting a proposal without giving chance to let it mature and get further into community input. And I still think that the harassment is a complete, utter red herring as I explain in my comment. If I want to follow someone around, I write a script, or use my bookmarks and would not be using this WMF-visible tool. Note that there is another solution that is perfectly workable: the AbuseFilter (for those who have access to that). I just have a piece of code in a .txt on my computer, I paste it into the abusefilter and test it against the last handful of days of edits and I get exactly the same as what this proposal wants to do (and of course, I do not save the AbuseFilter). So, really, I do not understand what you guys are trying to avoid, and why you do not want to have community input on how to solve the perceived problems of 4 (!) years ago. No, you don't know that it can't be worked on. --Dirk Beetstra T C (en: U, T) 07:08, 1 December 2020 (UTC)

I see many arguments to explain this, but I think it misses some key aspects, so lets take a step back. The Foundation is ALWAYS open to accept any and all ideas and bugreports. That's why there are 1000s of open tickets in phabricator. The Foundation is so open to the ideas of the community that it is perpetually overwhelmed by them. It turns out that this causes especially the smaller ideas to go unnoticed and fall by the wayside. The whole point of the community whishlist and the community tech team is to uncover some of these valuable and smaller ideas and use a focused team to prioritize that. That is what this effort is about.

Is it enough ? I don't think so, but without hiring a lot more developers it is the only way to even slightly move the needle on some of this. Going beyond that mandate of the team, requires influence by management, or rather even.. the board. I do however think that there is value in collecting all 'non-qualifying' ideas in a seperate category, where they can be reported to the rest of the organisation, without being part of the voting phase of for this specific team. Also because 'kicking' ideas out of a process like this is simply very offputting. It's like getting a CSD tag on your first article. —TheDJ (talkcontribs) 09:54, 25 November 2020 (UTC)

I disagree with the point '... accept any and all ideas and bugreports ... in phabricator'. Every bug goes into phabricator, many requests and suggestions go into phabricator. But phabricator does not have a sufficient ranking mechanism to assess what the community wants. Very annoying bugs are not solved (I reported a bug on the watchlist which stayed there for years with no action, until the bug report suddenly got closed with 'not a bug anymore, probably the solution for thát bug also solved this bug'). Problems are reported, and sometimes even recognised as a problem, but not solved. And for that, a list of things that the community wishes to be implemented, developed, upgraded, repaired (like a Community Wishlist) is a great thing to assess it. Pre-emptively throwing out everything that is too big, already declined etc. is then, indeed, off putting. --Dirk Beetstra T C (en: U, T) 13:01, 25 November 2020 (UTC)
I think somne of this could be solved by looking more for community wishes and maintenance instead of unwanted new bling like FLOW etc. In the end all the devs, that are paid by community generated money should work for those, who have to work with the software, the community. Some shifting to those areas the highest entity in the wikiverse wants work done should be a no-brainer. Grüße vom Sänger ♫(Reden) 13:26, 25 November 2020 (UTC)
I disagree. I do not think the community is the best judge of what should be worked on. Most people in the community, at least the ones usually active in policy and persistent at proposals, are long-time people who are used to this way of doing things. The bar to edit is increasing, participation dwindling, and the community cannot fix these issues. Joining discussions or Wikipedia in general as a new editor is hard, that's why attempts like Flow or VE are necessary. The community may be aware of this, but it is unable to figure out practical solutions for this. enwiki continues to bloat with more and more talk notices that there's never consensus to remove because "this one is also necessary". Your eyes, or mine, are used to glancing over all the crap but new editors' aren't. I'm not saying the foundation necessarily gets prioritisation right, but there's very good reasons why the communities should not be the be-all-end-all wall of how developer hours and budget is spent. A right mixture of addressing editors' issues, and addresisng long-term goals and unconscious issues, is needed. And yes, sometimes that results in failure, but it shouldn't stop attempts at trying to address difficult problems (though, perhaps more community and expert input could've prevented the Flow mess). ProcrastinatingReader (talk) 10:18, 2 December 2020 (UTC)
I absolutely agree, user:ProcrastinatingReader, the community is NOT the best judge of what should be worked on, the community is not the best judge of who (which team) should be working on things. But the community IS the best judge of what the community wants. Voting here is open to anyone, new editors as well as established editors. If new editors want flow, want VE, want MV then they should have that voice as well. What should be voted on are all proposals and see what the community wants.
On the other hand, there are problems which are not fixed. Those problems result in established editors spending a lot of work on mitigating those problems. That is time that they do not spend on keeping new editors here, helping them through startup problems. There are real issues with the interface which cause real problems which affect new editors and old editors alike. If, e.g., the spam and vandal floodgates are open new editors will not come because pages are not worth editing on.
Overall that needs a healthy balance. Currently, that balance is very much on the side of the bling, old problems get ignored, real problems do not get solved. Some of those problems have long ago been confirmed by developers, but they do not get assigned time to solve it. Some things are really wanted by the community but do not get worked on or do not even get discussed. This is the perfect place to bring the idea of Flow back into vision and see what the community thinks about rekindling that effort. And if the community wants it, then a decision can be made about who is going to work on that. --Dirk Beetstra T C (en: U, T) 11:53, 2 December 2020 (UTC)
VE is fine, as long as it's not the only possibility. And as long as it doesn't wreck pages, as it had done with ist first major roll-out. The problems were spelled out by the community before the premature start in the wild, but were ignored by the WMF. With MV the same happened again: The softwaree ignored licenses, was a legal nightmare, but was nevertheless pushed with might over right by some rogue devs with SuperProtect.
FLOW was just LQT-reloaded, with a complete rift between a wiki-page and a wiki-page. It was expecially bad for n00bs, as trying something on the talk page was no longer possible, talk pages were no longer wiki pages.
Ther are on the other hand lots of bugs, even severe ones, that get no attention by the WMF, despite being there for quite a long time, probably because they are not fancy enough to work on. Grüße vom Sänger ♫(Reden) 12:47, 2 December 2020 (UTC)

How do I create a proposal?[edit]

Maybe I am just dumb, but I looked through this page four times, and I was unable to find instructions for creating a proposal. Can someone please explain how an editor actually creates and modifies a proposal for this survey? Thanks. Jonesey95 (talk) 16:01, 16 November 2020 (UTC)

I think it's because it's set to open at 1800 UTC - I couldn't find it either! Nosebagbear (talk) 16:09, 16 November 2020 (UTC)
Correct. The survey is not open yet. Please check back in a few hours. We look forward to seeing your proposals! MusikAnimal (WMF) (talk) 16:36, 16 November 2020 (UTC)
I guess I shouldn't believe everything I read. Today's Tech News said "The Community Wishlist Survey is now open for proposals." Silly me. Jonesey95 (talk) 17:01, 16 November 2020 (UTC)
@Jonesey95 and Nosebagbear: Sorry for the confusion! I'm guessing we didn't take note of what time of day Tech News goes out. Better it was a few hours premature than to wait another week to get the word out, I suppose. Anyway, the survey is open now :) Thanks for participating! MusikAnimal (WMF) (talk) 19:58, 16 November 2020 (UTC)

Proposal TLDR: "Category Transitivity". Ask me what this means, if you want... and if you _dare_! ;-) Abe149 (talk) 03:22, 20 November 2020 (UTC)

Is it worth it to put forward section watchlisting?[edit]

My understanding is that the ability to watchlist sections (task T2738) has been put forward as a top item in the past and rejected. There seems to be a little movement on the phab ticket, though, according to Alsee, and I know Enterprisey has been working on a gadget so it doesn't seem like an impossible task. Is it worth it to put this forward as a request (it's definitely #1 on my wishlist, and I think the same is probably true for others) or would we just be wasting our time? {{u|Sdkb}}talk 03:08, 17 November 2020 (UTC)

Imho every technical wish is useful, as this is the only way for the community to make wishes in an open place. Whether this team can It should be irrelevant which subteam of the devs is working in it, this is the wishlist for technical wishes by the community to te WMF, organised by the community tech team. All tech teams should care about this wishlist. A rejection should be impossible, just because the small group of organisers can't cope. Grüße vom Sänger ♫(Reden) 05:05, 17 November 2020 (UTC)
hi @Sdkb – being able to receive updates to specific sections is something the Editing Team will be working on as part of the Talk pages project. In fact, a few weeks ago, we deployed some new infrastructure to support this functionality (see: T264478). We plan to focus on user-facing components of the implementation at the beginning of the next calendar year. At that point, I'm sure we'll have many questions – would you like me to ping you when those conversations are starting up? PPelberg (WMF) (talk) 02:36, 19 November 2020 (UTC)
@PPelberg (WMF): I'm not sure I'd have much specifically to contribute to those discussions, but a ping never hurts, so feel free to if you're seeking extra community input. It's certainly a feature I'll be looking forward to! {{u|Sdkb}}talk 02:39, 19 November 2020 (UTC)
Understood and sounds great ^ _ ^ PPelberg (WMF) (talk) 02:41, 19 November 2020 (UTC)

Multiple categories for one proposal[edit]

This proposal Community Wishlist Survey 2021/Mobile and apps/Wikidata contribution interface for mobile could be in the Mobile and in the Wikidata category. Should I copy the link in the Wikidata page? PAC2 (talk) 06:27, 17 November 2020 (UTC)

@PAC2: Unfortunately due to technical problems the system assumes proposals belong to exactly one category. You gave a very good example, though! We'd like to support this some time, while also ensuring wishes don't get too much coverage and overshadow other wishes. It's a delicate balance :) After we've reviewed and organized the proposals (December 7), we'll look into to some ways to help visibility of proposals that have very clear crossover like this. For now, let's just stick to one :) Thanks for your participation! MusikAnimal (WMF) (talk) 07:35, 17 November 2020 (UTC)

How can I search all the proposals and discussions at once? For example; for "table"[edit]

I know this can be done via subpages I believe. For example; go to any English Wikipedia village pump. For example;

Then search via "Search all village pumps and archives".

Please set this up for the wishlist. You may have to rename pages, and move stuff around. --Timeshifter (talk) 01:33, 18 November 2020 (UTC)

@Timeshifter: This link should work (replace "table" with your search query). I think it's a fine idea to add a search bar for this to the landing page. We'll look into it! MusikAnimal (WMF) (talk) 02:01, 18 November 2020 (UTC)
Done. MusikAnimal (WMF) (talk) 04:38, 18 November 2020 (UTC)

Make it clearer?[edit]

Hi - it did take me a good several minutes scanning up and down the page to find a submission link or button on this page, before realizing I need to click within the 'submission categories' area to do that - not very intuitive. Can we make this more apparent somehow? (talk) 23:56, 18 November 2020 (UTC)

Yep, UI is hard. I copied the existing "view and create" sentence to another likely location on the page. It might help. Jonesey95 (talk) 03:30, 19 November 2020 (UTC)
Yeah, that could help. Some other areas of the page have links to other sections - this could also be done in this example. Like you might think the proposal section would have a button to submit a proposal, or at least a link like "[[Community Wishlist Survey 2021#Header name|Submitting a proposal]] is just the beginning of the process." (talk) 04:31, 19 November 2020 (UTC)
All good ideas! I've added a message/link in the "What happens during the proposal phase?" section as suggested, as well. The issue here, if it wasn't obvious, is you can't make forms with multiple inputs, so you must first choose a category in order for the page to be created in the right place. This has a benefit however of letting you see if a similar proposal has already been made. Thanks for the suggestions! MusikAnimal (WMF) (talk) 05:03, 19 November 2020 (UTC)
I don’t think it’s a good idea to hide this link in translated versions. I, for example, as a native Hungarian with pretty fluent English, prefer starting from the Hungarian page, but if given a chance, I’ll create proposals in English, since translation takes time and effort, and even the translator might not give back my intents in English as well as myself. Probably a different wording mentioning the possibility of non-English proposals is useful, but there should be something in all languages. —Tacsipacsi (talk) 21:51, 19 November 2020 (UTC)


Please move this suggestion to the "Admins and patrollers" section. Thanks.—Iluvatar (talk) 23:17, 19 November 2020 (UTC)

Yes check.svg Done I agree this is the more fitting category. Best, MusikAnimal (WMF) (talk) 02:07, 20 November 2020 (UTC)

Double negatives[edit]

"The Community Tech team may decline proposals which do not meet the following criteria: " ... "The proposal has not been declined by Community Tech in the past" - so if the proposal has been declined in the past, then it doesn't meet the criteria for declining it now? You may want to avoid having double negatives here! ;-) Thanks. Mike Peel (talk) 21:36, 18 November 2020 (UTC)

Moved here from Talk:Community Wishlist Survey 2021/en * Pppery * it has begun 20:48, 20 November 2020 (UTC)
I tried to copy-edit the text in question, but the page is protected for some reason. Is this a wiki? Anyway, here's what I would have written:

Each proposal should meet all of the following criteria:

  • The proposal is about a technical change, not a policy or social change
  • The proposal is about the problem, not necessarily a specific solution
  • The proposal is a well-defined problem, not a mix and match of unrelated issues
  • The proposal is not already in another team's roadmap
  • The proposal has not been declined by the Community Tech team, or other teams, in the past
  • The proposal is within the team's scope

The Community Tech team may decline proposals that fail to meet all of the above criteria.

Someone with appropriate privileges could copy the above text into Community Wishlist Survey/section-declined/en to make it more clear. Jonesey95 (talk) 21:50, 20 November 2020 (UTC)
@Jonesey95 the /en subpage is used by the translate extension. The source page is Community Wishlist Survey/section-declined which you should be able to edit (though a translationadmin will still have to sync it before it shows up in transclusions). Anyway I agree the wording was a bit odd. I've implemented your suggestion with some minor tweaks. Thanks, MusikAnimal (WMF) (talk) 22:53, 20 November 2020 (UTC)
@MusikAnimal (WMF): By the way, this edit wasn’t necessary. FuzzyBot is pretty slow in the last few weeks, so I usually wait for at least half an hour until deciding it won’t work, but even if it really fails, you can just go to (i.e.{{FULLPAGENAMEE}}&do=mark) and press the big blue button without any pending edit. (This ability to mark for translation without pending edits exists since this summer, by the way.) —Tacsipacsi (talk) 15:01, 23 November 2020 (UTC)

It's not easy to check out new proposals as they come in[edit]

It's not easy to check out new proposals as they come in. The total number keeps going up, but which are the new ones? Wading through the list at Community Wishlist Survey 2021/Tracking to find proposals I've not yet looked at is rather tedious. Is there any chance of making that table sortable by date? MichaelMaggs (talk) 12:01, 21 November 2020 (UTC)

I track this using Special:RecentChangesLinked/Community Wishlist Survey 2021/Tracking. --Matěj Suchánek (talk) 13:38, 21 November 2020 (UTC)
That's useful, thanks. MichaelMaggs (talk) 16:07, 21 November 2020 (UTC)
That's one way to do it! I've been using which goes by Category:Community Wishlist Survey 2021/Proposals, which will include untranslated proposals, for instance, but otherwise the same as what Matěj Suchánek suggested. MusikAnimal (WMF) (talk) 18:19, 21 November 2020 (UTC)

Either accept every technical wish by the community or rename the survey[edit]

This is now called The community tech wishlist, so that's the wishlist by the community towards the WMF/WMDE techies. If this list should be restricted to a small group within this huge pool of service technicians for the community, this should be made clear in the title of this survey. Rename it to Survey of small wishes, that don't affect any other developers but the small group randomly gathered in Community Tech. No technicakl wish must be rejected as out of scope, just because a random set of devs doesn't feel fit for it. Grüße vom Sänger ♫(Reden) 08:39, 22 November 2020 (UTC)

I also doesn't have "all" in the name...
You can propose any wish. Wargo (talk) 13:30, 22 November 2020 (UTC)

Hardware-related ideas within scope?[edit]

I would like to propose a hardware-related idea after reading this task (phab:T268432). Before doing so, I can't help wonder whether this is within the wishlist scope. George Ho (talk) 09:57, 23 November 2020 (UTC)

Hmm, the focus of your proposal should be about the problem, not the solution. I admit I don't really understand what that task is about, but I definitely don't think we need to go through a survey to green light the purchase of a single iOS device for testing. If the performance team needs one, they will get one. MusikAnimal (WMF) (talk) 19:34, 23 November 2020 (UTC)

new category accessibility[edit]

Is it possible and how to add a new category for wishes to allow more groups of users to get a better access and a better userexperience in Wikipedia and Sisterprojects? I would name it accessibility. Regards, Conny (talk) 05:47, 26 November 2020 (UTC).

Added proposal that should be filled in category accessibility here. Regards, Conny (talk) 05:54, 27 November 2020 (UTC).

WikiBlind - needs accessibility for Blind & Low Vision Volunteers[edit]

I'm one of the co-founders of and just found this page of Community Wishlist proposal - noting there's nothing here yet about helping people who are blind participate in any way. I just saw the deadline for proposals is today, but when I tried to submit something, I was told the proposal submissions are already closed. I am deep in prep for the Global Conversations meeting next weekend and would be so grateful to sync up with anyone here working on accessibility and/or inclusivity, especially for bringing in new human resources to help across the movement. Thank you for any reply! I too have problems with accessibility so please email me at if you can. Thank you for all the work you all are doing to make progress on any of this!! DrMel (talk) 23:09, 30 November 2020 (UTC)