→Help request: ack and my feelings |
→Help request: re |
||
Line 260: | Line 260: | ||
:-[[User:DePiep|DePiep]] ([[User talk:DePiep#top|talk]]) 10:11, 31 December 2020 (UTC) |
:-[[User:DePiep|DePiep]] ([[User talk:DePiep#top|talk]]) 10:11, 31 December 2020 (UTC) |
||
Thank you DePiep. I am happy to work with {{u|EdChem}} rather than requiring your direct involvement. What would help is your thoughts on how you would like to see me edit in future. You and I worked together previously for several years. I would like to restore that situation with help from EdChem, as he has offered. 2020 has been a bad year, in many ways, and I would like to start 2021 by putting my best foot forward, as I have shown I have previously been capable of doing. I appreciate EdChem may have some thoughts in this regard. It is good that we are still talking. Are we able to put these matters behind us, noting I will need to do a lot better in future? Best regards for 2021. René aka [[User:Sandbh|Sandbh]] ([[User talk:Sandbh|talk]]) 10:35, 31 December 2020 (UTC) |
Thank you DePiep. I am happy to work with {{u|EdChem}} rather than requiring your direct involvement. What would help is your thoughts on how you would like to see me edit in future. You and I worked together previously for several years. I would like to restore that situation with help from EdChem, as he has offered. 2020 has been a bad year, in many ways, and I would like to start 2021 by putting my best foot forward, as I have shown I have previously been capable of doing. I appreciate EdChem may have some thoughts in this regard. It is good that we are still talking. Are we able to put these matters behind us, noting I will need to do a lot better in future? Best regards for 2021. René aka [[User:Sandbh|Sandbh]] ([[User talk:Sandbh|talk]]) 10:35, 31 December 2020 (UTC) |
||
::{{re|Sandbh}} AFAIK, I am not writing as 'direct involvement' here, just an advice (by my evaluation of the situation) as asked for. About a form of 'EdChem guided editing', as I read at ANI, I have written here: I am very wary of n-editor-deals, application of selected generic policies (eg "always assume GF"), and bad discussion flow. Also, this editing route would introduce having to check edits for mistakes-against-a-promise reappearing (bad second nature attitude, like a sleeping distrust). Plus that it would be a huge tour-de-force to change editing habit overnight, I think. Maybe starting such a risky situation (risk of reoccurrance) might keep YBG and Double sharp from rejoining. |
|||
::As for leaving thing behind: very well, and I am expected to do so by any conclusion. Except that reoccurrence c/would reopen the can, not for grudgement but for issue elimination. -[[User:DePiep|DePiep]] ([[User talk:DePiep#top|talk]]) 14:40, 31 December 2020 (UTC) |
Revision as of 14:41, 31 December 2020
You may {{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) |
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) |
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) |
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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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
- 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)
- 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)
- 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)
- 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)
- 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)
- 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 O2 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)
- 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)
- 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)
- 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)
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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- May I agree with that? ^_^ Double sharp (talk) 00:42, 13 November 2020 (UTC)
- 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)
- May I agree with that? ^_^ Double sharp (talk) 00:42, 13 November 2020 (UTC)
- So let's create WP:DABBLE then. Count me in (legally, by evote). -DePiep (talk) 00:39, 14 November 2020 (UTC)
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)
- 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)
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)
- 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)
- 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)
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
| ||||||||||||||||||
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)
- @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)
- 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)
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)
- {{Periodic table (18 columns, micro)}}
- {{Periodic table (32 columns, micro)}}
- 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)
- 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)
- 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)
- 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)
- 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)
- @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)
- 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)
- 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)
- 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)
- @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)
- 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)
- 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)
- 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)
- 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)
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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- User:Michael D. Turnbull: Below in #Regarding your addition I have written my reasoning wrt 18- or 32-column presentation. It is a reply to section Periodic table#Periodic_table#The_32-column_form Double sharp recently added. You're welcome to engage of course.
- That reply does not address the infobox specific situation (at issue here), nor Double sharp's preference to keep N-E-S-W PT-neighbours as infobox relevant (instead of: navigation only, =my point). -DePiep (talk) 18:26, 17 December 2020 (UTC)
WT:ELEM archiving
Just wondering if something has changed recently. As I recall, the bot had been taking care of archiving, but recently I've seen the one-click archiver being used frequently. YBG (talk) 22:04, 16 December 2020 (UTC)
- I did archiving manually, and that is what you saw. Automatic archiving bot archives threads that are inactive for 60d (full ==-threads only). Given that the page is huge, 500–900k easily, I archived threads manually when I judged them complete (no more relevant, discussion continued elsewhere, and such), before 60d. That may be arbitrary, so be it; the size by itself is getting prohibitive for the project talk. As such, it is a consequence of this years talkpage discipline.
- Problem is not finding "finished" threads by itself, but that multiple threads are huge in size (ie, many plain simple long posts), have multiple topics, threads are intertwined between themseves (same topic in multiple threads), and reasoning structure (subthreads, concluding, keeping topics distinct, introducing POV, collapsing-into-limbo threads) towards an encyclopedic improvement is, eh, absent. This year. See these numbers. And yesterday, Dec 15: +32.000 bytes of talk [1]. -DePiep (talk) 22:30, 16 December 2020 (UTC)
Regarding your addition
Firstly, thanks for the thanks: to preserve my comment past the edit summary, I still feel you have it right but that it's difficult to find RS willing to admit it. Secondly, I did some looking after I reverted you: my impression is that 3ARY sources stick to the Britannica line that the main reason is that people find the wideness of the 32 column form inconvenient, as we now say. So yeah, we'll stick to that unless you or anyone else finds someone saying something more detailed. ^_^
PS. That Britannica article is a pretty good inspiration for organisation IMHO. Will think about it. Double sharp (talk) 15:05, 17 December 2020 (UTC)
- "Inconvenient" is a bad argument: I find the word "inconvenient" the lowest quality of argument in here ;-) especially when used in combination with "people find". Sure there are 3RY sources that support this, eh, impression. We even see it in papers and posts from scholars.
- "I am used to it": idem ditto: It still hoovers in the area of "what experienced schienists and scholars are used to".
- Book page ratio: Incidentally, this is a fully different argument from "better fits book's page ratio" (was also present in the text), which is also true (obviously true even), but which might be easily cancelled in the case of modern webpages (various ratios) and of course wall (classrooms), which are presdominantly not bookpage-ratio. Even better: classroom walls have a ratio very suitable for the 32-column form!
- Leave out judgement at all: We can solve this easily because we do not have to report an argument of preference or advantages at all in the article. The section could be: "The PT is also presented in 32-column form: [table graph]".
- Historical development: There is a strong explanation by historical content for the various forms (Mendeleev's 10-column, added NG's, then 18-column before f-block aka "long", then adding the f-block by Seaborg initially crammed into one cell). This is content based, and descriptive, not judgemental. Could be completed in the History article. The published forms themselves are the proof, the original publication is the RS and has enough 2RY 3RY confirmations. Expected, a section about "The PT in 1930" would have the 18-column one. In this 18/32 talk it is relevant because it has the content-based introducion of 18-column form.
- Both forms must be equal: Again, no need to judge any form over the other. As long as both presentations are scientifically equal (they make exactly the same statements). This includes author's choices or claims like positioning H, stating group 3, etc.: must be the same in its 18- and 32-column form.
- All other equal, 32-columns is preferred for being encyclopedical: All this said, there is one more argument for WP: the 32-column form is more encyclopedic. Both for scientists and scholars, especially uninitiated ones(!). It represents the PT without prerequisite of mental reconstruction or disturbing side-explanations. Rarely if ever WP is forced to compromise on this and has to degrade to the 18-column form. We do not have to follow any "popular" form, or "more often seen"—unencyclopedic. A pity so many experienced readers (us editors included) fall back to "I am used to it so let's do the one as I learned it 30 y ago". -DePiep (talk) 17:51, 17 December 2020 (UTC)
- Heh, I agree totally. I also think the "I am used to it" plays a role in it. Rare earth metals were annoying for Mendeleev to place, first they were scattered across groups, it became clear that it doesn't work, then were all stuffed into one cell in the * form, then that was sometimes combined with La form with electronic periodic tables based on misunderstanding of the meaning of electronic configurations. With some protests in favour of Lu once enough was learnt to avoid that historical misunderstanding, of course. F block elements have been misunderstood from the beginning: the inconsistency of 18 vs 32 plus the continued existence of a group 3 dispute is the last shudder of this misunderstanding (thankfully dying slowly). Problem is, this understanding is from Jensen and Thyssen in context of their support for Lu. So it's not entirely usable as a neutral account until/unless La gets killed off. We will have to see about that.
- I think the first section should probably explain those asterisks very early like it does now. And indeed, the book-page lame reason can be left to the history as an explanation for why now, even 115 years after Werner's first long 32 column PT, we still have 18 as common. It is a lame reason indeed, but we ought to report it if RS truly have no better one. ;) Double sharp (talk) 03:12, 18 December 2020 (UTC)
- Just to add a couple of comments that follow from my earlier suggestion about navigation aids. I think that there needs to be a distinction between an article about the periodic table and how we, within Wikipedia, help readers navigate using graphics in the Infoboxes of individual elements. In the article we must use only WP:RS BUT have the space to cover all the history including the Group 3 controversy and the 18 versus 32-column forms (and other layouts). I'm not an expert on any of that and those that are within the ELEM project are doing a pretty good job, in my opinion, when they stop the point-scoring and stick to the aim of making a better encyclopaedia. That said, I think that we editors are missing a trick by not switching to an 18-column compact graphic in the cases where there are constraints imposed by the pixel counts across the page: that's not dependent on reliable sources but is a simple fact regarding how Wikipedia works! Thus I would urge that, at the appropriate time, the ELEM group start that discussion, whether based on "the draft in my sandbox". or in some other way. Mike Turnbull (talk) 11:26, 18 December 2020 (UTC)
- @Michael D. Turnbull: In fact personally I agree. I think, it would be good if the navigation aids were 18 rather than 32 column in the cases where we don't have so much horizontal space. So, I would support 18 in
{{infobox iron}}
, say, but 32 in{{compact periodic table}}
. - This said, I still also think you get not much improvement either way unless we manage to force the cells big enough to inscribe the symbols. Otherwise it is pretty difficult to find for example ruthenium to click on in a solid mass of salmon. DePiep has previously commented that this may not be possible, though. I'd still support 18 there even if this remains impossible, but still: it is something I still think should be tried. Maybe imagemap, maybe Wikitext table, we'll see. But there should be some way, given that when you write about chemistry of a specific element, you usually want to compare with neighbours and congeners to show continuity of trends and comparative chemistry (e.g. talking about iodine, I want to compare to other halogens, also to neighbours Te and Xe for some late period 5 trends). Okay, you sometimes want to refer to faraway elements (e.g. similarities of Cl to Mn), but at least I feel like we should have some sort of "zoom" onto the region we care about like WebElements. If the infobox cannot effectively show the reader who these neighbours are then the article has to do some of this work by itself, possibly with its own picture. This somehow does not satisfy me, but partly technical issues are responsible, which DePiep's more familiar with.
- This said, this conversation was rather about how to describe in the periodic table article the 18 vs 32 column thing and the reasons for it based on RS. The history is coverable from some RS indeed, it seems to be indeed part of a long struggle from Mendeleev onwards on how to deal with the rare earths that is not wholly finished. I also think we can do a good job. ;) Double sharp (talk) 11:43, 18 December 2020 (UTC)
- Apologies, Double sharp, I wasn't trying to muscle in on the conversation regarding the article. To your point on making the cells big enough, I would agree with DePiep that isn't going to be possible: however, from my desktop-based PC perspective, the hover-text of the element's name I get when moving from cell to cell in the graphics is all I need — and when that cell is a bit larger, as it will be in
{{infobox iron}}
etc., my joy will be unbounded... Mike Turnbull (talk) 11:54, 18 December 2020 (UTC)- Mike, please help me convince Double sharp in this ;-). In the {{Infobox element}}, the North, South neighbours should be removed from their current location. As presented today, they are navigation only, not noting an article statement at all. If, as Double sharp says (I think), exactly those two are, eh, contentual meaningful being homologues, then the infobox should have an extra datarow with a Label-Value pair, like: "Homologues: N, S element (linked)". Of course, these two homologues should be significant different from group homology, already present in the infobox. All this similar for the E-W neigbours now in there too. I promis, loyally, I'll make test demo's to enlarge the micro cells as you propose: the micro PT can use that extra width, for hovering at least. (Other issues here then can be discussed still). -DePiep (talk) 16:31, 18 December 2020 (UTC)
- I'm not sure that I can convince anyone, but personally, I don't like trying to fit all the information about E/W or N/S neighbours into the infobox graphic. It makes it very cluttered and doesn't add much that isn't already pretty obvious given all the information about groups, periods and so on that's in the part immediately below in the infobox. I'd prefer if the (18-column, naturally!) graphic stuck to its main task of marking where the element fits, without making assumptions about where the reader might want to go next or what relationships to other elements they are interested in. Also, you get too many complications, like having to mention Uqh under Uranium, which almost nobody will understand and the assertion that He is to the "left" or W of Li when it clearly isn't; it is just the element of next lowest atomic number. Mike Turnbull (talk) 17:13, 18 December 2020 (UTC)
- @Michael D. Turnbull: I think I'm persuaded to cut out the neighbours, since they'll need to be mentioned in the article anyway when relevant, and people will be able to use the 32-column PT at the bottom to get to whatever article they feel like. So, despite your lack of sureness, you succeeded. ;) 18-column for this limited-width situation I am already persuaded by. ^_^ Double sharp (talk) 17:16, 18 December 2020 (UTC)
- I'm not sure that I can convince anyone, but personally, I don't like trying to fit all the information about E/W or N/S neighbours into the infobox graphic. It makes it very cluttered and doesn't add much that isn't already pretty obvious given all the information about groups, periods and so on that's in the part immediately below in the infobox. I'd prefer if the (18-column, naturally!) graphic stuck to its main task of marking where the element fits, without making assumptions about where the reader might want to go next or what relationships to other elements they are interested in. Also, you get too many complications, like having to mention Uqh under Uranium, which almost nobody will understand and the assertion that He is to the "left" or W of Li when it clearly isn't; it is just the element of next lowest atomic number. Mike Turnbull (talk) 17:13, 18 December 2020 (UTC)
- Mike, please help me convince Double sharp in this ;-). In the {{Infobox element}}, the North, South neighbours should be removed from their current location. As presented today, they are navigation only, not noting an article statement at all. If, as Double sharp says (I think), exactly those two are, eh, contentual meaningful being homologues, then the infobox should have an extra datarow with a Label-Value pair, like: "Homologues: N, S element (linked)". Of course, these two homologues should be significant different from group homology, already present in the infobox. All this similar for the E-W neigbours now in there too. I promis, loyally, I'll make test demo's to enlarge the micro cells as you propose: the micro PT can use that extra width, for hovering at least. (Other issues here then can be discussed still). -DePiep (talk) 16:31, 18 December 2020 (UTC)
- Apologies, Double sharp, I wasn't trying to muscle in on the conversation regarding the article. To your point on making the cells big enough, I would agree with DePiep that isn't going to be possible: however, from my desktop-based PC perspective, the hover-text of the element's name I get when moving from cell to cell in the graphics is all I need — and when that cell is a bit larger, as it will be in
- @Michael D. Turnbull: In fact personally I agree. I think, it would be good if the navigation aids were 18 rather than 32 column in the cases where we don't have so much horizontal space. So, I would support 18 in
- Just to add a couple of comments that follow from my earlier suggestion about navigation aids. I think that there needs to be a distinction between an article about the periodic table and how we, within Wikipedia, help readers navigate using graphics in the Infoboxes of individual elements. In the article we must use only WP:RS BUT have the space to cover all the history including the Group 3 controversy and the 18 versus 32-column forms (and other layouts). I'm not an expert on any of that and those that are within the ELEM project are doing a pretty good job, in my opinion, when they stop the point-scoring and stick to the aim of making a better encyclopaedia. That said, I think that we editors are missing a trick by not switching to an 18-column compact graphic in the cases where there are constraints imposed by the pixel counts across the page: that's not dependent on reliable sources but is a simple fact regarding how Wikipedia works! Thus I would urge that, at the appropriate time, the ELEM group start that discussion, whether based on "the draft in my sandbox". or in some other way. Mike Turnbull (talk) 11:26, 18 December 2020 (UTC)
5 ft and 1520mm gauge
Please read my answer in my talk page Zenfox (talk) 21:34, 20 December 2020 (UTC)
Best wishes for the holidays
Season's Greetings | ||
Wishing you and yours a Happy Holiday Season, and all best wishes for the New Year! Stonehenge at mid-winter sunrise is my Wiki-Solstice card to all for this year. --John Maynard Friedman (talk) 15:03, 21 December 2020 (UTC) |
- @John Maynard Friedman: Thank you! A very pleasant surpise to find this uplifting card in my mailbox. All the best for you too (and please don't take stones home in your pocket from the Salisbury plains). Interestingly, Stonehenge is prehiostoric, that is from before any written notes. Given that writing in Wikipedia started in 2001, Stonehenge could be created as long ago as 1995! Mindboggling. -DePiep (talk) 16:02, 21 December 2020 (UTC)
Reversion on Noble gases
Why did you revert my edit on noble gases? UB Blacephalon (talk) 21:59, 21 December 2020 (UTC)
- As I said in my editsummary: "Undid revision 995588763 by Blacephalon (talk) you correctly went to the talkpage. let's see what that produces". here. I am curious for that outcome; properties of oganession are laregly unknown, so is its classification. -DePiep (talk) 22:24, 21 December 2020 (UTC)
- Well according to most chemists it seems Og is a noble gas by definition, since its atomic number places it at the end of a period. That's the route we took (because most chemists take it), and by that idea the classification is "known by fiat" even in the absence of chemical knowledge. Double sharp (talk) 09:39, 24 December 2020 (UTC)
- I am not following the details, just hoping the discussion is fruitful (and newbie not chased away). -DePiep (talk) 10:35, 24 December 2020 (UTC)
- Seems to be so; the article has been improved following Blacephalon's suggestions. ^_^ Double sharp (talk) 12:15, 24 December 2020 (UTC)
- I am not following the details, just hoping the discussion is fruitful (and newbie not chased away). -DePiep (talk) 10:35, 24 December 2020 (UTC)
- Well according to most chemists it seems Og is a noble gas by definition, since its atomic number places it at the end of a period. That's the route we took (because most chemists take it), and by that idea the classification is "known by fiat" even in the absence of chemical knowledge. Double sharp (talk) 09:39, 24 December 2020 (UTC)
A Joyous Yuletide to You!
Merry Christmas and a Prosperous 2021! | |
Hello DePiep, may you be surrounded by peace, success and happiness on this seasonal occasion. Spread the WikiLove by wishing another user a Merry Christmas and a Happy New Year, whether it be someone you have had disagreements with in the past, a good friend, or just some random person. Sending you heartfelt and warm greetings for Christmas and New Year 2021. Spread the love by adding {{subst:Seasonal Greetings}} to other user talk pages. |
ANI notice
There is currently a discussion at Wikipedia:Administrators' noticeboard/Incidents regarding an issue with which you may have been involved. Thank you.
The Signpost: 28 December 2020
- Arbitration report: 2020 election results
- Featured content: Very nearly ringing in the New Year with "Blank Space" – but we got there in time.
- Traffic report: 2020 wraps up
- Recent research: Predicting the next move in Wikipedia discussions
- Essay: Subjective importance
- Gallery: Angels in the architecture
- Humour: 'Twas the Night Before Wikimas
Help request
Dear DePiep, I obviously need help if, in my best endeavours, I'm facing the prospect of a topic ban. Not help in a mental sense; help in how to meet WP expectations sense. I'm obviously missing something.
Is my goose cooked?
Appreciate any help or support either of you could provide.
thank you, --- Sandbh (talk) 09:41, 30 December 2020 (UTC)
PS: I've asked EdChem for help, too.
I won't be online again until tomorrow morning my time; about 10 to 12 hours time.
- @Sandbh:. @EdChem:
- Just read EdChem's reply. My thoughts:
- Many commentors at the ANI thread have made good points. Skipping all my comments (that still might introduce some personal preferences not objective facts, understandably IMO), skipping those does not change the perceptions there. I think the thread did not derail as badly as the previous ones did. So in there are lots of observations that make sense re improving (your) editing. Also, including and since the ArbCom Case Request were some remarks in this direction, usually more subtle (in ArbCom Request, WT:ELEM, Userspace, and by editors who have left).
- The TBAN proposal origins from the IDHT responses you gave, not deminishing recent days. This examplifies the off-mainspace behaviour people see as problematic (IOW, discussion behaviour elsewhere is repeated at ANI).
- Now I cannot see a direct route to avert a TBAN. Promises and good intentions are hard to rely upon, especially since ELEM members tried this in November, when ArbCom was in the picture. If, today, you see and understand the issues at hand, that is a strong point to start from. Still, incorporating them into editing behaviour takes some time; personally I would not be happy having to follow your edits checking for, or awareness of, promises (next to my content responses). This extends not only to proper discussion setups (say propose-advocate-discusds-conclude), but also generic guidelines like GF or COMMONSENSE. I note that since the ARbCom Request, I have often shied away from editing (e.g. in the PT article) to evade problems beforehand altogether. That is not an editing situation I would like having to continue.
- So, for you to rethink these comments you need time and I'd prefer not to experience you practicing real time here. You could take a voluntary TBAN, to the same effect, but I wonder what difference that would make (and adding the need for return-criteria). I also thought what EdChem just wrote to you: the prospect of a TBAN-without-end-time-plus lift request after minimum 6 months is looming (I do not advocate, but is a possible consequence if you would break a voluntary TBAN). Anyway, almost all ANI judgements are directing the same way (again, one may skip my comments), so a less restrictive outcome is hard to imagine. And, this may sound untimely, but if you read this in Feb 2021 think: a TBAN leaves open editing everywhere else! You can contribute while practicing good editing, without the (current) burden the scientific load you want to enter. Could bring back the look and feel of your pre-2020 editing, contributions we all were happy with.
- Again, my comments are harsh-sounding, partly because of my less-eloquent English, my personal involvement, my self-withhold edits, and my desire to be more direct & more clear. You can skip them freely, for example to free the mind of attack-like impressions. There are other editors who have written critiques better, and more opening, to learn from.
- -DePiep (talk) 10:11, 31 December 2020 (UTC)
Thank you DePiep. I am happy to work with EdChem rather than requiring your direct involvement. What would help is your thoughts on how you would like to see me edit in future. You and I worked together previously for several years. I would like to restore that situation with help from EdChem, as he has offered. 2020 has been a bad year, in many ways, and I would like to start 2021 by putting my best foot forward, as I have shown I have previously been capable of doing. I appreciate EdChem may have some thoughts in this regard. It is good that we are still talking. Are we able to put these matters behind us, noting I will need to do a lot better in future? Best regards for 2021. René aka Sandbh (talk) 10:35, 31 December 2020 (UTC)
- @Sandbh: AFAIK, I am not writing as 'direct involvement' here, just an advice (by my evaluation of the situation) as asked for. About a form of 'EdChem guided editing', as I read at ANI, I have written here: I am very wary of n-editor-deals, application of selected generic policies (eg "always assume GF"), and bad discussion flow. Also, this editing route would introduce having to check edits for mistakes-against-a-promise reappearing (bad second nature attitude, like a sleeping distrust). Plus that it would be a huge tour-de-force to change editing habit overnight, I think. Maybe starting such a risky situation (risk of reoccurrance) might keep YBG and Double sharp from rejoining.
- As for leaving thing behind: very well, and I am expected to do so by any conclusion. Except that reoccurrence c/would reopen the can, not for grudgement but for issue elimination. -DePiep (talk) 14:40, 31 December 2020 (UTC)