Meta:Babel/Archives/2020-09

Direct-link-to-Commons

Hello. Is it just me, or does DirectCommons (in Special:Preferences#mw-prefsection-gadgets) does not work at all on Meta? Anyone know how to fix this? Rehman 05:30, 8 September 2020 (UTC)

Does it work for you at enWP?  — billinghurst sDrewth 15:50, 8 September 2020 (UTC)

What is it supposed to do? Nemo 16:03, 8 September 2020 (UTC)

Yes it works well on enwiki. So basically, clicking on a Commons-hosted file should open it on Commons, instead of from within Meta. Rehman 17:59, 8 September 2020 (UTC)

This is because the definition in MediaWiki:Gadgets-definition has a dependency on the obsolete module "jquery.mwExtension". I think if you removed this dependency it might work. PiRSquared17 (talk) 18:06, 8 September 2020 (UTC)

Thanks! I've posted an edit request on its talkpage. Rehman 04:25, 9 September 2020 (UTC)

This section was archived on a request by: Sgd. —Hasley 11:33, 10 September 2020 (UTC)

Clarification of policy regarding removal of unblock requests (declined) by user when being blocked

I was reading through the RC where I see this. Basically the user removed all the unblock declined messages and then Cabayi reverted and then GZWDer reverted Cabayi reversion. This is basically a mess. I search through the meta policies, can't see any hard policy / guideline that prevents the removal, but then the block notice is very clear not to remove. How shall we proceed, remove the message on the block notice, or codify it per GZWDer suggestion on my talkpage? For me I am ambivalent per my rationale on the user talkpage of the user, " I actually don't care if users remove that or not (personally only) as we admins can still see in the history when dealing with unblocks (and we will carry out such due diligence)," but for this particular user I am more of the fact they shouldn't remove per my rationale "do not remove decline unblock notices while being blocked. It's written in red very clearly in the declined template" ... " but given that your issue is that you don't read documents and get blocked, this is disturbing". Shall we clarify here the approach. One other alternative is to use common sense which I am a strong proponent of (i.e. case by case basis). Hope we can have some clarifications here.Camouflaged Mirage (talk) 18:46, 14 September 2020 (UTC)

I'm not so prolific on meta that I could contradict GZWDer but I'd assume that a template like {{unblock declined}} that's baked into the unblock request process would accurately state the requirements. The text Do not remove this unblock review while you are blocked. has been unchanged (except for review/request and its capitalisation) since July 2013 so it doesn't seem controversial. There was some text about admins removing notices covering expired blocks, but the core principal, that blocked users should leave the notice in place, has been rock solid. Cabayi (talk) 20:02, 14 September 2020 (UTC)

(Sorry for) I did not notice such message while remove it, but in some largest wikis I am active (such as Wikidata and Chinese Wikipedia), it is allowed to remove declined block appeals. Also, Meta seems not to have a blocking policy yet.--GZWDer (talk) 20:09, 14 September 2020 (UTC)

Proposal to enable DiscussionTools on Meta-Wiki as an opt-in Beta Feature

Tracked in Phabricator:
Task T262984 resolved

Hello. I propose that we enable mw:Extension:DiscussionTools on Meta-Wiki and therefore benefit from the reply tool. Installation is subject to the WMF editing team approval but if we're happy with having this enabled here I guess we can get added to the list of wikis interested and get it enabled when they roll out the next batch of wikis. I suggest that DiscussionTools and its associated reply tool be activated as a Beta Feature (opt-in) for those users that want to test it/use it; so users not willing to remain unnafected. The last report at VisualEditor/Newsletter/2020/August appears to show good results and good reception. Note that the reply tool can be used both in Wikitext format and in Visual Editor format. If you want to test the feature before commenting, you can try to add this piece of code to your personal Skin .js subpage and try it out. Courtesy ping to @Whatamidoing (WMF). Best regards, —MarcoAurelio (talk) 21:14, 4 September 2020 (UTC)

•  Support as proposer. —MarcoAurelio (talk) 21:14, 4 September 2020 (UTC)
•  Support enabling it as a beta feature. Sgd. —Hasley 21:18, 4 September 2020 (UTC)
•  Support since it's a very useful and simple to use tool. Agreed it should initially be opt-in. Isabelle ^🔔 22:34, 4 September 2020 (UTC)
•  Support --Novak Watchmen (talk) 22:37, 4 September 2020 (UTC)
•  Support Ruslik (talk) 12:41, 5 September 2020 (UTC)
•  Support Sounds like a good idea: it can be helpful for cross-wiki discussions here and also for a more balanced development of the feature with feedback from a wider cross-section of the community. I understand that it's fully reversible, in that it uses standard wikitext and can be disabled at any moment without any damage to past discussions. (I have not yet checked the code, the development plans or the edits it makes though.) Nemo 12:59, 5 September 2020 (UTC)

  Hi @Nemo bis: I also understand, and support, that we have the last word here and that if for any reason we ain't satisfied with the result we can ask to have the feature undeployed. Indeed as of today the reply tool keeps using standard wikitext so existing talk pages, discussions, etc. ain't disrupted (this comment is being written with the reply tool fwiw) so undo, rollback, revision deletion, etc. works just as before. For now it's just a convenient UI change on the user's side. And in any case, once installed, or opted-in, you use it if you want to use it. The 'edit' links in the sections don't disapear or stop working. Code of the extension can be found at phab:diffusion/EDTO/. Regards. —MarcoAurelio (talk) 10:05, 6 September 2020 (UTC)

• Comment I would ask that if activated that its use on any talk-type be contingent on a consensus on any existing community page. Obviously that would not apply to users' talk pages.  — billinghurst sDrewth 22:08, 5 September 2020 (UTC)

  Hi @Billinghurst: the tool does not modify the working, aspect or configuration of any pages. It just adds a handy link (currently [ reply ]) to the user's UI after each comment that can be replied with the tool. It does not change anything on-wiki. This is not Flow or something like that. Adding it as a Beta Opt-In feature also guarantees that it won't be loaded for anyone but those willing to try the feature out. As Nemo mentioned above, it operates with standard wikitext, and does not harm existing talk pages as a result. I am replying to your comment using the tool, so you can see in the diff that it does nothing weird. Best regards. —MarcoAurelio (talk) 09:55, 6 September 2020 (UTC)

•  Support Yes, using it via js for some time and it works perfectly on user talk pages and other talk namespaces. It would be great if it also works on pages that are not in talk namespaces but used for discussion such as SRUC. ‐‐1997kB (talk) 03:11, 6 September 2020 (UTC)
•  Support I just tested it on ca.wikipedia, and it seems fine to enable (opt-in for now). PiRSquared17 (talk) 03:23, 6 September 2020 (UTC)
•  Support --Sakretsu (炸裂) 13:15, 6 September 2020 (UTC)
•  Support as opt-in. I've used it via the .js loader on w:en. It feels pretty solid once you're aware of its limitations and how it works. You can always cancel out and do a section-edit if needed.
  • You can also test by appending ?dtenable=1 to the URL which I'm doing now.
  • Reply box might not appear where expected if the thread has irregular indentation, but that's not the tool's fault.
  • You can't insert wikitables or other markup that needs to be outdented to the start of a line, or templates. mw:Extension:DiscussionTools/Reply tool visual mode limitations
  • Edit summary currently is set to "Reply" and is not shown nor editable. They are working on that for a future version iteration.
  • @1997kB: It shows [reply] links for me on SRUC but I don't know why. Outside talk namespaces it used to look for pages with Add Section, but they have probably refined the detection logic since I last checked.
  • Signature is appended at the end of the last line (listitem), unless you have embedded list like I've done here. If you want it separate then insert some punctuation after the newline.
  • @-mention name picker is only enabled in Visual mode, though an early prototype demo'd it in Source mode. I'm hoping that will be updated at some point.
  • Like 2017 NWE, it sends wikitext through Parsoid.
  • Right now as I type this, it doesn't appear to be auto-indenting and adding bullets in the way I was expecting. Not sure what's going on there. [Indented with : instead of *]

Hope that's not too much extra detail, --Pelagic (talk) 13:40, 6 September 2020 (UTC)

Weird, doesn't work for me on SRUC, SRGP, SRM. And just noticed that it also add -- in beginning of signature, which means if you have already added -- in settings it will duplicate. IMO it should only use raw signature as ~~~~. ‐‐1997kB (talk) 13:58, 6 September 2020 (UTC)

Just as a note, '--' prefix was added by Martin Urbanec at MediaWiki:Discussiontools-signature-prefix. Sgd. —Hasley 15:55, 6 September 2020 (UTC)

Oh, I'm sorry if that's an issue for anyone - feel free to delete the page. I thought the -- prefix should be added as per the custom, so I added it to the message. --Martin Urbanec (talk) 16:13, 6 September 2020 (UTC)

I think it would be best if it was optional, since not everyone likes adding those dashes. If not possible to make it optional, then better to erase that page. Isabelle ^🔔 16:28, 6 September 2020 (UTC)

Deleted. — xaosflux ^Talk 17:14, 6 September 2020 (UTC)

@1997kB: By default, the tool will only work on discussion, project & help namespaces, and pages using __NEWSECTIONLINK__. See the list of limitations. ESanders (WMF) (talk) 21:14, 7 September 2020 (UTC)

P.S. Using ?dtenable=1 will override these checks which is why it was working for @Pelagic. ESanders (WMF) (talk) 21:21, 7 September 2020 (UTC)

Oh, didn’t think of that, my bad. Thanks, ESanders (WMF). —Pelagic (talk) 17:30, 9 September 2020 (UTC)

•  Support for sure.--evrifaessa ❯❯❯ talk 18:33, 6 September 2020 (UTC)
•  Support. Yair rand (talk) 23:03, 6 September 2020 (UTC)

  Hm, it doesn't match indentation style to earlier comments. Eh, still... --Yair rand (talk) 23:04, 6 September 2020 (UTC)

  It actually used to do it, but we've gotten feedback from some wikis that it's wrong even if another person has already indented their comment with * (some of this is recorded in T252708), and no one has complained as strongly about always indenting with :. The discussion in which we're commenting right now is somewhat of a special case, since it's a poll rather than a "normal" discussion. Better handling for polls and votes is something we have in mind but haven't had time for yet (T259865). Matma Rex (talk) 22:20, 8 September 2020 (UTC)

  @Matma Rex: So my memory isn’t faulty! I think the old behaviour was more desirable. Pelagic (talk) 17:30, 9 September 2020 (UTC)

  Same, but it doesn't matter so long any more since the indenting became the same. Nemo 17:34, 9 September 2020 (UTC)

  Ideally, you would find the start and end of the previous sibling comment at the same indent level, and use the bullet or number style from the start. That way, if the previous comment wasn’t multi-paragraph, you’d be continuing the same HTML list. If there is no sibling, then user expectations will vary. . . . Actually, the truly ideal solution would be that we stop abusing list markup for discussions, but unfortunately that practice is heavily ingrained. Pelagic (talk) 17:56, 9 September 2020 (UTC)

•  Support for sure.Déjà vu • ✉ 01:24, 10 September 2020 (UTC)
•  Support, yes please. Rehman 05:50, 10 September 2020 (UTC)
•  Oppose until the content corruption problem is fixed.
  The design basically cloned Flow's backend wikitext corruption design problem. Rather than simply inserting the new comment into the page, the page content is translated through VE's engine Parsoid, then everything gets re-translated back before saving. This round-trip double translation is unnecessary, and it results in a complex unpredictable array of corruption to page content. Examples:
  A simple plaintext reply "Reply 2."[1] The diff should be a simple one-line insertion, but the Discussion Tool deleted a </span> from a previous comment. The Discussion Tool can corrupt pre-existing content on the page. This corruption causes the red font styling to spill to the end of the section, turning any and all further comments red.
  I copied-pasted a random table from an article to the talk page.[2] The table is corrupted during posting, but more seriously it demonstrates another case where trying to reply corrupts existing page content. I tried post a plaintext comment "A simple reply."[3] As you can see in that diff, the pre-existing comment got completely mangled and the new comment was posted as part of the previous comment at the beginning of the line.
  Here's another failed attempt to copy-paste a table.[4] However more significant is the widespread corruption to the page when I try to make a simple plaintext reply "Reply to reply 1".[5] Note that the diff not only shows the previous comment getting mangled, it shows several comments in multiple different sections of the page all getting mangled by the Discussion Tool.
  The fundamental problem is that they needlessly send everything on a round-trip double-translation through VE's Parsoid engine. Not only does the round trip double-translation cause a variety of corruption issues, the round trip translation process is so complex that there is no realistic way to even find all of the cases that will trigger corruption. The fix is simple - just insert the new comment into the page without sending everything through a round-trip double-translation. I raised the content corruption issue with the Dev team. They could fix it, but they don't want to. In fact when I said "It's like you didn't even bother testing it with anything other than basic text-comments",[6] the Code of Conduct Committee said that post was a conduct violation. I was banned from talking to the team.
  I'll ping the previous RFC respondents, to consider the posted evidence and possibly revise their !vote to say that this must be fixed prior to any deployment.

Alsee (talk) 08:32, 10 September 2020 (UTC)

Tracked in Phabricator:
Task T263709

Have you ever seen anyone type something like {{#if:x|<span style="color:red;|<span style="}} font-weight: bold">This should be red.}}</span> in a discussion on wiki? I've made more than more than 100,000 edits over the last 14 years, and I don't ever remember anyone typing {{#if: to format their comments on a talk page, even without trying to stick a span tag halfway in, and halfway out, of the conditional parser expression.

The Reply tool has been used on multiple wikis more than 20,000 times so far. Enterprisey's very popular reply-links script, which has been used thousands of times by about 500 editors at the English Wikipedia, is also using Parsoid. I think that if Parsoid was causing real problems with page corruption, rather than just someone repeating his favorite illustration of the mw:Parsing/Notes/Two Systems Problem as a demonstration case, we'd have seen them by now. Whatamidoing (WMF) (talk) 19:19, 10 September 2020 (UTC)

So, the code in that first example is horrifying.

Anyway. The issue with the tool choking on tables is quite significant, but I don't think it's a good enough reason to not enable it for opt-in testing as proposed. Certainly I don't think it should be enabled by default on any major project until it's fixed, but that's not what's being proposed. Yair rand (talk) 21:36, 10 September 2020 (UTC)

It doesn't seem to break on actually valid tables (example). It does choke on the broken table wikitext that Alsee used, but that seems like an adversarially-crafted pathological example rather than something that would naturally arise in a discussion. PiRSquared17 (talk) 05:47, 11 September 2020 (UTC)

PiRSquared17 there was nothing adversarial or pathological about the tables I grabbed. The diffs from your example show that you posted your example table using the wikitext editor.[7] Try posting your table with Discussion Tools. You'll find that it mangles your table.[8] That's bad, but that's incidental to the point I'm making. My real point is what happens when anyone tries to make the next reply.[9] You'll find that Discussion Tools spectacularly corrupts the existing page content, even if you try to post a plain one-word reply.
The point is that I have documented two completely-unrelated cases where Discussion Tools will corrupt existing page content. There is a systematic content corruption design flaw, there is a vast and unknown array of other cases where Discussion Tools replies will corrupt existing page content. They could fix the flaw and avoid all of the corruption issues, they just don't want to. Instead they want to keep the flaw and claim they will play whack-a-mole addressing specific cases of corruption. That's exactly what the Flow team advocated, and it doesn't work. Alsee (talk) 12:16, 11 September 2020 (UTC)

Ah, okay, you're right. It seems the problem occurs when you try to write a reply using a table, not when a table is already present. Maybe the Reply editor should give a warning if it detects table markup in the code you're trying to write. PiRSquared17 (talk) 12:26, 11 September 2020 (UTC)

@PiRSquared17 Currently it is not possible to indent a table in wikitext with or without this tool. This is part of the reason we implemented the live preview: so that users could see issues caused by invalid syntax in real time. We also have checks in place to warn about using the tool on pages which may have ended up with this invalid syntax on them. Longer term we hope to introduce new syntax that will make it possible to indent tables, and we are consulting with the Parsing team on an RfC for this. ESanders (WMF) (talk) 21:45, 14 September 2020 (UTC)

@ESanders (WMF): Eh?

Testing indented table

Seems to work? --Yair rand (talk) 22:23, 14 September 2020 (UTC)

Yeah, I tested this on the same example I used before, and it seemingly works fine: [10]. PiRSquared17 (talk) 23:19, 14 September 2020 (UTC)

Sorry, my explanation was overly simplified. The parser's handling of tables in lists is quite hacky, indeed it is commented as "Definition Lists: Hacky use to indent tables". It uses a regular expression to match colons preceding the table open, so there are cases where this would break, for example if you were replying to a bullet or numbered list (e.g. in a !vote context):

*:{|

|foo

|}

The hack is also part of the table parser, not the list parser, so it will also create a new list context in the middle of your comment for the table, which could cause confusing styling on places like French Wikipedia (have a look at the DOM generated by your example for what I mean).

There is also the problem of detecting this while in source mode. You would essentially need to re-implement parts of the wikitext parser to work out which lines to indent with a colon, and which ones to skip. Consider cases where the the table has content before and after it, or nested tables.

Again, we hope to fix this my enabling wikitext to support complex content inside list items more generically, which would remove all these limitations from the tool. ESanders (WMF) (talk) 16:01, 15 September 2020 (UTC)

Limiting it to opt-in testing is a credible option, so long as the team does get the message that it needs to be fixed before deployment as a default feature. Whatamidoing (WMF), there are three big problems with your argument. First, mw:Parsing/Notes/Two Systems Problem is completely irrelevant. The problem is the Parsoid round-trip-translation, eliminating our wikitext engine would do nothing to fix this. Second, I'm saying that there's a minefield of corruption issues. I documented that the minefield exists with multiple examples. Criticizing the location of a specific mine is hardly an argument in favor of putting minefield in our workplace. Third, you're defending the indefensible. Any first-year programming student can tell you that inserting string A (a new comment) into string B (the page) should never have any corruption issues at all. It's like translating an article into Japanese before applying each edit, then retranslating it back to English for saving. And doing that round trip retranslation for each and every edit. That's obviously an absurd. The obvious fix is to eliminate the unnecessary round-trip double-translation. If the dev's answer is "We don't wanna fix it", well, we don't imagine we're going to force them. But we do imagine we can reject a product unless&until it's fixed. Alsee (talk) 05:38, 11 September 2020 (UTC)

I have editted the title of this thread to make it clearer that my proposal was indeed to enable DT as an opt-in Beta Feature only. I am aware that the tool as it is now is not perfect, but it seems to work fine for regular conversation which I think it's what mainly happens here. I hope that the developers can get some more feedback, stats and examples of problems from the usage of the tool here at Meta-Wiki if the proposal passes, and sincerely hope that they work in addressing the issues. The team seems responsive and willing to engage with us in the development of the tool (I get frequent pings in mediawiki.org asking for our opinions on existing or proposed new features at mw:Talk:Talk pages project/replying). If however we signal issues or problems, and the team starts to ignore them, or the tool is abandoned, or for whatever reason after a time we decide this is not for us etc. then I won't hesistate in asking that the feature be disabled and removed as I've done before. Best regards. —MarcoAurelio (talk) 11:26, 11 September 2020 (UTC)

There is a realistic way to find cases that trigger page corruption, and it is phab:T261998, which adds a (hidden) tag to every edit that is detected as having corrupted the page. You're opposing deployment because of a bug that active effort is being expended on fixing, which seems a bit silly. (Removing the </span> tag is reported as phab:T262448, and I can't find a bug ID for the table corruption)* Pppery * _{it has begun} 21:07, 15 September 2020 (UTC)

•  Support —TheDJ (talk • contribs) 10:57, 11 September 2020 (UTC)
•  Support Useful. Camouflaged Mirage (talk) 18:49, 14 September 2020 (UTC)
•  Support * Pppery * _{it has begun} 21:07, 15 September 2020 (UTC)

---

There is a pretty clear consensus here. I have filed phabricator:T262984. --MF-W 21:53, 15 September 2020 (UTC)

Thanks for filing the Phabricator task, MF-Warburg. I'll make sure that it's on the team's list. I don't know when it will happen. They're still talking about who's next (after the Japanese and Vietnamese Wikipedias, which are tomorrow). If there's a particularly good or "normal" page for the team to test the tool on, then please add a link to that page to the Phab task.

As a reminder, the setting will be "opt in". That means that you will have to go to Special:Preferences#mw-prefsection-betafeatures after the team turns on the Beta Feature, and enable it if you want to use it. (If you have the auto-enable setting, then you'll have to wait until your preferences update on their own.) Whatamidoing (WMF) (talk) 17:44, 16 September 2020 (UTC)

The Beta Feature will probably appear some time on Wednesday, 14 October. You will have to go to Special:Preferences#mw-prefsection-betafeatures and turn it on if you want to use it. Whatamidoing (WMF) (talk) 02:36, 10 October 2020 (UTC)

Suggest that a meta framed announced by done to main page at that time.  — billinghurst sDrewth 05:57, 10 October 2020 (UTC)

I'll leave that all in your hands. Please check out mw:Help:DiscussionTools/Why can't I reply to this comment? for quick answers to some common questions. Also, feedback/problem reports can go to mw:Talk:Talk pages project/replying(which is a Flow board, not the Reply tool). Whatamidoing (WMF) (talk) 22:02, 13 October 2020 (UTC)

The Beta Feature is available now in Special:Preferences. Whatamidoing (WMF) (talk) 16:13, 14 October 2020 (UTC)

Comment Main page announcement added with {{Announce Meta}}

This section was archived on a request by:  — billinghurst sDrewth 03:55, 15 October 2020 (UTC)

Global ban RFC for Slowking4

There is a global ban RFC for Slowking4 at m:Requests for comment/Global ban for Slowking4.--GZWDer (talk) 03:30, 30 September 2020 (UTC)

No consensus is the closure by steward Ruslik0. Archiving. Camouflaged Mirage (talk) 18:36, 19 October 2020 (UTC)

This section was archived on a request by: Camouflaged Mirage (talk) 18:36, 19 October 2020 (UTC)

Global ban RFC for Nrcprm2026/James Salsman

Nrcprm2026, better known as James Salsman, has an active discussion regarding a possible global ban.--GZWDer (talk) 07:53, 26 September 2020 (UTC)

Affiliate role accounts

(Previously posted at Talk:Role_account#Affiliate_role_accounts, without response, so reposting here.)

Several affiliates seem to have created role accounts which are active on Meta: User:Wikimedia Österreich, User:Wikimedia Bangladesh, User:Wikimedia Nigeria. Per Role account, such accounts require consensus in advance. Was consensus established for any of these? (Pinging listed WMBD contact User:NahidSultan. The WMNG and WMAT accounts have no listed contacts.) --Yair rand (talk) 04:41, 17 September 2020 (UTC)

Yair rand, it appears that the assertion that consensus is required was added to that unofficial, non-policy page here with no discussion by an account that got a checkuser block the next week. It is possible that the page does not fully reflect reality. WhatamIdoing (talk) 02:03, 23 September 2020 (UTC)

@WhatamIdoing: Huh. Okay then. Personally, I don't think we shouldn't have role accounts except in very limited circumstances, but if this isn't a concluded policy issue, I don't think it's worth it to try to generally figure out the issue from scratch here just for these three accounts, so I'll go ahead and close this. (No idea what to do with the Role accounts page itself.) Thank you. --Yair rand (talk) 08:24, 23 September 2020 (UTC)

Generally they should be discouraged. There is a whole lot of reasoning at the WPs about accounts belonging to an individual, and really how would the wikis and us manage their ownership, management and transferral. I wouldn't want to see them editing on content pages at any content site. I would prefer that they not be used, and don't see a good reason for their active editing.  — billinghurst sDrewth 11:55, 24 September 2020 (UTC)

The English Wikipedia has some of the strongest opposition to them, but Commons seems to like them. It simplifies some of their copyright patrolling work, if you know that an image is being uploaded from the official organization, with OTRS permissions already secured once for the whole account/whole organization. WhatamIdoing (talk) 15:28, 24 September 2020 (UTC)

@WhatamIdoing: I was indicating content wikis. I can definitely see that Commons and Meta being the points of difference, and relating to official function of the organisation in the broadest sense, maybe at content wikis in project namespaces. Can we meet halfway and refine our statements to be Generally they should be discouraged from being used on content wikis, and ... (let us find some words) I don't have a particular issue with them where they are purposefully and assiduously controlled. I feel there needs to be a process to demonstrate that they are controlled by the organisation, and they have a process to manage them. I would prefer to see their creation restricted to CREATOR+ accounts if that can be done tidily.  — billinghurst sDrewth 01:10, 25 September 2020 (UTC)

These associated role accounts should be clearly identified to the organisations, their editing scope identified on their meta user pages, and means of escalation about their (ab|mis)?use.  — billinghurst sDrewth 01:13, 25 September 2020 (UTC)

Billinghurst, I think that the German-language Wikipedia also accepted role accounts. I agree that the best practice is for these accounts to be identified and documented (a global userpage is nice, but maybe not necessary if you're only planning to edit on Commons), but I'm less certain that we could realistically ban them from the content wikis (including Commons) if any local community finds value in accepting them. WhatamIdoing (talk) 18:00, 25 September 2020 (UTC)

WhatamIdoing Not in disagreement with anything that you are saying. Set the principles, point to existing practices that should guide their operation, maybe reserve some keywords, manage expectations, and remind them that they are not exempted from local rules.

I still prefer that, where possible, editing is undertaken an individual account, not behind a group account, which was my meaning with discourage which perhaps needed the qualification. I would not expect a group/role account to be the first choice, and their use should be of limited and focused scope (part of the principles). They should not be a means for an individual to obfuscate their editing within such a role account.  — billinghurst sDrewth 23:08, 25 September 2020 (UTC)

One of these days, we might sort out the practical consequences of Help:Unified login, i.e., that a username that is welcome at one wiki might be banned at another. We might actually need a global username policy. It would step on a few toes (one wiki used to ban usernames of 21+ characters, e.g., User:Billinghurst in public); AFAIK another still has an admin who blocks anyone who puts a 3 where he expects an E, even if the user has never made an edit), but I think the benefits will eventually be worth it. WhatamIdoing (talk) 23:04, 27 September 2020 (UTC)

Wiki of functions naming contest

Please help translate to your language.

Hello. Please help pick a name for the new Wikimedia wiki project. This project will be a wiki where the community can work together on a library of functions. The community can create new functions, read about them, discuss them, and share them. Some of these functions will be used to help create language-independent Wikipedia articles that can be displayed in any language, as part of the Abstract Wikipedia project. But functions will also be usable in many other situations.

There will be two rounds of voting, each followed by legal review of candidates, with voting beginning on 29 September and 27 October. Our goal is to have a final project name selected on 8 December. If you would like to participate, then please learn more and vote now at meta-wiki. Thank you! --Quiddity (WMF)

20:53, 29 September 2020 (UTC)

Heads-up about MassMessaging for annual survey

This is a gentle note to mention that I'm posting some messages in a couple of wikis. I apologize if these messages are viewed are disruptive. The intent here is to request users attention about an e-mail they received earlier this month and which may have been marked automatically as spam. The annual survey is an important way for the communities to share their views and concerns with the Foundation. Based on community feedback from the previous years, we’re considering moving away from the three repeated pings historically used. The e-mails we've sent request the consent (opt-in) of contributors so that, moving forward, we can e-mail them instead of sending on-wiki messages. So the plan is to eliminate the annual disruption and rely only on opt-in email recipients. You may read more about the discussion surrounding this survey here.

Should you have any questions or suggestions, please leave me a note.

Many thanks for your understanding. Samuel (WMF) (talk) 17:15, 25 September 2020 (UTC)

I think the message you sent me was deleted long ago: I can't find it, anyway. I'm happy to respond to anything you put on my talk page. Andrew Dalby (talk) 19:01, 25 September 2020 (UTC)

I appreciate Wikipedia and Wikisource. I do think that Wikipedia is no longer an "anyone can edit" place. I was quite annoyed to discover that an article which I compiled about the early 20th century Scottish Bible college principal and currently in-print author David McIntyre (see http://reynoldsbooks.weebly.com/peterreynoldsbookscom-news-9658/david-mcintyre-of-the-bible-training-institute-wikipedia-article) had been deleted by the author of an article about a Canadian hockey player of the same name who may be famous now but will be forgotten pretty soon. OK Rev McIntyre is not particularly famous now, but he influenced a lot of people and was the ministerial colleague and successor of Andrew Bonar who *is* famous - and he is mentioned at https://en.wikipedia.org/wiki/International_Christian_College. I don't have time to work out how to challenge such practices, and am also disillusioned by the persistent description of Evolution (a theory) as fact - Evolution being a theory involving the gain of information by Natural Selection, as opposed to Natural Selection itself which can be demonstrated but can only be demonstrated to involve at most the loss of information, sometimes only the temporary rearrangement of information. There are powerful people on Wikipedia whose opinions count, regardless of what other people may say. So I hardly ever edit Wikipedia these days, though I've done quite a bit on Wikisource in more recent times. --PeterR2 (talk) 19:20, 25 September 2020 (UTC)

If the emails go to spam, it may be because of poor wording or because Qualtrics.com is perceived as a spammer. Switching to a LimeSurvey instance, which could be configured to send emails from Wikimedia Foundation domains, could help here. Nemo 06:56, 26 September 2020 (UTC)

• @Samuel (WMF): Personally I much prefer stuff onwiki, and wish to see fewer things in my mailbox (grown to hate email) I do hope that an onwiki notification is able to be maintained. I am also a little gobsmacked that people complain about wiki notifications when they are here to edit wikis—that said, people are weird.  — billinghurst sDrewth 23:15, 25 September 2020 (UTC)
• I am a bit astonished by this… "We sent you an e-mail", really? Why not something even less specific like "Notification for you" or "Please respond"? And if you have to link to a diff in the body of the message to avoid spam complaints… perhaps something is wrong here and the message should not be sent at all? I was honestly a bit puzzled to see this originated from the WMF, it seems to be at odds with the communication standards I generally witness from them. And it is just a really bad strategy as far as I can see - if you annoy people about this, at least give them a direct link to the survey in your on-wiki message. If they first have to dig up an email in their spam folder, it is a bad start (see the first reply above). − Pintoch (talk) 06:23, 26 September 2020 (UTC)
  • I suppose the link gets sent by email from Qualtrics.com itself in order to use response tracking (so that each link can only be used once, hopefully by the intended recipient), which is harder if you send a link publicly. WMF's usage of such tracking features is often not clearly specified anywhere, although WMF spends a lot of bytes creating boilerplate pages with a "privacy policy" for each (?) survey. Nemo 06:56, 26 September 2020 (UTC)
• The extremely generic wording of this message is more suitable for phishing than for a legit message about Wikimedia activities. At a minimum, next time please try to follow MassMessage guidelines (such as the usage of a proper signature), otherwise your MassMessage sender rights may be revoked. Thank you, Nemo 06:49, 26 September 2020 (UTC)

  I don't think we've ever revoked anyone's MassMessage rights over using four tildes, even though it results in the bot signing rather than a human. Everyone knows that happens on occasion and is just a harmless mistake. WhatamIdoing (talk) 03:28, 27 September 2020 (UTC)

  I don't think it is worth revoking rights at all if such decisions are simply ignored at the next round… Who cares about what the community thinks, after all? − Pintoch (talk) 12:53, 27 September 2020 (UTC)

  Well, WMF T&S can add any flags they need/want, whatever the community thinks of it. (Well, actually doing it - that is going to be a bit of controversy but that's a different story) — regards, Revi 16:13, 1 October 2020 (UTC)

@Samuel (WMF): maybe forgot that he had left a "heads-up" here, so I've asked him to reply. I could have send an email I suppose :) Andrew Dalby (talk) 16:07, 1 October 2020 (UTC)