Meta:Babel/Archives/2020-11
Please do not post any new comments on this page. This is a discussion archive first created in November 2020, although the comments contained were likely posted before and after this date. See current discussion or the archives index. |
A problem with Template:Oppose
为什么{{Oppose}}只能用英语显示“Oppose”?它出了什么问题吗?{{Strong Support}}也一样。
Why can {{Oppose}} only display "oppose" in English? Is there something amiss with it? And the same problem is also appear on the {{Strong Support}}.--Yining Chen (Talk) 01:04, 7 November 2020 (UTC)
- This is a default English language wiki; and generally for such a template and counting in that language you would keep the responses aligned in their display and message. Having oppose and support in a myriad of languages is just going to be confusing. — billinghurst sDrewth 06:49, 7 November 2020 (UTC)
- @Billinghurst:Sorry but I think you might get it wrong.You can check the source code of these templates ({{support}}, {{Doubtful}} and so on) . They can change the messages that they display according to the language the user is using. If the default language is Chinese,{{support}} will display "support" in Chinese but {{oppose}} will not. --Yining Chen (Talk) 12:27, 7 November 2020 (UTC)
- @Yining Chen: My answer is accurate to the question you asked. Sounds like the question you are were meaning to ask is why isn't Template:Oppose set up as a translated multilingual template as has been done with others (your list). Answer: is simply because they haven't been set up that way. These aren't necessarily problems, they are just differently configured. Ping DannyS712 on their talk page and see of they will consider updating the templates to a translated form. — billinghurst sDrewth 12:36, 7 November 2020 (UTC)
- @Billinghurst: Thank you for your advice! I will ask User:DannyS712 for help.(By the way, I checked the source code of {{Oppose}} and found that it contained code to implement the function, but it seems that the code doesn't work well.) --Yining Chen (Talk) 12:54, 7 November 2020 (UTC)
- @Yining Chen: My answer is accurate to the question you asked. Sounds like the question you are were meaning to ask is why isn't Template:Oppose set up as a translated multilingual template as has been done with others (your list). Answer: is simply because they haven't been set up that way. These aren't necessarily problems, they are just differently configured. Ping DannyS712 on their talk page and see of they will consider updating the templates to a translated form. — billinghurst sDrewth 12:36, 7 November 2020 (UTC)
- @Billinghurst:Sorry but I think you might get it wrong.You can check the source code of these templates ({{support}}, {{Doubtful}} and so on) . They can change the messages that they display according to the language the user is using. If the default language is Chinese,{{support}} will display "support" in Chinese but {{oppose}} will not. --Yining Chen (Talk) 12:27, 7 November 2020 (UTC)
- This section was archived on a request by: Camouflaged Mirage (talk) 10:28, 12 November 2020 (UTC)
Wiki of functions naming contest - Round 2
Hello. Reminder: Please help to choose the name for the new Wikimedia wiki project - the library of functions. The finalist vote starts today. The finalists for the name are: Wikicode, Wikicodex, Wikifunctions, Wikifusion, Wikilambda, Wikimedia Functions. If you would like to participate, then please learn more and vote now at Meta-wiki. Thank you! --Quiddity (WMF)
22:10, 5 November 2020 (UTC)
Gadget for steward/renamers
Hello everyone, From an internal discussion between Global renamers and Stewards there has been almost unanimous support that request should be handled by someone familiar with project or language unless it's a simple request (doesn't include blocks and sanctions).
To mark the origin of request in Queue we have been using User:Ladsgroup/GlobalRenamQueueHelper.js user script, but the issue is that every new renamer have to install it or some might even do not know about it. So I propose it to be added as a gadget for steward section and enable it by default for Stewards and Global renamers. Thanks! ‐‐1997kB (talk) 07:19, 9 November 2020 (UTC)
- @Ladsgroup: do you agree to have your script moved to the mediawiki namespace? You won't be able to edit it there (as I'm sure you're aware) so I want to confirm. If you agree, I can move forward with converting it to a gadget tomorrow - as far as I can tell the only dependency is
mediawiki.api
(though that isn't explicitly loaded in the current code, it should be included as a dependency for the gadget to make sure it is always available). Thanks, --DannyS712 (talk) 07:58, 9 November 2020 (UTC)- @DannyS712 I'm fine with moving the code to mediawiki namespace. Amir (talk) 06:44, 10 November 2020 (UTC)
- Thank you @Ladsgroup:! This gadget is very useful. I have a question for you though. Would it be possible to allow sorting by the column "local wiki"? If not it is still okay, ctrl+f still works fine. Cheers! Nadzik (talk) 08:19, 10 November 2020 (UTC)
- @Nadzik Hey, Unfortunately that's not possible. It'll be possible once phab:T217099 will resolve. Amir (talk) 17:03, 10 November 2020 (UTC)
- According to phab:T217099#6387917 that'd require a schema change and a code change later. Is that doable? While the script is indeed very useful, it'd be better IMHO if the extension gave that info to us directly. Thanks. —MarcoAurelio (talk) 17:07, 11 November 2020 (UTC)
- @Nadzik Hey, Unfortunately that's not possible. It'll be possible once phab:T217099 will resolve. Amir (talk) 17:03, 10 November 2020 (UTC)
- Looks good to me! Martin Urbanec (talk) 13:45, 10 November 2020 (UTC)
- Great idea! It's a very useful script and all renamers/stewards should have it enabled by default! --Superpes15 (talk) 15:05, 10 November 2020 (UTC)
- @Ladsgroup I tested the script out on the beta cluster - for "missing" users (i.e. after they have been renamed, if you're looking in Special:GlobalRenameQueue/closed) it shows "undefined" - is this intentional? If it is, I'll move the script as-is to a gadget, but if not I thought you should have a chance to fix it before you can no longer edit the script DannyS712 (talk) 22:34, 10 November 2020 (UTC)
- Script updated, though it still won't fill the local wiki field if the requester cannot be identified via API anymore. I think this is the best we can do for now.--Sakretsu (炸裂) 12:11, 11 November 2020 (UTC)
- @DannyS712 Done by Sakretsu. I don't think the script will be set in stone, worst case, I request a change on its talk page. Amir (talk) 12:24, 11 November 2020 (UTC)
- Doing... switching to a gadget now --DannyS712 (talk) 20:53, 12 November 2020 (UTC)
- @1997kB, Ladsgroup, and Martin Urbanec: Done, now available as a gadget enabled by default DannyS712 (talk) 20:59, 12 November 2020 (UTC)
Close request
Note this request is a cross-post from RFH; additional discussion is available here.
Would an uninvolved contributor please consider closing the 3 discussions at Communications/Wikimedia brands/2030 movement brand project/Community feedback and straw poll, thanks for your time.
Some glitch on translations
I have done some translations for page Wikimedia Foundation/fi but it seems that my translations are not in its page history, these exists only in namespace Translation. Jnovikov (talk) 19:20, 15 November 2020 (UTC)
Whoa, now these are there! Jnovikov (talk) 19:22, 15 November 2020 (UTC)
Community Wishlist Survey 2021
The 2021 Community Wishlist Survey is now open! This survey is the process where communities decide what the Community Tech team should work on over the next year. We encourage everyone to submit proposals until the deadline on 30 November, or comment on other proposals to help make them better. The communities will vote on the proposals between 8 December and 21 December.
The Community Tech team is focused on tools for experienced Wikimedia editors. You can write proposals in any language, and we will translate them for you. Thank you, and we look forward to seeing your proposals!
Global bot policy proposal: invitation to a Meta discussion
Hello!
I apologize for sending a message in English. Please help translate to your language. According to the list, your wiki project currently is opted in to the global bot policy. Under this policy, bots that fix double redirects or maintain interwiki links are allowed to operate under a global bot flag that is assigned directly by the stewards.
As the Wikimedia projects developed, the need for the current global bot policy decreased, and in the past years, no bots were appointed via that policy. That is mainly given Wikidata were estabilished in 2013, and it is no longer necessary to have dozens of bots that maintain interwiki links.
A proposal was made at Meta-Wiki, which proposes that the stewards will be authorized to determine whether an uncontroversial task may be assigned a global bot flag. The stewards already assign permissions that are more impactful on many wikis, namely, global sysops and global renamers, and I do not think that trust should be an issue. The stewards will assign the permission only to time-proven bots that are already approved at a number of projects, like ListeriaBot.
By this message, I would like to invite you to comment in the global RFC, to voice your opinion about this matter.
Thank you for your time.
Best regards,
Martin Urbanec (talk) 11:49, 24 November 2020 (UTC)
Test Wikimedia Commons
What is the interwiki prefix for Test Wikimedia Commons? Can't seem to find one at Special:Interwiki. testcommonswiki: doesn't work, nor does testcommons:. --AJ1m3,zsd. (talk) 21:18, 30 November 2020 (UTC)
- @AJ1m3,zsd. There's none (intentionally), as the site is/was a single-purpose one, and probably will be destroyed one day. Martin Urbanec (talk) 23:01, 30 November 2020 (UTC)
- This section was archived on a request by: —MarcoAurelio (talk) 21:51, 23 December 2020 (UTC)
Include autopatrol rights with Int-Admin
Hello, there can be some cases where non-admin granted such rights. There is no reason to not trust them with autopatrol, and I think there can be a bundling of autopatrol with interface-admin. Camouflaged Mirage (talk) 18:02, 11 November 2020 (UTC)
- I was literally about to create this thread. Support adding autopatrol to the interface-administrator group. —MarcoAurelio (talk) 18:06, 11 November 2020 (UTC)
- Support --Novak Watchmen (talk) 18:12, 11 November 2020 (UTC)
- Support —Atcovi (Talk - Contribs) 18:18, 11 November 2020 (UTC)
- Support. Sgd. —Hasley 19:23, 11 November 2020 (UTC)
- Support --Krd 19:37, 11 November 2020 (UTC)
- Weak oppose for principle reasons. As stated at Limits to configuration changes, it is the policy to not grant any other permissions to the interface admin group. The purpose of that policy is to make wikis not to grant the permission unless the user really needs to edit JS/CSS, thus restricting the number of holders to the absolute minimum (as it's one of the most sensitive permissions we can grant). I agree that autopatrol probably won't trigger such response, but my principles-liking myself doesn't like adding any permissions to that group anyway. There is really no reason to not duplicate the groups through; at least it makes revoking easier :)) --Martin Urbanec (talk) 20:16, 11 November 2020 (UTC)
- Just to be clear, this is a meta-wiki only proposal. CN admins have autopatrol I don't see why IAs can't. It's not as if we grant IA for the user to be autopatrol. @Martin Urbanec: CM-Public (talk) 20:38, 11 November 2020 (UTC)
- However, if sysdevs are against this idea per Limits to configuration changes, then I guess there's nothing we can do here, I will gladly withdraw this proposal. Advice will be much appreciated? Camouflaged Mirage (talk) 10:42, 12 November 2020 (UTC)
- Just to be clear, this is a meta-wiki only proposal. CN admins have autopatrol I don't see why IAs can't. It's not as if we grant IA for the user to be autopatrol. @Martin Urbanec: CM-Public (talk) 20:38, 11 November 2020 (UTC)
- Uh. Do we really need to discuss a configuration change for such a rare occurrence? Can't we just decide that interface admins can be added to the autopatrol group on sight? Let's not make things more complicated that they need to be. Nemo 20:27, 11 November 2020 (UTC)
- Oppose. 1) We should turn off the useless autopatrolling altogether. The feature and the associated group is superfluous. – 2) Per Martin Urbanec. – 3) Per Nemo, where's the big problem of giving interface-admins the autopatrol group as well. --MF-W 20:51, 11 November 2020 (UTC)
- Re nemo point: My thinking is along the lines we grant global renamers, TAs autopatrol, read a discussion somewhere about adding. Just can't find it now. CM-Public (talk) 21:10, 11 November 2020 (UTC)
- Response to comment about AP itself. I find the patrol indicator useful for my viewing of edits here. — billinghurst sDrewth 02:55, 12 November 2020 (UTC)
- Re nemo point: My thinking is along the lines we grant global renamers, TAs autopatrol, read a discussion somewhere about adding. Just can't find it now. CM-Public (talk) 21:10, 11 November 2020 (UTC)
- Comment They are independent and should continue to be independent, when one stops being admin do you then you think that they should be back to being patrolled. I would hope that if someone is being given the described rights that whomever just assigns autopatrolled at the same time. If you are pushing for a binary decision, Oppose though based on a true need and a sanity of action. — billinghurst sDrewth 02:50, 12 November 2020 (UTC)
- Oppose use the right tool for the right job, there is absolutely no problem with someone being in multiple user groups, and needing a project-local customization for intadmin for this is a bit silly. — xaosflux Talk 16:27, 12 November 2020 (UTC)
- Oppose per Martin, Xaosflux, billinghurst - they are orthogonal groups and I don't see a clear benefit to bundling autopatrol into intadmin. If we want to explicitly say that intadmins are presumed eligible for autopatrol, I won't object, but imo that's rules creep - if someone is trusted enough to be an intadmin I would certainly expect them to meet the criteria for autopatrol. GeneralNotability (talk) 17:08, 12 November 2020 (UTC)
- Weak oppose I find Martin Urbanec's reasoning to be persuasive. 𝒬𝔔 22:23, 17 November 2020 (UTC)
- Strong oppose Nieuwsgierige Gebruiker (CA) 17:05, 24 November 2020 (UTC)
Not done No consensus for system change as proposed, though there is clear indication that consideration be given to granting the right separately if someone is applying for the right, and that admins and 'crats should be considering this pro-actively. — billinghurst sDrewth 06:36, 26 November 2020 (UTC)
Wikidata descriptions changes to be included more often in Recent Changes and Watchlist
Sorry for sending this message in English. Translations are available on this page. Feel free to translate it in more languages!
As you may know, you can include changes coming from Wikidata in your Watchlist and Recent Changes (in your preferences). Until now, this feature didn’t always include changes made on Wikidata descriptions due to the way Wikidata tracks the data used in a given article.
Starting on December 3rd, the Watchlist and Recent Changes will include changes on the descriptions of Wikidata Items that are used in the pages that you watch. This will only include descriptions in the language of your wiki to make sure that you’re only seeing changes that are relevant to your wiki.
This improvement was requested by many users from different projects. We hope that it can help you monitor the changes on Wikidata descriptions that affect your wiki and participate in the effort of improving the data quality on Wikidata for all Wikimedia wikis and beyond.
Note: if you didn’t use the Wikidata watchlist integration feature for a long time, feel free to give it another chance! The feature has been improved since the beginning and the content it displays is more precise and useful than at the beginning of the feature in 2015.
If you encounter any issue or want to provide feedback, feel free to use this Phabricator ticket. Thanks!
Since we are speaking of bots for the global bot policy, I found our meta bot policy is still marked as a proposal. Is there any objections if it becomes policy, tabling here for the community inputs. Camouflaged Mirage (talk) 16:58, 24 November 2020 (UTC)
- No objection from me. Ruslik (talk) 20:24, 25 November 2020 (UTC)
- Comment: Meta is currently following Bot policy, so does this proposal include discontinuing that and making Meta:Bots as policy or we gonna follow both? ‐‐1997kB (talk) 04:02, 26 November 2020 (UTC)
- @1997kB: it reads as though it is meant to be complementary to global bot policy, and where there is dispute between the two policies that that the local wording will take precedence. — billinghurst sDrewth 06:43, 26 November 2020 (UTC)
- This is similar to the oversight and checkuser policies of meta vs global checkuser and oversight policies. This is more towards oversight policy as oversight policy we allow oversight of logged out editing here on meta where the global don't specify. I.e. we can add in more rules of how bots can be used rather than the global bot policy. It is also similiar to checkuser is that the local policy doesn't override the global one, i.e. global bots can operate still (as we the community agree on allowing global bots to run in meta). Hope this clarifies, might be a little confusing. Camouflaged Mirage (talk) 09:35, 26 November 2020 (UTC)
- @1997kB: it reads as though it is meant to be complementary to global bot policy, and where there is dispute between the two policies that that the local wording will take precedence. — billinghurst sDrewth 06:43, 26 November 2020 (UTC)
- okay with this being implemented, nothing controversial, and if we have a bot inactivity policy then something for on the way in makes sense. — billinghurst sDrewth 06:45, 26 November 2020 (UTC)
- See no issues then. It will be useful to have a local policy. ‐‐1997kB (talk) 01:42, 28 November 2020 (UTC)
- Don't get the point, is there anything in there that isn't in Bot policy (which seems to be the local policy, too)? If not, imo having two policies which don't add to each other is just confusing. ProcrastinatingReader (talk) 10:31, 2 December 2020 (UTC)
- @ProcrastinatingReader This proposal basically is to have a separate one for meta, as at times we might differ from the global bot policy and it's easier to list meta only proceedures/pages to apply for bots etc on a stand alone policy page rather than that of global. It's confusing I agree, but one must understand that while meta we host most of the global events, we had also a small community here related to meta so this is the local community bot policy. See Meta:About#Community for more details. Camouflaged Mirage (talk) 10:44, 2 December 2020 (UTC)
- Hmm. But there are no specific local policy points currently, right, and currently it only seems to repeat the global one? Unless there's local terms, what's the point of creating a separate policy page? I fear it would just throw people off / confuse people trying to make meta bots at worst, or at best just add unnecessary reading. If there were any special local terms then yeah, I'd follow, but at a glance I can't identify them
- On a tangential note, where is the local Checkuser policy? I found Meta:CheckUsers but this seems to just be a page that "provides information" rather than anything supplementing Checkuser policy (indeed, it says to visit there for the policy). ProcrastinatingReader (talk) 10:51, 2 December 2020 (UTC)
- @ProcrastinatingReader Specific points might be towards the location to apply for bot flag if it's running on meta, like not a discussion here, neither at SRB but at Meta:Requests for adminship (which the term itself is confusing - hence a local page might help). Pardon me about the use of the term policy there, I should had written information page. Camouflaged Mirage (talk) 10:55, 2 December 2020 (UTC)
- I wouldn't mind turning this into an information page for clarity, but it would need tidying up for that purpose, somewhat reading like the structure of Checkuser policy, with information on meta-specific norms relating to bots. I think that would be quite helpful and improve clarity. However, I somewhat oppose the idea of duplicating it by creating a new policy, though, perhaps revisit this if meta ever passes local-only policies relating to bots; there's only a point to doing this if it improves clarity. ProcrastinatingReader (talk) 10:58, 2 December 2020 (UTC)
- Let me see how it can be tidied up, but we did have one local bot policy which is the inactivity one @ProcrastinatingReader Camouflaged Mirage (talk) 11:01, 2 December 2020 (UTC)
- (Edit conflict.)Alternatively (just saw MarcoAurelio's comment below) could trim it and turn it into a policy page if merging with the inactivity policy, but maybe the distinction between norms vs policy will then become unclear? ProcrastinatingReader (talk) 11:01, 2 December 2020 (UTC)
- I re-read the current page, all of the information could be made policy, they aren't norms anyway. I am treating this thread to have consensus for that page to be of local policy. Let us refine the existing page to make it a good policy is my intent. @ProcrastinatingReader Camouflaged Mirage (talk) 11:06, 2 December 2020 (UTC)
- I wouldn't mind turning this into an information page for clarity, but it would need tidying up for that purpose, somewhat reading like the structure of Checkuser policy, with information on meta-specific norms relating to bots. I think that would be quite helpful and improve clarity. However, I somewhat oppose the idea of duplicating it by creating a new policy, though, perhaps revisit this if meta ever passes local-only policies relating to bots; there's only a point to doing this if it improves clarity. ProcrastinatingReader (talk) 10:58, 2 December 2020 (UTC)
- @ProcrastinatingReader Specific points might be towards the location to apply for bot flag if it's running on meta, like not a discussion here, neither at SRB but at Meta:Requests for adminship (which the term itself is confusing - hence a local page might help). Pardon me about the use of the term policy there, I should had written information page. Camouflaged Mirage (talk) 10:55, 2 December 2020 (UTC)
- @ProcrastinatingReader This proposal basically is to have a separate one for meta, as at times we might differ from the global bot policy and it's easier to list meta only proceedures/pages to apply for bots etc on a stand alone policy page rather than that of global. It's confusing I agree, but one must understand that while meta we host most of the global events, we had also a small community here related to meta so this is the local community bot policy. See Meta:About#Community for more details. Camouflaged Mirage (talk) 10:44, 2 December 2020 (UTC)
- I think we should merge Meta:Bot inactivity policy into Meta:Bots so everything about local bots stay in one place. —MarcoAurelio (talk) 10:55, 2 December 2020 (UTC)
- I agree, let's do the merge once this ended. Camouflaged Mirage (talk) 10:57, 2 December 2020 (UTC)
Call for insights on ways to better communicate the work of the movement
The Movement Strategy recommendations published this year made clear the importance of establishing stronger communications within our movement. To this end, the Foundation wants to gather insights from communities on ways we all might more consistently communicate about our collective work, and better highlight community contributions from across the movement. Over the coming months, we will be running focus groups and online discussions to collect these insights. Visit the page on Meta-Wiki to sign up for a focus group or participate in the discussion.
ELappen (WMF) (talk) 18:56, 18 November 2020 (UTC)
- LOL. Attempting to really communicate would be a good start, contrary to the Decision... has... been... made... attitude. All of the link being generated from 2020 event is saying something. — regards, Revi 22:23, 18 November 2020 (UTC)
- +1. --Base (talk) 15:49, 19 November 2020 (UTC)
- Agreed. --Rschen7754 02:35, 20 November 2020 (UTC)
- @ELappen (WMF): courtesy ping to make sure you saw the responses DannyS712 (talk) 03:45, 20 November 2020 (UTC)
- I did see it, thanks DannyS712. It didn’t feel like anyone was looking for a reply from the team so I didn’t want to butt in, but I will say this work is based on the recognition that we have a lot of room to grow. I totally understand that people are frustrated and disillusioned and may not want to elaborate, but if anyone wants to have a conversation about the specifics of what better, more consistent communication would look like to you, I’d be happy to have it on the project talk page, or here if you prefer. Needless to say, I would also be happy to have any of you sign up for a focus group. --ELappen (WMF) (talk) 18:05, 20 November 2020 (UTC)
- @ELappen (WMF): Okay, I'll bite. In one sentence: When the community tells you no, then listen. For the last several years, the WMF has had a series of colossal failures where they proceeded against the wishes of the community and making excuses as to why they did so ("oh, it was just a vocal minority and the majority really agrees with us", "oh, our TOS requires this" (when it was more a matter of interpretation, for example). Visual Editor? MediaViewer/Superprotect? w:en:WP:FRAM? And now WMF has the temerity to ask us what they are doing wrong (and expect editors to go join a synchronous Google Meet call), as if they can't learn from or understand their mistakes. WMF has since burned all their political capital (and thus not had it when they needed it, such as with global bans) and trust is at an all-time low. I think the fact that all three of us (Revi, Base, and I) are or were stewards, and have almost half a million edits and 34 years of editing experience between the three of us should also say something. --Rschen7754 06:50, 25 November 2020 (UTC)
- +1 —MarcoAurelio (talk) 10:26, 25 November 2020 (UTC)
- @Rschen7754 and others, I think my reply to a similar point applies here as well. Instead of copying it in full, I'll just say here that situations of strong disagreement and massive discussion make one type of communication problems, but there are many more. Of course your perspective as long term Wikipedians and Stewards is very important, it's just that there are many other perspectives in the movement that complement each other. Examples just to illustrate this point include where to find information about what is going on in our movement, how to promote activities to get more participants among Wikimedians or newcomers, how to share community news in multiple languages, how to collaborate effectively in social media outreach, how to collaborate to get more local press coverage, what type of documentation and training the communicators in our movement need, etc. Dozens of volunteers are signing up for the focus groups, some might want to discuss problems like the ones you describe, others might have other priorities. We want to capture everything. Qgil-WMF (talk) 18:17, 25 November 2020 (UTC)
- @Qgil-WMF: Quite frankly, the growing divide between the editor base (read: the people who write the content that motivates people to donate) and the WMF is the most pressing of these problems. In other words, I don't think there will be a movement or a WMF to communicate about in 5 years if the WMF proceeds to alienate the most experienced portion of its editor base like it is currently doing. --Rschen7754 18:30, 25 November 2020 (UTC)
- Noted, and we agree that this relationship is an important problem to address. Qgil-WMF (talk) 22:05, 25 November 2020 (UTC)
- @Qgil-WMF: Quite frankly, the growing divide between the editor base (read: the people who write the content that motivates people to donate) and the WMF is the most pressing of these problems. In other words, I don't think there will be a movement or a WMF to communicate about in 5 years if the WMF proceeds to alienate the most experienced portion of its editor base like it is currently doing. --Rschen7754 18:30, 25 November 2020 (UTC)
- @ELappen (WMF): Okay, I'll bite. In one sentence: When the community tells you no, then listen. For the last several years, the WMF has had a series of colossal failures where they proceeded against the wishes of the community and making excuses as to why they did so ("oh, it was just a vocal minority and the majority really agrees with us", "oh, our TOS requires this" (when it was more a matter of interpretation, for example). Visual Editor? MediaViewer/Superprotect? w:en:WP:FRAM? And now WMF has the temerity to ask us what they are doing wrong (and expect editors to go join a synchronous Google Meet call), as if they can't learn from or understand their mistakes. WMF has since burned all their political capital (and thus not had it when they needed it, such as with global bans) and trust is at an all-time low. I think the fact that all three of us (Revi, Base, and I) are or were stewards, and have almost half a million edits and 34 years of editing experience between the three of us should also say something. --Rschen7754 06:50, 25 November 2020 (UTC)
- I did see it, thanks DannyS712. It didn’t feel like anyone was looking for a reply from the team so I didn’t want to butt in, but I will say this work is based on the recognition that we have a lot of room to grow. I totally understand that people are frustrated and disillusioned and may not want to elaborate, but if anyone wants to have a conversation about the specifics of what better, more consistent communication would look like to you, I’d be happy to have it on the project talk page, or here if you prefer. Needless to say, I would also be happy to have any of you sign up for a focus group. --ELappen (WMF) (talk) 18:05, 20 November 2020 (UTC)
- @ELappen (WMF): courtesy ping to make sure you saw the responses DannyS712 (talk) 03:45, 20 November 2020 (UTC)
- Ibid. --Rschen7754 05:18, 8 December 2020 (UTC)
- Oh, and stop doing so called 'consultation' and pretend as if you listened to us. You did not. — regards, Revi 09:06, 29 December 2020 (UTC)