Talk:Community Wishlist Survey 2021

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

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

New format[edit]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

It really needs clarifying.

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

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

Fairly good for readers

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

Why just for this tiny team?[edit]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Multiple categories for one proposal[edit]

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

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

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

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

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

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

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

Make it clearer?[edit]

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

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


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

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

Double negatives[edit]

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

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

Each proposal should meet all of the following criteria:

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

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

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

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

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

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

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

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

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

Hardware-related ideas within scope?[edit]

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

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

new category accessibility[edit]

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

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

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

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

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[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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[edit]

  • 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"?[edit]

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 |
  • Du bist hier auf dem sogenannten „Meta-Wiki“ oder auf „Meta“ ( 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 (
  • 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 ( 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.
  • 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.
  • 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: „“. Wenn Du auf den entsprechenden „Deutsch“-Knopf gedrückt hast, bist Du bei dieser Webseite gelandet: „“. 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: „“.
  • 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: „“. Dann klickst Du auf den Punkt Deiner Wahl, z. B. „Bearbeiten“ (39 Vorschläge). Dann kommst Du auf eine englischsprachige Seite, z. B. „“.
  • 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.
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?“ ( 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)