User talk:DePiep

You may want to increment {{Archive basics}} to |counter= 14 as User talk:DePiep/Archive 13 is larger than the recommended 150Kb.

	The Special Barnstar
	For your thoughtful, poetic contribution about learning chemistry, and the value of informative categories in science. You have my respect. Sandbh (talk) 11:52, 7 December 2013 (UTC)[reply]

	The Non-metallic Barnstar for improving the Periodic Table You've done a whole damn lot for our project. You've actually made it better. Please keep up.--R8R Gtrs (talk) 17:53, 29 October 2013 (UTC)[reply]

		What a Brilliant Idea Barnstar
		For turning the trivial names of groups table in the periodic table article into a visual feast for the eyes Sandbh (talk) 13:43, 21 April 2013 (UTC)[reply]

	The Graphic Designer's Barnstar
	For your amazing work with the graph. It appears now better than what I thought of it to be before! With your learning ability, you're all up to be an awesome graphic designer, in addition to your template skills! Thanks, man R8R Gtrs (talk) 16:07, 2 September 2012 (UTC)[reply]

Periodic table brilliant idea

The barnstar made me curious: What was the “visual feast for the eyes” you created? ◅ Sebastian 18:04, 29 October 2020 (UTC)[reply]

We show the PT with nine categories (say by metallish behaviour), which require nine background colors to be used as a legend (not just fancy illustration!).

Back then we had our set improved. The category colors look like {{Periodic_table/blind1}} (as published in Periodic table: {{Periodic table}}).

Still it is not great, it is very complicated to find nine distinct colors useful as a legend. (Today, we are going to redesign the set). Anyway, it was an improvement compared to previous color set. -DePiep (talk) 18:14, 29 October 2020 (UTC)[reply]

Ah, I see; I understood “groups” to refer to the columns of the table. But I see not nine, but ten different background colors, including the light gray for the hypothetical elements. ◅ Sebastian 19:10, 29 October 2020 (UTC)[reply]

Yep it's "9+1". Groups/columns do not need colors because they are visible already. A different color scheme is used in block (periodic table). -DePiep (talk) 19:12, 29 October 2020 (UTC)-DePiep (talk) 19:12, 29 October 2020 (UTC)[reply]

Why do you write “it is very complicated to find nine distinct colors useful as a legend”? When I need a bit more than a handful of colours, I like to start out from the Electronic color code, and tweak it as needed. ◅ Sebastian 19:31, 29 October 2020 (UTC)[reply]

Because, being a legend they have to be distinguishable (between one another, and find-tihe-color-in-the-legend requirement (the Reader needs to do), and also v.v. find-color-from-legend-to-image). This asks for strong (outspoken) colors. BUT on the other hand, texts must be readable too (contrast requirements per ws3c and WP:ACCESS). This require light colors -- that is a contradictionary requirement. The number of 9 makes this ~insolvable without compromise, I expect. -DePiep (talk) 19:37, 29 October 2020 (UTC)[reply]

Maybe you're being too perfectionist. I think your choice is a solution, and a good one at that. In addition to the criteria you listed, it also uses familiarity of the color to express how ⸉exotic⸊ their block is. ◅ Sebastian 19:50, 29 October 2020 (UTC)[reply]

well, problems with current colors: grey is used, "brown" for the main main category (metalloids) is not a color. Five reds, no greens is uneven. Before being perfect, lots of improvements possible. A nice process btw, designing for the Reader (science communication). -DePiep (talk) 19:53, 29 October 2020 (UTC)[reply]

I fully agree with your last sentence: Designing (and writing) for the reader is a great challenge, and BTW, IMHO much underappreciated here on Wikipedia. And science communication in particular is a fascinating area, although it apparently more and more falls victim to our edutainment expectations. As for your color tally, I still don't think you're being fair to yourself. By assigning the colors to the coarse boxes of our traditional color names, you're glossing over the fact that both the metalloids and for the reactive nonmetals are represented with hues related to green. But I agree that the use of grey for the post-transition metals is suboptimal; it appears too far away from the transition metals to adequately represent their properties. ◅ Sebastian 20:40, 29 October 2020 (UTC)[reply]

Yes, like that. First new try would be to follow the rainbow left-to-right, as it is a trend inthe PT. And evenly, not 5 reds. (Did this in private PT's I made). However, that could make neighboring colors too much alike. So we could shuffle them, that is create alternating neighbours (blueish next to yellowish; checkering). Not yet noted, there is also requirement colorblind-awareness: through CB filter, less colors remain so they better alternate too. Will be researched. -DePiep (talk) 20:59, 29 October 2020 (UTC)[reply]

OK, now I see what bothers you. You're on a quest for the perfect design, where by “perfect” you understand a logical, provable property. That is probably really insolvable. I think you would feel more at ease if you understood it as an art, not a science. Even for the Mona Lisa, we have no proof that no detail of it could have been improved.

Regarding “evenly, not 5 reds”: I don't think an even color distribution would do justice to the properties of the elements. At least in my layperson understanding, two metals, even from opposite ends of the grouping, are much more related than, say, a halogen with a noble gas. It makes sense that the colors of the latter differ more than those of the former.

Regarding accessibility: It's good that you're thinking about it. But where to stop? Even CB relies on information not available to other disabilities. I'm no expert on this, but here's an idea: It might be best to fork the information: Use a graphic approach for the majority of readers, and create another table intrinsically geared towards accessibility which then could smoothly dovetail with assistive technology. For instance, the accessible version could simply contain abbreviations for the subcategories that would naturally also be read by a screen reader. The PT lends itself to that approach since it changes infrequently enough so that the fork would not require undue extra maintenance work. ◅ Sebastian 10:38, 30 October 2020 (UTC)[reply]

Yes the requirements could be too much. But first we give it a try, so not compromise (split) beforehand. — DePiep 10:50, 30 October 2020 — continues after insertion below

To the contrary, not splitting forces far more compromises. ◅ Sebastian 11:33, 30 October 2020 (UTC)[reply]

beforehand is the active word here. -DePiep (talk) 18:04, 30 October 2020 (UTC)[reply]

re the association of colors and metal property: this is what we cannot permit. The suggestion that metals are more related and so should have the same teint (say reddish) is reducing degrees of freedom. This makes it more difficult to have them distinguished (they will all look alike, ~just like today). — DePiep 10:50, 30 October 2020 — continues after insertion below

This has nothing to do with degrees of freedom in any of the four meanings of that disambiguation page. So there is no reason to state apodictically that “this is what we cannot permit”. And looking alike does not make it hard to distingush them; or has anyone ever told you he or she couldn't distinguish the metals in your coloring? (Well maybe the actinides from the alkali metals; those could really be set a bit further apart. But that's not a fundamental problem, only one of good judgment.) ◅ Sebastian 11:33, 30 October 2020 (UTC)[reply]

That's an omission of Wikipedia then. Until WP is fixed, I'd go with the mathematical one and extend it to 'design'. I'm fine with that.

I am writing short indications of design issues here, not a dissertation. There are six metal categories. Aiming to use only reddish colors for these is nigh impossible given the other requirements. (Been through this design route before, as I wrote). Even maintaining a rainbow-sequence (l-to-r) is critical. -DePiep (talk) 18:04, 30 October 2020 (UTC)[reply]

But yes, I expect no perfect solution. Though trying and playing with colors wil give an improvement. (Another bad design thing is the meaningful fontcolor, red=liquid etc. Maybe solve different too). -DePiep (talk) 10:50, 30 October 2020 (UTC)[reply]

Yes, that might be improved. It's also not logical to attach that information to the atomic number. Moreover, while that information traditionally often is included in the PT, how helpful is it really to know that some form of H (that is, H₂) and some form of O (i.e. O₂, or maybe a mixture of O₂ and O₃, the legend doesn't indicate which) are gases, when the triple point of ubiquitous H₂O is more informative for all manner of things we compute and measure daily? ◅ Sebastian 11:33, 30 October 2020 (UTC)[reply]

We PT people have that in mind too: is it about the concept of the atom (say, a physical thing, and chemical behaviour) or its RL appearance (substances like O₂ and C diamond). However, for this (being liquid at room temp) this is not very problematic. When the State is shown clearly in the graph, the solids and gases show a pattern (l-r); just two seemingly random liquids appear. Point is: do we want to show that in the primary showcase PT. -DePiep (talk) 18:04, 30 October 2020 (UTC)[reply]

Just came across your colored table

Here: https://youtu.be/fCn8zs912OE?t=714. There are a few differences, though – so maybe that's an earlier version? ◅ Sebastian 16:33, 12 November 2020 (UTC)[reply]

Thank you very much! Nice to see, even nicer you noticed & recognised. (Of course Wikipedia is a free source so easy to use). -DePiep (talk) 17:04, 12 November 2020 (UTC)[reply]

Yes an older coloring version (pre 2018): yellow+green form is now single yellow (and renamed), column 30-112 now grey. -DePiep (talk) 17:14, 12 November 2020 (UTC)[reply]

One sign that it's earlier is that it still has the three-letter abbreviations like Uut. But what made me wonder was that several elements that are now light gray (for “unknown chemical properties” – such as At and Cn) were already colored in that table. 😕 ◅ Sebastian 18:32, 12 November 2020 (UTC)[reply]

The four Uxx's were officially named in 2016. At is not "unknown", but "post-transition metal" (dark-grey -- one of the problematic colors!). Cn changed color after new research was published. (All this is at WT:ELEM; usually I follow the talk & apply the consequences like colors). As said, these months WT:ELEM is more chaotic and less stable; conclusions are pushed, a pity. -DePiep (talk) 19:22, 12 November 2020 (UTC)[reply]

Ah, I see. The confusion of the two grays was my error. But we talked about that particular color choice before.

When you mention WT:ELEM, do you mean specifically On the inevitable misunderstandings...? That is really TLDR now. (You already wrote so after one 500 word reply, but the whole discussion has grown to 5500 words since.) It is remarkable that the OP didn't react offended by your characterization of what they wrote as “basically senseless”. That takes a lot of good faith. ◅ Sebastian 19:55, 12 November 2020 (UTC)[reply]

Was not aimed at the OP, was about the thread development. Let me say this: discussions were more fruitful before 2020, somehow, same people. It was easy to cooperate & improve (articles). Not much need to go into that here. While, when the flow returns, I could invite you to follow WP:PTG (now infant). But please do not start commenting on that unborn baby now. I had in mind to tip you for that. -DePiep (talk) 20:05, 12 November 2020 (UTC)[reply]

I noticed people changing in other walks of life, too. In those cases, people understandably are getting more impatient due to the ongoing impact of COVID-19. I wonder if that could be a cause here, too.

Thanks for the pointer to WP:PTG. I added it to my watchlist, but I already got so much on that list that I may well miss the development there. ◅ Sebastian 20:31, 12 November 2020 (UTC)[reply]

Think I'll ping you when it's on. As for 2020: no, changed in 2020 before covid (well, Wuhan was happening but unrelated). Sure 2020 is weird. And then there is 2021. -DePiep (talk) 20:46, 12 November 2020 (UTC)[reply]

btw, SebastianHelm, how come you are so good in this topic and I only know you from this side-talk? Are you hiding some brilliance from me ;-) ? -DePiep (talk) 23:41, 12 November 2020 (UTC)[reply]
- May I agree with that? ^_^ Double sharp (talk) 00:42, 13 November 2020 (UTC)[reply]
  - Thanks for the compliments. Well, i'm interested in many topics, but often not strongly enough: In order to achieve something – here as in the real world – one often needs to compete with people who dedicate much more time and energy to the same area. So i dabble a little here and there, but rarely join a WikiProject. ◅ Sebastian 09:29, 13 November 2020 (UTC)[reply]
So let's create WP:DABBLE then. Count me in (legally, by evote). -DePiep (talk) 00:39, 14 November 2020 (UTC)[reply]
- Sorry, I'm not getting the joke. Do you really mean “drabble”? ◅ Sebastian 10:50, 14 November 2020 (UTC)[reply]
  - sorry, fixed. still might be lame. -DePiep (talk) 11:02, 14 November 2020 (UTC)[reply]

I see. Actually, it's a cute idea. The thought appealed to me, but i can't imagine how it would work in practice. The closest in reality i could think of that would help Wikipedia would be something like a WikiProject for articles not claimed by other WikiProjects. So I did a quick survey of 12 random articles, and found they were claimed by the following number of WikiProjects:

number of WikiProjects	number of articles
0	1
1	6
2	2
3	1
4	2

The one article for the value 0 is David Bowie: Sound and Vision (documentary), which could go in at least four of the WikiProjects found at talk:David Bowie, and certainly is no topic where a dabbler would be of much help. ◅ Sebastian 13:39, 14 November 2020 (UTC)[reply]

Nah, should stay a joke, time is limited. Sure if you browse this wiki you'll find your niche of editing. -DePiep (talk) 14:17, 14 November 2020 (UTC)[reply]

ArbCom 2020 Elections voter message

Hello! Voting in the 2020 Arbitration Committee elections is now open until 23:59 (UTC) on Monday, 7 December 2020. All eligible users are allowed to vote. Users with alternate accounts may only vote once.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2020 election, please review the candidates and submit your choices on the voting page. If you no longer wish to receive these messages, you may add {{NoACEMM}} to your user talk page. MediaWiki message delivery (talk) 01:21, 24 November 2020 (UTC)[reply]

Toggling options

Right, so here we go.

First of all: I just ask this as a sort of proof-of-concept. No guarantees that it will actually be deployed in articlespace, to make it clear upfront. And I have no intention to argue for it now when Scerri's article in Chemistry International telling us about what the project has come up with is still being written and yet to be published. It is just that I thought it was an interesting idea when SMcCandlish proposed it, and that I can definitely see situations in which I think it would be appropriate. ^_^

Now that that's clear: the idea would generally be to have some sort of thing you could click to flip the PT (or really any template) between various forms. Could be used for Sc-Y-La / Sc-Y-Lu; could also be used for something like He-Be vs He-Ne within the specific context of block (periodic table) for example; could even be for something like showing or hiding the extension or flipping between category sets. I can see a lot of possibilities for it beyond just the group 3 and category things, which is why I think developing it might be a good idea anyway. But you're under no obligation to really do it; I was just curious if it could be done. ^_^ Double sharp (talk) 21:18, 24 November 2020 (UTC)[reply]

An addendum summarizing my original yakking: It would be a lot of Lua work, and we'd also need to establish what the default output should be (for people running without JavaScript). And "default" might be universal or something set on a per-category/field basis, or whatever; depends on the consensus discussion outcome[s]. — SMcCandlish ☏ ¢ 😼 21:29, 24 November 2020 (UTC)[reply]

I understand. In my testpage I have two technical options. Third one is todo: that would be "zoom" (so not exactly fits here, but a major need for the PT: show overview PT <-> cell details. Example: see US election broadcasts at CNN or NYT: USA map w/colored states, and opening popup with State detailed numbers).

c:Category:Animated GIF files can handle table images, pics &tc, and with various precision (fluid/flickering alternations). No pause option AFAIK. Jscript required?

The map options map zooming (Paris example) are hardcoded in Lua for maps (globe coord calculations!). PT would be easier / hardcoded. Could be cluncky?

Meanwhile, the actual flipping content trbd. -DePiep (talk) 21:52, 24 November 2020 (UTC)[reply]

The Signpost: 29 November 2020

News and notes: Jimmy Wales "shouldn't be kicked out before he's ready"

Op-Ed: Re-righting Wikipedia

Opinion: How billionaires re-write Wikipedia

In the media: Relying on Wikipedia: voters, scientists, and a Canadian border guard

Featured content: Frontonia sp. is thankful for delicious cyanobacteria

Traffic report: 007 with Borat, the Queen, and an election

News from Wiki Education: An assignment that changed a life: Kasey Baker

GLAM plus: West Coast New Zealand's Wikipedian at Large

Wikicup report: Lee Vilenski wins the 2020 WikiCup

Recent research: Wikipedia's Shoah coverage succeeds where libraries fail

Essay: Writing about women

* Read this Signpost in full * Single-page * Unsubscribe * MediaWiki message delivery (talk) 17:45, 29 November 2020 (UTC)[reply]

Administrators' newsletter – December 2020

News and updates for administrators from the past month (November 2020).

Administrator changes

Andrwsc • Anetode • GoldenRing • JzG • LinguistAtLarge • Nehrams2020

Interface administrator changes

Izno

Guideline and policy news

There is a request for comment in progress to either remove T3 (duplicated and hardcoded instances) as a speedy deletion criterion or eliminate its seven-day waiting period.

Technical news

Voting for proposals in the 2021 Community Wishlist Survey, which determines what software the Wikimedia Foundation's Community Tech team will work on next year, will take place from 8 December through 21 December. In particular, there are sections regarding administrators and anti-harassment.

Arbitration

Voting in the 2020 Arbitration Committee Elections is open to eligible editors until Monday 23:59, 7 December 2020 UTC. Please review the candidates and, if you wish to do so, submit your choices on the voting page.

Sent by MediaWiki message delivery (talk) 02:37, 1 December 2020 (UTC)[reply]

Something weird with the 18-column micro Periodic Table

Hi DePiep. On 25 July, I placed your then-new version of Template:Periodic table (18 columns, micro) on my User page, because I liked it so much. I used the version where I highlighted some of the elements I'm interested in so the mark-up was {{Periodic table (18 columns, micro)|mark=C,H,N,O,S,F,Cl,Br,P}}. Today I noticed that the table now looks like this

Tin

It has black marked cells and some others. I'm pretty sure that wasn't how it looked before and is much inferior. Can you explain what is going on and preferably fix it? The issue must be in the depths of what the template calls, as the template itself hasn't been edited since July. Thanks. Mike Turnbull (talk) 14:15, 6 December 2020 (UTC)[reply]

@Michael D. Turnbull: Should be fixed (collateral damage from recently agreed element category colour change, sorry). Double sharp (talk) 15:00, 6 December 2020 (UTC) (talk page stalker)[reply]

Thanks, that's perfect. I wondered whether the discussion on colours was the problem but I haven't been following that closely. Mike Turnbull (talk) 15:18, 6 December 2020 (UTC)[reply]

18 or 32 ideas

Just curious, Mike Turnbull: can you tell us why you prefer this one over the 32-column form? -DePiep (talk) 17:55, 6 December 2020 (UTC)[reply]

Tin

Because I'm an organic chemist and more accustomed to seeing that form of the table! Incidentally, if you remember, I wanted to propose that the 18-column form was tweaked to make the boxes bigger, for use in the Chemboxes of element articles. There is still a discussion proposal for that in my sandbox "here". which it might now be time to resurrect.... Mike Turnbull (talk) 18:09, 6 December 2020 (UTC)[reply]

Thx. Just some notes, not complete replies. Well, ELEM is very very busy these days ;-) and we have to change (redesign) the category colors to be more balanced. Changing the presentation (32 to 18) to accomodate webpage effects is a bit strange to me, like wrong priorities. Personally I prefer the 32-column form, for having no needless IKEA deconstruction. I guess only older scientists ;-)prefer the 18-column one. When I worked with a highschool chem teacher, he was very happy to use a 32-cooluimn form. -DePiep (talk) 18:25, 6 December 2020 (UTC)[reply]

I'd absolutely advocate to remove the neighbouring elements (above-below-left-right or N-E-S-W) in the element infobox. This is navigation not info. Extra space can be used to widen the micro cells. -DePiep (talk) 18:44, 6 December 2020 (UTC)[reply]

If you propose that, you'll get support from me, provided the micro cells get to be widened enough to show the element symbols. ^_^

FWIW, I think 32 is the theoretically ideal form and 18 is a concession to practice kind of like moving Alaska and Hawaii on maps of the USA. But as long as the 18 and 32 are consistent, I'm willing to accept 18. Double sharp (talk) 01:33, 7 December 2020 (UTC)[reply]

The issue, for me, is all about ease of navigation and ^_^'s comment regarding maps is an excellent analogy. So, if you, Double sharp and DePiep support my proposal, which is basically to widen the 18-column micro table so that it is the same with as the current 32-column one (hence fitting into Chemboxes but with bigger cells) I'll move the proposal now in my Sandbox (linked as above here) into the ELEM talk page. By all means suggest improvements to the wording of the proposal so that it is more likely to get a swift consensus. Note that I don't think the cells could be big enough to show the element symbols. Mike Turnbull (talk) 12:07, 7 December 2020 (UTC)[reply]

@Michael D. Turnbull: I understand about the symbols; it's just something I wish could be done, but I understand it might not be practical. I'd still support 18 for the micro table as being more familiar and suiting the limited width we have; 32 makes most sense for the footer when we have a lot of width and 18 won't fill the space well. So I'd support your proposal. Double sharp (talk) 12:12, 7 December 2020 (UTC)[reply]

There is no space for symbols, and being a micro PT has a reason and a consequence: only to show an overview not details. The main overview to show is period, group, block, category. -DePiep (talk) 12:18, 7 December 2020 (UTC)[reply]

We could add headers for rows and columns. Removing the N-S elements would give 10% extra width. -DePiep (talk) 12:20, 7 December 2020 (UTC)[reply]

Must say, I am not convinced that enlarging and using the 18-column form would be desirable. (Enlarging to occupy the same width would be a 80% enlarging of the cells (linear). Navigation is not the purpose of the infobox, and squeezing in such function would creep infobox essence. Then having to return to the 18-column form, for the wrong reasons, is a setback and reducing information quality. An IKEA DIY building box is not helpful in giving the overview. -DePiep (talk) 12:30, 7 December 2020 (UTC)[reply]

I'm not clear why "navigation is not the purpose of the infobox" when it clearly has that functionality. Users who accidentally mouse-click on one of the cells will be whisked off to the article for the element they clicked on. Merely hovering over the cell gives its page title, or page preview if the user is not logged on, so there's a lot going on in these little graphics. Maybe you would prefer removing such functionality in the micro version of the table? That's not something I'd support but is a logical step given your "not navigation" opinion. Incidentally, IKEA is very successful, so perhaps not so damning as you imply ;-) Mike Turnbull (talk) 12:50, 7 December 2020 (UTC)[reply]

The 18-column form requires an extra mental step to get it. Only more experienced readers (like us) are familiar with the cut-and-paste trick, for new readers this is a distracting complication. And, of course, not helping to give the *overview*. I am not saying or suggesting that the links should be removed. -DePiep (talk) 13:01, 7 December 2020 (UTC)[reply]

OK, I guess that's the crux of our difference of opinion. My opinion is that the "cut-and-paste" version of the periodic table is actually the one most people are familiar with, as evidenced by the {{Periodic table}}, the version top right in the periodic table article and IUPAC's standard (albeit not "endorsed") version. It is certainly the version I first saw when in school chemistry, although in those days we paid hardly any attention to the lanthanides and actinides (except uranium). I don't want to make a big fuss about this: as I said I'm mainly concerned to make navigation around WIkipedia as easy as possible and I think the element infoboxes are ideal places to do that. Mike Turnbull (talk) 13:18, 7 December 2020 (UTC)[reply]

I guess what DePiep says is true if you think about it as restoring an ideal format, since the asterisks basically mean "slot the f block elements in there". So with an 18 column form you have to imagine what the 32 column form gives you. But, in terms of sheer commonness, 18 column is way more familiar and everyone is used to the footnoted f block. That's how I saw it in books, that's how I saw it in school, that's basically how I see it almost everywhere frankly. So if we speak about navigation I think 18 column serves the readers better due to familiarity, whereas 32 column may leave people wondering how it relates to the format they're used to: the direction of imagining then becomes 32-to-18 instead of the other way round. I also think Michael D. Turnbull is correct about how it matches the way the f elements are generally considered not very important to talk about at school level (and, as an aside, I guess uranium truly is the most interesting of them anyway). But, I also do not want to make a fuss about the issue either. Double sharp (talk) 13:26, 7 December 2020 (UTC)[reply]

re User:Michael D. Turnbull: I don't have time to reply more thorougly; the reply you deserve here & in this. Maybe time is part of the solution. -DePiep (talk) 23:38, 7 December 2020 (UTC)[reply]

Social interactions

On the heels of [1] now comes now this [2], so I have to ask you, yet again, to stop trying to police the other editors' behavior. I don't know what your cultural or educational background is, but for whatever reason (and I'm putting this as gently as I can, under the circumstances) you lack the social awareness to grasp the nuances of other users' social interactions. You simply do not understand a lot of what goes on, and for whatever reason it seems to be in your nature to think the worst of what you do not understand. You made a narrow escape at Arbcom recently, but had that case gone forward your habit of scolding people for things you don't understand would not doubt have been a significant topic of the proceedings.

You will likely, as you have before, dismiss this message as trolling, but multiple editors have told you this and I'm repeating it now for your own good: stick to content issues and leave the behavioral commentary to others. E Eng 01:37, 13 December 2020 (UTC)[reply]