Talk:Community Wishlist Survey/Archive 1

Turned into a disambiguation page

I have turned Community Wishlist Survey into a disambiguation page. Adding a new link every year is better than retargeting the redirect every year. GeoffreyT2000 (talk) 18:49, 25 August 2018 (UTC)

Q: Is choosing priorities based on number of votes just biasing English Wikipedia against other projects?

As most contributors are English and by far the largest project is Wikipedia how can an important request from another project or language ever get near the top of the list? --Traveler100 (talk) 19:28, 19 May 2019 (UTC)

New format

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?

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?

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 (talk • contribs) 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)

"...so open to the ideas of the community that it is perpetually overwhelmed by them. ... The whole point of the community wishlist 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. ... Going beyond that mandate of the team, requires influence by management, or rather even.. the board"

I hear you, TheDJ. So how do get our bigger wishes to the people who can allocate resources, rather than those who already have their manpower circumscribed? I don't like the chances that "other teams happen to pick them up" as MusikAnimal (WMF) puts it. And why isn't the W?F already consulting the community more widely on software features than just than this "focused" process?

Right now, the Foundation is running an advertising campaign which says "donate money to the Foundation, show the hardworking Wikipedia editors that you care". But I'm not feeling that the Foundation is showing editors that it cares. Pelagic (talk) 10:28, 16 December 2020 (UTC)

How do I create a proposal?

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)

Adding proposals to Wikidata

It would be helpful to have these proposals, and strategy proposals from the various strategy workflows, in wikidata with a family of related schemas.

Schema elements for the CSW wishlist proposals (what else?):

proposal name, year, rank, project page, category, tickets (list), status (dict of {element, link} since there are often many links?)

–SJ talk  19:33, 17 November 2020 (UTC)

Is it worth it to put forward section watchlisting?

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

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"

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

• w:Wikipedia:Village pump (technical)

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?

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)

Moving

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

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

Double negatives

"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 https://meta.wikimedia.org/w/index.php?title=Special:PageTranslation/Community_Wishlist_Survey/section-declined&do=mark (i.e. https://meta.wikimedia.org/w/index.php?title=Special:PageTranslation/{{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

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 https://w.wiki/nWv 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

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?

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

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

I'm one of the co-founders of wikiBlind.org 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 drmelganus@gmail.com 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)

DrMel Thank you for your message; an email will be sent to you directly, as per your request. --IFried (WMF) (talk) 21:39, 8 December 2020 (UTC)

Wiktionary: New Search tool

I would like get Search tool, which, if asked e. g. line, returns (pages with) line, łíne, líne, líné, líně, linę, -line, line-, Line, LINE, lline, Linné, linée, but does not return lined, lines/lineš or others words with more (or less) letters, than questioned, unless doubled, where are only differences in diacritics and/or capitals. --Kusurija (talk) 14:32, 9 December 2020 (UTC)

Notify all communities

Hello, I see that Wiikimedia communities haven't been notified of the survey. Please do so! --NaBUru38 (talk) 21:18, 10 December 2020 (UTC)

@NaBUru38: There's a banner across the entire site on every project... --Yair rand (talk) 21:44, 10 December 2020 (UTC)

@NaBUru38: all wikis will receive a message this week. This isn't synonymous to "notify all communities", though. For instance, it's difficult to reach out to the communities writing in various Chinese scripts. Some communities don't use wiki or Telegram or Discord or Facebook that much, and in their case, other social media would be effective. Unfortunately, there is no central map of the main communication channels per community. Additionally, some of the main communication channels are private. So depending on what you're really asking for, the answer is "it's gonna happen" or "it's not possible". By the way, it would be really helpful if you suggested what communication channels are used by the groups you belong to. SGrabarczuk (WMF) (talk) 00:35, 11 December 2020 (UTC)

I mean writing a message at pages like Q16503. --NaBUru38 (talk) 21:44, 12 December 2020 (UTC)

Categorizing based on anticipated difficulty

Something that I'd suggest as a possibility to consider for 2022 is categorizing proposals during the voting stage based on what the Community Tech team considers their anticipated difficulty. There are a lot of small tweaks I'm seeing requested that would likely be easy to implement but will probably get abandoned because they won't make the top 10. Having separate categories for big vs. small changes might mean that more small ones could get implemented without having to compete with bigger proposals. {{u|Sdkb}} ^talk 00:21, 11 December 2020 (UTC)

Most supported first

Instead of see the list chronologically (by the time the proposal was created), I suggest see them by the number of support in the latest day ("yesterday" at 23:59:00 UTC).--BoldLuis (talk) 15:28, 11 December 2020 (UTC)

@BoldLuis: See the Community Wishlist Survey 2021/Tracking subpage (which, granted, is not as prominent as it might be). {{u|Sdkb}} ^talk 08:30, 13 December 2020 (UTC)

@Sdkb: Thank you. This show the first task to begin (the most voted)--BoldLuis (talk) 18:25, 22 December 2020 (UTC)

Broken proposals count for Russian translation

On this page: Community Wishlist Survey 2021/ru proposal count is missing. Please fix it. Screenshot: [4]. — Vort (talk) 16:16, 11 December 2020 (UTC)

Fixed. Stryn (talk) 16:37, 11 December 2020 (UTC)

Number of oppose/ratio of support:oppose

On Community Wishlist Survey 2021/Tracking, I wish the list included the number of oppose votes as well as a ratio of support:oppose votes. I think it would help to see which proposals are most contentious. Right now, there is no difference in the list between proposals that are really good but haven't seen attention and proposals that are really bad. // Lollipoplollipoplollipop :: talk 11:06, 13 December 2020 (UTC)

Oppose !votes are ignored for tallying purposes: "The only votes that are counted are Support votes. The final list of wishes will be ranked in order of the most Support votes." See the section What happens during the voting phase? MichaelMaggs (talk) 12:02, 13 December 2020 (UTC)

Voting gadget UX isses

• When the page is open four a couple minutes before voting, I get a nondescript "An error occurred" due to CSRF check. The gadget should use mw.Api.postWithToken to avoid that; and it should probably display the actual error message instead of / alongside this nondescript text.
• With the amount of votes most proposals get, the feature where the new vote is scrolled into view has become rather annoying. Some feedback that voting happened is of course good, but a simple notice popup would be fine.
• Voting on the list pages lands you to the wish subpage. I don't think there's a good reason to do that, it's just a slowdown.
• This is not related to the gadget, but when clicking on the "Back to XXX" button after editing a discussion section, it could maybe anchor you to the relevant section so you don't have to find your place again. (Granted this is not as useful with the page being shuffled periodically.)

--Tgr (talk) 05:03, 14 December 2020 (UTC)

Shuffling also means that when you return to the category page after being sent to the wish subpage, you may not find the place you were… I also don’t like the OOUI-like-but-not-really-OOUI interface (why not create a real OOUI popup instead?), and I really miss the preview feature the reply tool has. Probably a better voting tool next year? —Tacsipacsi (talk) 19:41, 15 December 2020 (UTC)

All great ideas! The gadget is actually just a fork of Meta:AddMe which comes with all the caveats you mention. I'm a little hesitant to make any changes to it while voting is in progress, but we'll look into these improvements for next year, if not rewrite it entirely. Thanks, MusikAnimal (WMF) (talk) 22:15, 15 December 2020 (UTC)

Wishlist. Und wie wäre es mit einer "Wunschliste"?

Darf man nur Vorschläge machen oder abstimmen, wenn man Englisch kann? --Georg Hügler (talk) 17:01, 15 December 2020 (UTC)

@Georg Hügler: Man konnte Vorschläge in beliebiger Sprache machen, und alle nicht englische Vorschläge wurde in Englisch übersetzt. Leider (oder zum Glück) gibt es so viele Vorschläge, dass das umgekehrt unmöglich ist; niemand kann alle Vorschläge in alle Sprachen übersetzen. – Tacsipacsi (talk) 19:53, 15 December 2020 (UTC)

Hallo Georg Hügler,

man kann gelegentlich auch Vorschläge in anderen Sprachen machen oder abstimmen, aber man hat es hier oft einfacher, wenn man Englisch benutzt.

Navigation: zur Überschrift↑ | zu den Lesezeichen in diesem Beitrag: Meta-Wiki↓ / Wunschliste↓ / Anleitung↓ / Zusammenfassung↓ | zum Ende dieses Beitrags↓ | zur Diskussionsseite von Georg Hügler |

Meta-Wiki

• Du bist hier auf dem sogenannten „Meta-Wiki“ oder auf „Meta“ (https://meta.wikimedia.org/). Der Meta-Wiki soll der weltweite Versammlungsplatz zu den sogenannten Projekten der Stiftung „Wikimedia Foundation“ sein; da ist Englisch die erste Sprache. Das bekannteste Projekt, das von der Wikimedia-Stiftung betreut wird, ist die Online-Enzyklopädie Wikipedia.
• Die Wörter „Wikimedia“ und „Wikipedia“ unterscheiden sich nicht sehr stark. Vielleicht wolltest Du Dich eigentlich gar nicht bei der internationalen Wikimedia-Bewegung und auch nicht bei der englischen Wikipedia einloggen, sondern bei der deutschen Wikipedia (https://de.wikipedia.org/wiki/Wikipedia:Hauptseite).
• Unter der Marke „Wikimedia“ werden verschiedene Projekte zusammengeführt, das ist z. B. die freie Online-Enzyklopädie „Wikipedia“ mit den Teilprojekten (sozusagen mit den „Wikipedias“) in Englisch (https://en.wikipedia.org/wiki/Main_Page) oder eben auch der Deutsch sowie in vielen anderen Sprachen. Weitere Projekte sind das kostenlose Wörterbuch Wiktionary, das „Medien-Lager“ Wikimedia Commons (Bilder usw.), die Bibliothek für frei verfügbare Inhalte Wikisource usw. Insgesamt gibt es wohl fünfzehn Projekte.
• Alles was mit der Wikimedia-Stiftung zu tun hat, die Projekte, die beteiligten Leute, die Länderorganisationen usw., bilden die sogenannte Wikimedia-Bewegung.

Wunschliste

• Ich bin auf diese Seite hier gestoßen, weil ich in einem der Wikimedia-Projekte, in der deutschen Wikipedia, unterwegs war; dort wurde mir eingeblendet, dass gerade die „Abstimmungsphase der Umfrage zur Community-Wunschliste 2021“ läuft (bis 21. Dezember). Es geht dabei darum, Wünsche innerhalb der „Communities“ zu erfassen, die sich auf Verbesserungen der zugrunde liegenden Software beziehen, die man MediaWiki nennt.
• Wir sind da jetzt in der Abstimmungsphase angekommen: 8. bis 21. Dezember 2020. Die technischen Wünsche wurden in einer vorausgehenden Phase entgegen genommen. Es wurde betont, dass man sich bemühe, auch andere Sprachen als Englisch zu berücksichtigen. Tatsächlich wurden einige Textpassagen ins Englische übersetzt, um darüber abzustimmen.
• Ursprünglich war Wikimedia wohl mal so gedacht, dass alles was wichtig ist, irgendwann irgendwie von irgendjemandem übersetzt wird.
• Praktisch ist es aber komplizierter: wenn man 20 Sprachen hat (es sind mehr), müsste man jede Wortmeldung in die 19 anderen Sprachen übersetzten. Hinzu kommt, dass es hier um sehr spezielle, technische Wünsche geht. Du findest also oft eine Art „Techie-Sprech“ auf der Basis von English vor.

Anleitung

• Ich dachte, Du kommst aus der deutschen Wikipedia und deshalb habe ich Dir eine Art „Anleitung“ skizziert, wie Du Dich ohne ausgeprägte Englischkenntnisse hier einigermaßen zurechtfinden könntest. Da ich gesehen habe, dass Du weder eine Benutzerseite, noch eine Diskussionsseite für „Georg Hügler“ in der deutschen Wikipedia hast, ist diese „Anleitung“ für Dich möglicherweise hinfällig.
• Ich schreibe sie trotzdem mal hin:
• Du hast vermutlich mit der Webseite angefangen, die man auch „Vorderseite“ nennt: „https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021“. Wenn Du auf den entsprechenden „Deutsch“-Knopf gedrückt hast, bist Du bei dieser Webseite gelandet: „https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021/de“. Wenn Du auf der deutschen „Vorderseite“ warst und auf den Reiter „Diskussion“ geklickt hast, könntest Du erwarten, auf der deutschen „Rückseite“ zu landen (also auf der entsprechenden, deutschen Diskussionsseite). So ist es meist auch, aber in diesem Fall ist die „Rückseite“ keine deutsche Seite, sondern eine Weiterleitung auf die englischsprachige Diskussionsseite.
• Dort hast Du vermutlich Deinen Diskussionsbeitrag angelegt, indem Du auf „Abschnitt hinzufügen“ geklickt und die Betreffzeile ausgefüllt hast (Wishlist. Und wie wäre es mit einer "Wunschliste"?). Weiterhin hast Du Deinen Beitrag geschrieben, mit Deiner Signatur abgeschlossen (--~~~~) und gespeichert („Änderungen veröffentlichen“). Dadurch wurde eine Version der Diskussionsseite angelegt, die Deinen Beitrag als damals neueste Änderung enthielt: „https://meta.wikimedia.org/w/index.php?title=Talk:Community_Wishlist_Survey_2021&oldid=20820097“.
• Ich denke, wenn Du unter Umgehung ausgeprägter Englischkenntnisse mal ein wenig stöbern möchtest, ist es das Einfachste, wenn Du auf mal hierhin gehst: „https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021/de“. Dann klickst Du auf den Punkt Deiner Wahl, z. B. „Bearbeiten“ (39 Vorschläge). Dann kommst Du auf eine englischsprachige Seite, z. B. „https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021/Editing“.
• So eine Seite lässt sich meist halbwegs brauchbar übersetzen.
• Im Browser Google Chrome kann das z. B. so aussehen: „Kontextmenü (Klick rechte Maustaste)“ --> „Auf Deutsch übersetzen“. Dann siehst Du z. B. die deutsche Übersetzung „Markdown-Syntax zum Wiki-Link-Konvertierungs-Gadget“ statt des englischen Vorschlags „Markdown syntax to wiki link conversion gadget“. Eine automatische Übersetzung ist natürlich auch nicht selten Blödsinn. Für die grobe Orientierung mag es reichen.
• Wie dem auch sei, Du könntest bspw. auf den Vorschlag stoßen, der folgendermaßen übersetzt wurde: „Fügen Sie globale LaTeX-Makros für Mathematik in Mathematik-Tags hinzu“ (original: „Add global LaTeX macros for math in math tags“). Wenn für Dich bestimmte mathematische Symbole, wie der absolute Wert und der erwartete Wert, sehr mühsam zu tippen sind und das Bearbeiten umständlicher und fehleranfälliger machen, dann wäre das genau Dein Thema.
• Du würdest in einem solchen Fall zum Unterabschnitt „Voting“ und dort auf [Bearbeiten] gehen können und gegebenenfalls Folgendes in die unterste Zeile schreiben: * {{support}} --~~~~ Es gibt neben {{support}} (Unterstützung des Vorschlags) auch noch die Bausteine {{oppose}} (dagegen), {{strongly oppose}} (sehr dagegen) und {{doubtful}} (Zweifel am Vorschlag). Dass Du einen {{Comment}} (Kommentar) anbringen würdest, nehme ich eher nicht an.
• Du kannst zwischen den beiden schließenden Klammern des Bausteins (also }}) und den vier Tilden für Deine Signatur (also ~~~~) auch jeden beliebigen Text einfügen. Ich glaube, wirklich gezählt wird eine Stimme nur, wenn {{support}} und ~~~~ in einer Zeile stehen, die am besten mit einem Aufzählungszeichen startet (*). Wie die anderen Bausteine gezählt werden, weiß ich nicht. Es wird ja kaum so sein, dass für jedes {{strongly oppose}} zweimal ein {{support}} abgezogen wird.
• Ich vermute, ein Klick auf den Knopf „Unterstützung“ (bzw. Support) macht es einfacher und fügt die Zeile * {{support}}~~~~ unten an; das habe ich aber noch nicht ausprobiert.

Zusammenfassung

Du hättest zwar einen Vorschlag in Deutsch machen können, aber Du hättest dann in Englisch über Deinen eigenen Vorschlag abstimmen müssen. Bei der Beschreibung eines Vorschlags selbst wird auch eine gewisse Erfahrung vorausgesetzt. Wenn Du mal im Abschnitt „Kann ich einen Vorschlag aus vorherigen Umfragen erneut einreichen?“ (https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021/de#resubmit) stöberst, erkennst Du, dass Du Dich gegebenenfalls selbst mit Arbeit beschenkt hättest, wenn es Dir gelungen wäre, einen bisher unerfüllten Wunsch zu wiederholen.

Sei also bloß froh, dass Du die Phase der Wunscherfassung verpasst hast! ;-)

Zum Anfang des Beitrags↑

Es gibt übrigens in den einzelnen Projekten auch Wunschlisten: in der deutschen Wikipedia arbeitet bspw. das Team Technische Wünsche, Wikimedia Deutschland (WMDE), daran, die Wünsche der „Wikipedianerinnen und Wikipedianer“ zu erfassen und umzusetzen; das ist dann in Deutsch.

MfG --Dirk123456 (talk) 17:01, 16 December 2020 (UTC)

Was soll dieser ganze Ankerunsinn eigentlich? Und diese blödsinninge Navigation am Abfang? Der Absatz ist ja nun wahrlich nicht so groß, dass er eine Navileiste bräuchte. Das müllt nur völlig sinnfrei den Quelltext zu.

Georg ist selbstverfreilich ein sehr fleißiger deWP-Autor, wie unschwer zu erkennen ist.

Ich lese seinen Beitrag eher so, wie ich hier auch vieles empfinde, aber dank recht guter Englischkenntnisse nicht so betroffen bin: Das hier ist ein anglozentrischer Laden, der alles, außer Englisch gnadenlos marginalisert, wer nicht Englisch kan, ist hier eher unerwünscht. Ja, es gibt ab und an Lippenbekenntnisse zur Multilingualität, aber solange selbst in den 10 größten Sprachen des Wikiversums noch immer in den entsprechenden Projekten Massennachrichten auf Englisch gespammt werden, kann ich das nicht ernst nehmen.

@Georg Hügler: Du hättest, wenn Du auf die entsprechende Bekanntmachung im Kurier reagiert hättest, auch einen Vorschlag auf Deutsch machen können. Auch in der Abstimmung darfst Du gerne Deutsch benutzen. Nur die Vorschläge werden leider nur dann auf Deutsch vorliegen, wen sie irgendwer unorganisiert übersetzt, oder Du eben ein Onlineübersetzungsprogramm wie Bing oder Google oder so benutzt. Grüße vom Sänger ♫^(Reden) 05:37, 17 December 2020 (UTC)

Hallo @Georg, entschuldige bitte, dass ich da was übersehen habe. Eigentlich weiß ich, dass man Beiträge von Nutzern mit entsprechenden Spezialseiten herausfinden kann; keine Ahnung, was ich da eingegeben habe.

Hallo @Sänger, scheint so, dass ich etwas gemacht habe, was Dir nicht gefällt.

Wozu die Anker? Ich habe festgestellt, dass es manchmal einfacher ist, wenn man auf sein bereits Geschriebenes verweisen möchte, dass man nicht den Text wiederholen muss, sondern verknüpfen kann (neudeutsch „verlinken“). Dazu braucht man jeweils ein Sprungziel in der Nähe. Ich habe in verschiedenen Diskussionen des Öfteren solche Formulierungen gesehen, wie: „dazu habe ich schon mal was geschrieben“ oder: „... siehe im Archiv ...“. Da ich nicht vorhersehen kann, wo meine Texte künftig landen und worauf ich mich künftig beziehen möchte, habe ich mir ein mehr oder weniger einheitliches System ausgedacht, bei dem ich Sprungziele definiere, deren Namen sich auf ein und derselben Webseite möglichst nicht wiederholen. Keine Angst, sowas landet nicht Artikeln der Wikipedia!

Wozu eine „Navigation“ im Beitrag? Ich finde es optisch angenehm, wenn die Normalansicht strukturiert ist. Ein gutes Beispiel ist die „Vorderseite“ (Umfrage zur Community-Wunschliste 2021). Wenn man dann noch Verknüpfungsziele hat, wie das dort der Fall ist, umso besser. „Navigation“ ist ein pompöses Wort – ein besseres ist mir nicht eingefallen. Ich wolle vor allem erreichen, dass man den Anfang und das Ende schnell findet. Ob der Beitrag kurz ist? – mag sein. Scrollen ist eine Möglichkeit, Klicken eine weitere.

Übersichtlichkeit: Quelltext oder Normalansicht? Der Quelltext wird in der Tat etwas unübersichtlicher, wenn man die Normalansicht auf diese Weise (also mit Ankern) gestaltet. Dort, wo es geht, benutze ich bei manchen Arbeitsschritten auch gern den Visual Editor, u. a. deshalb, weil dieser in etwa das Ergebnis von Quelltext anzeigt und nicht den Quelltext selbst.

Georg ist ein sehr fleißiger Autor. Ja, das ist so. Erkennt man das leicht? Eigentlich schon. Ich weiß nicht, was ich da genau durcheinander gebracht habe. Danke für den Tipp, Special:CentralAuth zu nutzen! Bisher habe ich die Spezialseiten verwendet, die in der Wikipedia und auf „Meta“ jeweils oben unter „Beiträge“ erscheinen.

Empfindungen und Sprache Du schreibst: „Ich lese seinen Beitrag eher so, wie ich hier auch vieles empfinde, ...“. Das machen wir alle ein bisschen. Wir lesen etwas, nehmen den tatsächlichen Inhalt und bewerten das Ganze anhand weiterer Eindrücke und Annahmen. Daraus entsteht dann ein Bild.

Ich z. B. habe hier eine Überschrift und darunter eine einzelne Frage gelesen; beides in Deutsch, obwohl der Rest der Seite Englisch war. Daraus – und aus dem deutschen Benutzernamen Georg Hügler – habe ich die Annahme abgeleitet, dass jemand Hilfe gebrauchen könnte und angefangen, einen erklärenden Text zu schreiben. Als ich dann überprüfen wollte, ob Benutzer-Beiträge in der deutschen Wikipedia vorhanden sind, hat das vermeintliche Ergebnis meiner fehlgeschlagenen „Recherche“ (nämlich, dass der Benutzer keine Beiträge hätte) gut in mein bis dahin entstandenes Bild gepasst. Daher habe ich keine weiteren Prüfungen meiner Annahme durchgeführt und meinen Text auf dieser Basis zu Ende geschrieben.

Du hast ebenfalls recht viel in die wenigen Wörter hinein interpretiert; nämlich die Bestätigung Deiner Empfindung, dass die mangelnde Multilingualität an den Pranger gestellt werden sollte. Wenn ich das von dieser Warte aus lese, verstehe ich die zwei Fragen auch etwas anders, eher als Ausdruck der Empörung und weniger als Hilferuf. Es steht zwar nur ein kurzer Text da, der aber —> ein zweites Mal gelesen —> bei mir eine neue Interpretation hervorruft.

Englisch im Zentrum Ich habe zur Dominanz der englischen Sprache ein eher pragmatisches Verhältnis. Da ich nicht das ganz große Sprachgenie bin, hatte ich früher durchaus Bedenken, mein Studium nicht schaffen zu können (die Veröffentlichungen in den dafür relevanten Gebieten, Mikrobiologie, Genetik und Molekularbiologie, sind eben alle in Englisch). Ich habe dann glücklicherweise im ausreichenden Maße Englisch gelernt, vor allem durch direkte Kontakte zu nicht-deutschsprachigen Kolleg*innen (damals einfach Kollegen). Wenn ich mir jetzt vorstelle, dass jede(r) Wissenschaftler*in aus Multilingualitäts-Gründen drei Fremdsprachen lernen würde und es träfen sich zweie — der eine könnte die Sprachen {A; B; C; D} und die andere {E; F; G; H} — dann wäre es schwierig, direkt zu kommunizieren. Käme allerdings noch eine dritte oder ein dritter dazu, die oder der die Sprachen {C; G; I; J} anwenden könnte, dann könnten sich alle drei in zwei Sprachen unterhalten: {C; G}. So etwas wäre Zufall. Daher hatte ich erkannt, dass in einer Gemeinschaft jeder eine definierte Sprache anwenden müsste, damit man sich nicht nur irgendwie, sondern effektiv verständigen kann.

(Gendersyntax: Im vorausgehenden Satz steht „hatte“, weil ich anschließend nur das Wort „jeder“ verwendet habe, dass man heute wohl gendergerecht anpassen müsste – ich weiß aber nicht wie. Da ich mich aber auf eine Zeit beziehe, in der ich Schwierigkeiten mit normalem Englisch hatte – und nicht mit modernem Deutsch – ist das vielleicht OK.)

Die Nutzung einer gemeinsamen Sprache, nennen wir sie A (zufällig wie anglozentrisch), würde dazu führten, dass sich die Lage erheblich vereinfachen würde. Jede Menge von Sprachen zu einer Person der betrachteten Gemeinschaft enthielte das Element A. Man merkt, dass das etwas ungerecht ist, weil innerhalb dieses Schemas Angelsächs*innen nur eine Sprache brauchen, während andere Personen zusätzlich zu ihrer Muttersprache die Sprache A hinzu buchen müssen.

Kann man dieses Dilemma auflösen? Ich glaube nicht daran. Ich denke der Anglozentrismus ist kein böser Wille und auch kein mangelndes Engagement, sondern eine Frage der Möglichkeiten.

Ich bin kein Mathematiker, aber ich kann mich noch an die Schule erinnern. In Kombinatorik fand ich bedruckend, wie die Zahlen für Interaktionen wachsen können, wenn die Zahl der interagierenden Elemente nur geringfügig erhöht wird.

Jetzt kommen Stellen, an denen ich sonst Anker und Verknüpfungen anwenden würde, um den folgenden Text vom sonstigen Fließtext abzusetzen. So benutze ich lediglich Hervorhebungen (unterstrichen). Ich stelle nun eine Betrachtung zu den Möglichkeiten vielsprachiger Übersetzungen an (Vielsprachigkeit und Logistik) und erkläre dann die hier verwendeten Ausdrücke (Spezielle Ausdrücke).

Vielsprachigkeit und Logistik Für das Beispiel mit der Wunschliste gäbe es – denke ich – drei grundsätzliche Übersetzungsstrategien:

• Erste Variante: Es wird gar nichts von anderen übersetzt und erwartet, dass jede(r) ausschließlich in Sprache A – also Englisch – schreibt; das nenne ich mal „vollständig anglozentrische Vorgehensweise“.
• Zweite Variante: Es gibt ein paar (z. B. zehn) Sprachen, die in Sprache A übersetzt werden; das nenne ich mal „halb-anglozentrische Oligolingualität“. Jeder Wunsch liegt dann in seiner Ursprungssprache und in Englisch vor.
• Dritte Variante: Es gibt ein paar Sprachen, die in Sprache A übersetzt werden und von dort in die jeweils anderen Sprachen; das nenne ich mal „vollständige Oligolingualität“. Jeder Wunsch liegt dann in jeder der zehn Sprachen vor.

Wenn 10 Sprachen erlaubt wären und 100 Wünsche aufgeschrieben würden – jeweils 10 Wünsche in jeder Sprache – benötigte man 90 Übersetzungen in Sprache A. Mit diesen 100 Beiträgen in Sprache A wäre bei der zweiten Variante – also so ähnlich, wie es jetzt abläuft – Schluss („halb-anglozentrische Oligolingualität“). Würde man mehr anstreben, wie bei der dritten Variante („vollständige Oligolingualität“), dann würde man alles in alle bis dahin fehlenden Sprachen übersetzen müssen. Die 10 Beiträge aus der Sprache A müssten in die anderen neun Sprachen B bis J übersetzt werden – das macht 90 Übersetzungen (10 * 9 = 90). Die anderen 90 Beiträge, die nicht aus Sprache A kämen (B bis J), müssten in jeweils 8 Sprachen übersetzt werden, da die Übersetzungen nach A schon erfolgt wären – das macht 720 Übersetzungen (90 * 8 = 720).

Bei diesem Zahlenbeispiel wären also beim gegenwärtigen System 90 Übersetzungen nötig („halb-anglozentrische Oligolingualität“) und wenn man alles in allen Sprachen bringen wollte („vollständige Oligolingualität“) – 810 Übersetzungen (90 + 720 = 810 oder 100 * 9 = 810).

Spezielle Ausdrücke Ich sehe Dich schon schreiben: „Was soll dieser Unsinn mit der ‚halb-anglozentrischen Oligolingualität‘?“ Das ist in der Tat nicht die beste Idee, die ich jemals hatte; ich wollte aber irgendwie an Deine Ausdrücke „anglozentrisch“ und „Multilingualität“ anknüpfen. Ich finde die Ausdrücke eigentlich recht plastisch; aber man kann sie in der Enzyklopädie Wikipedia (also im Artikelnamenraum, de:WP:ANR) nicht nachschlagen (was ich gut finde).

Deshalb hier eine Art „persönliches Mini-Lexikon“, wie ich die inoffiziellen Ausdrücke einordne:

• Anglozentrisch: Auf die englische Sprache fokussiert.
• Anglozentrismus: Vorgehensweise, bei der die englische Sprache im Mittelpunkt steht.
• Halb-anglozentrische Oligolingualität: Die „halb-anglozentrische Oligolingualität“ ist eine Form der Oligolingualität↓, bei der Wünsche aus wenigen Sprachen in eine Sprache, nämlich Englisch, übersetzt werden. Da immerhin einige weitere Sprachen (außer der englischen) eine Rolle spielen, wurde die Vorgehensweise hier nicht als „vollständig anglozentrisch“↓, sondern als „halb-anglozentrisch“ bezeichnet.
• Multilingualität: Multilingualität ist ein umgangssprachlicher Begriff, der vor allem innerhalb der Wikimedia-Bewegung genutzt wird. Der Fremdwort-ähnliche Ausdruck enthält lateinische Wortteile (multi = viel und lingua = Sprache) und könnte in etwa mit „Vielsprachigkeit“ übersetzt werden. Der Begriff bezieht sich auf den Gedanken, dass sämtliche Informationen zeitnah in vielen Sprachen verfügbar sein könnten. Die Voraussetzungen dafür wurden bisher nirgends definiert.
• Oligolingualität: Oligolingualität ist ein „Arbeitsbegriff“, ein Ausdruck, der in einer Diskussion zum Thema Multilingualität↑ von einem Benutzer eingeführt wurde, um einen Gedanken zu präsentieren, der diesem Benutzer realistischer erschien als Multilingualität. Die Verwendung des Wortteils „oligo“ (lat. für „wenig“) statt „multi“ (lat. für „viel“) soll dabei kenntlich machen, dass eine Begrenzung der Zahl von verwendeten Sprachen eine Kommunikation effizient machen könnte. Es geht dabei um ein Gedankenspiel zur Präsentation von Wünschen in mehreren Sprachen.
• Vollständige Oligolingualität: Die „vollständige Oligolingualität“ ist eine Form der Oligolingualität↑, bei der jeder Wunsch in einer von wenigen Sprachen vorgebracht werden kann und dann in alle übrigen Sprachen der Auswahl übersetzt wird. Aus logistischen Gründen und zum Vergleich wurde die „halb-anglozentrische Oligolingualität“ als Zwischenschritt zum Erreichen der vollständigen Oligolingualität vorgeschlagen.
• Vollständig anglozentrische Vorgehensweise: Vorgehensweise, bei der auf Übersetzungen durch Dritte verzichtet wird und nur die englische Sprache als Mittel der Kommunikation zum Einsatz kommt.

Lippenbekenntnisse und Wahrnehmung Es gibt eben den Wiederspruch zwischen Wunsch und Realität und – was schwerer wiegt – unterschiedliche Vorstellungen dazu. Es ist manchmal einfacher, jemandem recht zu geben, als ihn oder sie mit der Realität zu konfrontieren („Du hast recht und ich hab meine Ruhe!“). Man kann jemanden meist auch gar nicht mit der Realität konfrontieren, sondern nur mit den eigenen Vorstellungen davon – und die könnten falsch sein. Dadurch hat die oder der Konfrontierte immer eine Hintertür („Ist ja gar nicht wahr!“). Zur Not kann man, wenn ein Streit eskaliert oder wenn man selbst merkt, dass gute Argumente fehlen, noch einen Dritten heranziehen, den sprichwörtlichen Sündenbock („... die da oben!“).

Wenn Interessengruppen kommunizieren, wird das alles noch schwieriger, weil sich dann Echokammern entwickeln. Man freut sich eben mehr über Zuspruch als über Wiederspruch.

Wenn dann doch jemand kommt und sagt: „Hört mal zu, so geht das aber nicht, weil ...“, dann sticht sie oder er in ein Wespennest.

Ich habe bei Seminaren über Kommunikation mal Folgendes gelernt:

• in Gesprächen übertrumpft der Bezugsaspekt (wie stehen die beiden Personen zueinander) den Sachaspekt (worum geht es thematisch); und
• man sollte Kritik immer mit einer positiven Aussage über die Person einleiten, die man kritisiert.

Ich bin unter anderen deshalb in einer Enzyklopädie zugange, weil in einem enzyklopädischen Artikel normaler der Sachaspekt überwiegt.

Aus diesem Dilemma, dass man einerseits die Sachaussage anbringen will und andererseits niemanden auf seinen oder ihren Schlips treten darf, kommt man umso schwieriger heraus, je weniger vorhersehbar ist, mit wem man eigentlich kommuniziert.

Bei großen Organisationen, wie z. B. die Wikimedia Fondation eine ist, besteht die Gefahr, dass man mit Fakten – oder dem, was man dafür halten mag – einen noch größeren Shitstorm auslösen würde, als wenn man Lippenbekenntnisse anmutig vor sich hin plätschern lässt.

Es gibt auch Kompromisse zwischen Sozialkompetenz und sachbezogenem Pragmatismus. Man kann beispielsweise die Multilingualität als Mantra vor sich her tragen, diese auch zum Teil umsetzen (wie es mit der Wunschliste durchaus versucht wurde) und den Rest, den man nicht gut umsetzen kann, einfach abwürgen. Letztes wurde erreicht, indem man die Diskussionsseiten in verschiedenen Sprachen kommentarlos auf eine einzige Diskussionsseite weitergeleitet hat – anglozentrisch eben.

Noch einmal die Anker Ein Grund dafür, warum ich die vielen Anker verwendet habe, war übrigens mein ursprünglicher „Plan“, Georgs und meinen Beitrag satzweise ins Englische zu übersetzen und sämtliche Sätze durch Anker und Verknüpfungen in Beziehung zu bringen, so dass man beide Sprachversionen miteinander vergleichen könnte. Achtung! – nicht wörtlich nehmen:

(Du hättest dann mitteilen können, dass noch mindestens acht Sprachen fehlen würden, damit man das ernst nehmen könnte. Denn es sollten ja immer die größten 10 Sprachen vertreten sein.)

Mit den letzten beiden Sätzen in Klammern soll demonstriert werden, wie man jemandem sprichwörtlich „das Wort im Munde umdrehen“ könnte, indem man den Kontext ein wenig umbiegt – ein sehr gerne genommener Trick, wenn man irgendwie zurück schießen will.

Kritik Ich werde Dir nicht absichtlich das Wort im Munde umdrehen. Der hauptsächliche Grund dafür ist, dass ich das generell ablehne. Der zweite Grund ist, dass ich das nicht brauche, um aus dem von Dir geschriebenen Text Kritik abzuleiten.

Ein Kritikpunkt betrifft die Art und Weise Deines verkleinert geschriebenen Textes. Mal abgesehen davon, dass wir alle Tippfehler machen, könnten einige Fehler vermieden werden, indem man einfach die Wörter nicht benutzt, deren Verwendung bereits einen Fehler an sich darstellt. Lies Dir den Text einfach noch mal durch! Ich bin sicher, dass es Dir gegeben ist, zu erkennen, worauf ich hinaus will.

Als zweiten Kritikpunkt bringe ich Deinen dramatisierenden Stil zur Sprache. Du bist nicht automatisch der Schutzpatron der Entrechteten und Geknechteten der Wikimedia, wenn Du Formulierungen wie „gnadenlos marginalisiert“ und „eher unerwünscht“ verwendest. Dass man ohne entsprechende Sprachkenntnisse ins Hintertreffen gelangt, stört mich auch. Aber Du kannst ja mal überlegen, inwieweit Deine stete Empörung hilfreich ist.

Ein weiterer Kritikpunkt betrifft Deine etwas hohe Erwartungshaltung. Ich verstehe Dich schon, wenn Du Dich auf der einen Seite über anglozentrische Kommunikation ärgerst und auf der anderen Seite auf „sängerzentrischem Quelltext“ bestehst, der Deinen Lesegewohnheiten genehm wäre. Aber selbst wenn ich vorher gewusst hätte, dass Dir irgendwas nicht gefallen könnte, hatte ich ja ursprünglich ein ganz anderes Ziel, als mit Dir ins Gespräch zu kommen.

Abschluss Ich sehe es ja als positiv an, wenn Du zuvorderst den Sachaspekt beleuchtest und danach den sozialen Aspekt erwägst. Ich könnte aber über Deinen Beitrag und was er auslöst etwas Ähnliches schreiben, wie Du in einem etwas anderen Kontext: „Ich lese seinen Beitrag eher so, wie ich hier auch vieles empfinde, ...“. Da Du weißt, wie Du selbst tickst, brauchst Du das nur auf andere übertragen; wir lesen alle so, wie wir es wahrnehmen.

So, damit soll es auch genug sein. Ich wünsche Dir ein frohes Weihnachtsfest und auch einen guten Rutsch ins neue Jahr!

MfG --Dirk123456 (talk) 20:59, 21 December 2020 (UTC)

Feedback on CWS process

A comment I left in one CWS proposal has turned into something of a larger thread (originally at: User talk:SMcCandlish#Wrong balance at Community Wishlist Survey), on ways to improve the survey, as to prioritization, organization, etc. I'll just copy the extant thread from there to here, since it's apt to be more useful here.  — SMcCandlish ☺ ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  04:14, 19 December 2020 (UTC)

---

Under one item of our wishlist you write “Community Wishlist Survey is rather broken, in accepting only what has the most votes this year, which is never, ever going to be stuff template editors need.” That is a valid point that deserves wider attention. How would you suggest this to be fixed? One fix I can see would be to put effort and effect in proportion. A wishlist without any regard for cost will tend to favor the most expensive items, regardless of how many useful items can be had at the same price. ◅ SebastianHelm (talk) 13:45, 16 December 2020 (UTC)

@SebastianHelm: Yes, there's definitely that effect.

• That one's challenging to address, since assumptions about difficulty of implementing something are often – maybe even usually? – wrong (just ask any software engineer, especially one tasked with changing existing features or adding new one to an existing product mostly written by other people). I'm reminded of the voter guide I get in the mail; there's a dedicated legislative analysis office that comes up with estimated costs and complications of implementing various ballot measures. WMF having someone[s] on staff doing this for CWS proposals and Phab requests in general might help, but it might be easy to be wrong and get fired/sacked. >;-)
• The no. 1 thing to me is true prioritization. Mission-critical things, e.g., accessibility solutions, HTML (and other) standards-compliance fixes, security improvements, and other key proposals which meet with support should take precedence over all attempts to add new features or "polish the chrome" on things that already are properly functional. Secondarily, improvements to existing features people definitely use (wishlist, search, editing tools) should generally have higher priority (among accepted proposals) than requests for all-new features.
  • This, to me, is where the process (not just CWS, but WMF's MW development in general) has failed the worst. It's also deeply entwined in why I resigned as a WMF Tech Ambassador to en.WP; the short version of my statement on my user page about this is: WMF is acting like a software company with a customer base and a marketing plan (what it wants customers to go for), instead of behaving as a globally important NGO with a constituency and a mission to serve the actual needs of that constituency. Some of the standards-compliance things have been open tickets for 15+ years, across multiple bug-tracker systems, and some attempts to "fix" them have simply introduced more compliance problems, cutting off our nose to spite our face. There's a competence problem of some kind happening somewhere, even if most of the devs are amazing. But whoever thought it was good idea to have : equate to <dd> and render visually as an indent, and do this in absence of a proper <dl> list structure was foolish. Of course it would get abused for purely visual indentation not d-list construction, especially if no alternative was provided to do indentation properly. But it was an even worse idea (one I just now learned about, in the mobile skin) to replace that abuse of <dd> with abuse of <blockquote>, which is strictly reserved for actual quotations. The <div> generic element exists for a reason, and is super-mega-obviously the one to use here (though on talk pages the HTML 5 element <article> might be a better choice, especially with smart id stuff for thread building; this can probably just be ripped wholesale from any good blog, forum, or other CMS that is open-source.
  • No one who is unwilling to totally absorb the HTML and CSS specs has any business working on HTML and CSS code (including code that generates that code) at a professional level. I don't mean fire/sack anyone, just move them to something they're actually competent at, and put experts on the tasks the non-experts have been screwing up. Seriously, the kind of screwups involved are things that would not have been tolerated at a regular meritocracy-driven open source project; they would have been fixed years ago, and a bad mistake, like moving from abuse of one element to abuse of another instead of use of the proper, one would likely never have happened.
  • A conceptually similar issue (which I raised with a WMF person at w:en:WP:VPTECH, I think, within the last month) is WMF's internal hostility to VPNs, and inability to distinguish them from other kinds of services, nor to recognize the value they provide for security in an increasingly mobile but increasingly vulnerable computing and communications environment. The current practice of just blacklisting almost every block of IP addresses that happen to resolve to machines that provide VPN out-node services (generally blacklisted because of other services they provide) is downright stupid. It betrays a sort of "stuck in 2004" ignorance about how the technology works. Not just the necessity of VPNs these days, but the simple fact that any given IP address is apt to resolve to multiple [virtual] servers, even by multiple entities, and any given "server" is apt to have multiple sometimes unrelated IP addresses, all due to cloud computing, and software/servers-as-a-service models. It's rather like trying to block travel from Massachusetts because you heard about a bank robber who was born in Massachusetts, and also block entry to banks while you're at it, because anyone going into one might be a robber. This is not how to address sockpuppetry and other abuse problems, anymore than just massacring the entire populations of Nigeria and India is how to address the problem of online scams often coming from or passing through Nigeria and India.
• CWS proposals that pertain primarily to WMF projects should get pretty much all priority; stuff that's extraneous to that (e.g. features for bending MW into a blogging platform) should be left to third-party development, other than any necessary hooks for that development And even then only if both WMF and the overall community think spending any time at all on that hook is worthwhile. Just because someone can conceive of a way to torque MW into being something it was not supposed to be doesn't make it a good idea.
• But there also need to be more CWS categories, or subcategories, that independently rank proposals within them. The current ones are mostly too sweeping, and net together many unrelated things (plus they become so long they are difficult to get through).
  • E.g., almost all requests for template/module tools are stuffed under "Editing", which is not at all what most people are thinking about for that category (they're thinking of public-facing content, the form we used for creating it, and the tools that operate on the content in that form like add markup with a button press, etc.).
  • It even needs to split between source-mode editing and VisualEditor. Some of the proposals this year are VE-only, but are not labeled as such, and end up being confusing.
  • More projects need to be represented by sections. I'll just quote this from q:Village pump#Community Wishlist Survey 2021: "We all can see that small projects are discriminated [against] just as any minorities in democratic processes are. As long as sheer numbers count, small communities' requests are not likely to make it to the top. We can't change the rules during the voting, but we certainly will discuss potential improvements to the future editions. ... SGrabarczuk (WMF) (talk) 00:41, 16 December 2020 (UTC)".
• Then there's the issue of the same proposals being made for 5 or 10 years in a row and always being supported but never implemented. Support assessment needs to be cumulative (within reason; some of the proposals mutate a little over time, but the entire WMF community is good at assessing shifting consensus over time, so this is not much of a challenge).
• Not-quite-relatedly, there are often also essentially duplicate proposals (I saw at least three this year, one pair already identified as such by someone, one pair flagged as such by me, though I only did that one way, and one pair unmarked because I was exhausted by the end and couldn't be bothered). As en.Wikipedia's Arbitration Committee, and several other processes, have clerks, someone should be tasked with clerking this stuff and merging proposals that are too similar (just present the options as variants, and if the proposal in general passes, the exact version to implement can be another discussion for another time, if that's not already clear from the CWS comments). I think there actually is some clerking going on already, since I have seen translation and other work get done. Maybe whoever's doing it needs an assistant.
• One other thing: this survey is so daunting it is very difficult to actually get through it all. It might be more practical to stagger it, e.g. put out the Editing section one month and the Search section another month, and so on, so one does not have to spend literally an entire waking day to wade through it all.
• We're getting too little input from too few editors. In part this is because of the issue in the bullet above this, but in part it's due to lack of local-project awareness and engagement. One radical change in approach could be for projects to host their own wishlists, or have RfCs for items to add, and then forward this on to the bigger, cross-project process. There are numerous ways this could be reshaped, and each would present its own strengths and weaknesses.
• Some of it could also be more top down. The devs will have ideas about what really needs to get done, what is nearing completion and pretty easy to do, what is virtually impossible, and some other matters, like what WMF's executive team and/or board are hoping for (which the community often doesn't know anything about in detail until too late) and solicit feedback more directly.
• Frankly, WMF needs to be willing to spend more money on getting stuff done. It has a lot of money, and isn't really spending enough of it on mission-critical things. I come from a "tech nonprofit" background (EFF and CRF), so I know very well what that problem looks like. A common version is over-spending on executive salaries and perqs (also for the board), like luxury furniture and first-class travel, at the expense of sufficient program staff (the average tech, communications, and other program staffer at such organizations is in dire need of at least one assistant, often a department, and the organization will not realize this until that over-worked and under-paid person burns out and leaves, and the org finds that person has to be replaced with 2 or 4 or 8 to get the same work done).

I could probably come up with more ideas and observations (see, e.g., w:en:User:SMcCandlish/Discretionary sanctions 2013–2018 review for an example of the kind of policy analysis I can do when I devote enough time to it, and even that's two years out of date and would cover several more more things than it does if I revised it significantly).
 — SMcCandlish ☺ ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  02:21, 17 December 2020 (UTC); revised: 04:22, 19 December 2020 (UTC)
 

Wow, I had no idea there was so much behind it – and you're hiding it in the comment to one wish! How best to tackle all of this? Does it even make sense to try and find a solution for one problem that only addresses a small shard of the whole?

Good point about the clerical tasks. I would see those as part of project management; why aren't WMF's PMs doing that?

You're right that the sheer amount of wishes is daunting. It may be a good idea to stagger it, but ultimately the workload stays the same. Not sure how to actually reduce the workload. Maybe similar to what we wrote in the wish for preferences: Mark everything for which a wish exists with a “🎁” symbol – in the UI and the manual – which links to the wish under discussion. So users will see wishes at the right moment and the right place, and only for those functionalities that they use or are interested enough to RTFM. I think this may also address the issue of getting input from too few editors. ◅ SebastianHelm (talk) 22:58, 17 December 2020 (UTC)

Hey SMcCandlish. Thanks for the detailed and interesting post. Couple of thoughts.

• [WMF devs should prioritize] Mission-critical things, e.g., accessibility solutions, HTML (and other) standards-compliance fixes Are these really mission critical fixes? Accessibility is used by a very small minority of users. HTML and other standards compliance is "under the hood" stuff. Using <dl><dd> instead of <ul><li> or <div> will be invisible to most users. In general, refactoring is good, but I wouldn't say it's mission critical.
• I'd say bug fixes are more important than anything listed. Overall, I think WMF does a good job with bug fixes on MediaWiki, although I can think of a couple of bugs in the visual editor. But yeah, if you don't keep up on bug fixes, software quality really suffers, so it's important to prioritize it.
• Seriously, the kind of screwups involved are things that would not have been tolerated at a regular meritocracy-driven open source project; they would have been fixed years ago, and a bad mistake, like moving from abuse of one element to abuse of another instead of use of the proper, one would likely never have happened. This has not been my experience with programming. My experience has been that programming shops often do not prioritize en:code refactoring, because the results are usually invisible to the user. In programming shops, there is often a culture of time pressure, and of delivering tangible results. If you've got a backlog of 100 tickets, you're not going to want to take days or weeks to do a bunch of refactoring that doesn't reduce the backlog. In general, devs would prefer to have sprints now and then to do refactoring, as it makes code easier for them to write in the long run, but often the needs of the business to deliver tangible results end up overriding this.
• Good observation about non profits (and companies in general) in your last bullet there. I don't know if it applies to WMF, but I think that the overall idea of it is correct.

–Novem Linguae (talk) 09:21, 5 January 2021 (UTC)

How many items from the community wishlist typically get implemented per year?

Just wondering. The current wishlist that just closed identified 268 proposals. About 10 of them got over 100 votes. How many of the top 10 are likely to get completed? How many of the entire list are likely to get completed? Any amount is fine by me, just curious. Thank you everybody for all your hard work. –Novem Linguae (talk) 09:23, 5 January 2021 (UTC)

I found Community Tech/Status report for 2019 wishlist today. That's a good summary. Looks like they work on the top 13 or so proposals, and about 7 get done per year. Not bad at all. –Novem Linguae (talk) 17:47, 5 January 2021 (UTC)

Newsletter

From Community Wishlist Survey/FAQ: "You can subscribe to the Community Tech Newsletter to get periodic notifications on the progress of these wishes." I can see that the last newsletter was sent 2 years ago so I wouldn't call it as "periodic". Is it going to be used anymore or should you remove it from the page? Stryn (talk) 08:31, 7 March 2021 (UTC)

Any update?

Is anything happened with 2021 requests? It's already March and I can't find any updates. Stryn (talk) 14:37, 7 March 2021 (UTC)

No project pages yet?

Where are the updates? Where are the project pages? I would like to see how much work has been done in summary. Must I search a random Phabricator task to find out? George Ho (talk) 23:38, 7 March 2021 (UTC)

I am also wondering. The survey was closed almost 4 months ago, and there is still no update at all. --Ita140188 (talk) 04:03, 12 April 2021 (UTC)

I was wondering the same already a month ago but didn't get any replies. Not looking good... Stryn (talk) 07:14, 12 April 2021 (UTC)

@George Ho, Ita140188, and Stryn: Thanks for your comments, and apologies for not responding sooner! The team recently finished the Ebook Export Improvements project at the end of March, and we're now working on the OCR Improvements project. Before that, we were focused on the Watchlist Expiry project (which we began wrapping up during the 2021 survey period). In total, we definitely haven't forgotten about the 2021 survey. We just had some prior commitments that we needed to work on as well, and we didn't want to just drop them right when the new survey finished. However, the good news is that we're currently planning our first project from the 2021 Community Wishlist Survey (the disambiguation link wish, which was the #2 wish). We have chosen this project because it is was very popular (in terms of votes), high impact, and within reasonable scope. We have already begun discussing the wish as a team, and formal research will begin soon. When the project page is up, we'll be sure to update the 2021 wishlist page as well. Thanks for bringing this up, and we hope to see you all sharing feedback when the project page is up! --IFried (WMF) (talk) 16:21, 14 April 2021 (UTC)

Three months later, still don't see new project pages. Getting close to a new wishlist, which may then replace the whole backlog, right? George Ho (talk) 01:47, 14 July 2021 (UTC)

@George Ho @Ita140188 @Stryn Hello everyone, we just posted our first Status Update for the 2021 Wishlist. Thanks for your patience! We'd love to hear your thoughts and feedback. In summary, we're currently working on 3 wishes from the 2021 wishlist-- Disambiguation, Bibliographic Bot for WikiData, and Copy and Paste Diff. Find the link to the full update here. NRodriguez (WMF) (talk) 15:36, 15 July 2021 (UTC)

@NRodriguez (WMF): So much for supporting the community. A completely non transparent method to prioritize wishes (who came up with it? Was it voted on?), when we already voted on the proposals. I thought that was the way to prioritize them. Also it would be helpful to actually put a link to this report on the relevant pages that people are likely to check rather than on this discussion. --Ita140188 (talk) 02:25, 16 July 2021 (UTC)

@Ita140188 Hello, thanks for pointing out that word about this could and should be surfaced in more places. When I authored the post my plan was to post in the following places:

- A new section at the top of the 2021 wishlist page (apologies, did not get to that yesterday due to OCR work. However, it is updated today!)

- A ping in this discussion page (here)

- A post for each of the wishes we are working on and pinging people who voted on them (Working on this)

- Adding a link to it in our Community Tech Links section

Are there other places, like signal groups, or email lists you think it would be helpful to post an update to? I considered Tech News but it seems a bit too early given that we are just announcing what work we are taking on but not releasing changes yet.

Open to hearing more feedback! As per your comment on transparency, I have to be honest that I was worried that more transparency would feel like less. In the past we've done wishes out of order and not explained why. This was an effort to bring more visibility into it rather than just announce that we would work on a wish in the top 5 and no other details. We are still working on disambiguation (a wish inside the top 5) and also going to work on popular but low complexity wishes we can tackle in the meantime. The other wishes, like the number 1 wish on Translation, will also require some thorough research and design before we can begin tackling them-- which is why it makes sense to tackle technical wishes while we do that design work. Let me know if this is still feeling like a black box, and thanks again for caring deeply about the Wishlist and how to make it better. NRodriguez (WMF) (talk) 16:29, 16 July 2021 (UTC)

Quote: worried that more transparency would feel like less. Seriously? When and how will it feel like... "more" instead of... "less"? Also, seeing that the group would like to work on just three out of hundreds of proposals, I wonder whether community will feel more inclined to re-propose the same proposals every year. George Ho (talk) 18:24, 17 July 2021 (UTC)

@NRodriguez (WMF): up above Ilana promised that the team "will evaluate wishes in order of the number of votes they receive". Will the research be done in phab tasks like in the past? If so can you point me to the research the team did for the #1 wish? Best, Barkeep49 (talk) 02:01, 22 July 2021 (UTC)

Since this most recent survey happened, the Community Tech team has undergone significant changes. In addition some engineers have been or will be on leave for an extended period of time. Let me make that clear first; This is the primary reason progress has been so slow, in addition to the global pandemic, social/political climate, and similar hurdles that most all of us have endured over the past ~16 months. Illana's word that we'll evaluate wishes by number of votes still holds true. We devised a new prioritization process, which you can think of as a preliminary investigation. We do this on the top ~30 wishes or so, starting from the top. The system is meant to help the product team gauge what we can afford to do given our bandwidth. For example, let's say the #1 most-voted wish is highly reliant on another team. This would increase the technical complexity score, since it has external dependencies. Say that team isn't available for at least a quarter. We obviously aren't going to sit around and do nothing, rather we'll move on the next wish. Let's say wish #2 is humongous and will take up to a year to complete. But, wishes #3 and #4 can be done very quickly and have a greater impact. We'd naturally opt to tackle #3 and #4 first, unless we are confident we can take on a year-long project (something we try to avoid anyway). So you see, it's not just about number of votes. Votes represent popularity, which is a critical factor, but there are many other elements to software development that need to be evaluated for our team to be efficient and as impactful as possible.

As NRodriguez said, in the past, we simply picked any wish we wanted in the top N without giving any explanation. This system worked but only because we ultimately would address all of the other top wishes. However with that we found ourselves continually backlogged, still working wishes from years ago, some of which were outdated and no longer relevant. Other times we found a wish to be too complex to complete in a reasonable time frame. This hindered community trust and forced us to break promises. This is why we got rid of the "top N" concept. Instead the idea is to regularly conduct a new survey (which is of benefit to other teams and the greater technical community, too) and always work off of the most recent survey. Since we don't have a top N anymore, we need some way to figure out what we should work on next given all the elements involved in software development, hence the prioritization scoring system. This much more fairly represents the reality of how product teams work, and in the end we believe will result in us being more high-output.

We as a team by definition are committed to serving you, the community. Forever and always. A team is only as good as it can serve. It can only serve as good as it can plan. This past year hasn't been great, we admit. With a new administration came a much needed overhaul of our processes. I know these wishlist changes may seem peculiar or even counter-intuitive, but I hope you'll give us the benefit of the doubt that it is an attempt to both be more transparent about how we internally prioritize our work, and improve our productivity. We can't please everyone, and never will, but we can do our best to please as many as possible. In the end our goals are still the same – to make your wishes come true :)

I hope this offers clarity into our decisions, and we thank for your understanding! Please keep the feedback coming. MusikAnimal (WMF) (talk) 19:48, 23 July 2021 (UTC)

Status report

Thanks for sharing the report finally, the Google Docs file is very confusing, not easy to understand, like what is the real order of wishes you will work on? I would like to see this on-wiki and in more clear format. Stryn (talk) 08:27, 16 July 2021 (UTC)

Hey @Stryn we hear that! We are working on clearing up the spreadsheet and bringing it into on-Wiki too because of your feedback-- solid point. In the short term, you can find a less "cluttered" sheet in google version which we just cleaned up for you and others, but you can expect the table inside the on-wiki soon. This is really helpful feedback. It makes me realize that even when we remove all the noise, it's still a tad confusing to see that we are "staggering" our wishes. So we are doing a combination of priority score + strategy-- so the designer and product manager research and conduct user interviews and tests for wishes with a high Product and Design score but low Technical complexity. Meanwhile, engineers work on low product and design complexity so that engineers are not blocked by needing the designs finalized. A bit hard to explain but I can make a diagram to show what we mean by "staggering" the product and design work with the technical work. Think about it like a kitchen-- there are three tables waiting for their food at a restaurant. The first table orders a steamed lobster. The next two of them order soup. Rather than waiting for the chef to make the lobster to serve the second and third table, we are giving them the soup while the order for the first table is steaming. "Staggering" what we serve. Thanks for letting me workshop explanations here! NRodriguez (WMF) (talk) 17:27, 16 July 2021 (UTC)