User talk:Vossanova

Archives

Archive 1 Archive 2 Archive 3 Archive 4

An automated process has detected that when you recently edited General Motors, you added a link pointing to the disambiguation page DMAX.

(Opt-out instructions.) --DPL bot (talk) 06:01, 4 December 2021 (UTC)[reply]

Thanks Vossanova You Are So Cool :D — Preceding unsigned comment added by CornyTheEditor (talk • contribs) 13:19, 19 January 2022 (UTC)[reply]

Template:AMD Radeon 600 mobile has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. Nigej (talk) 17:58, 3 March 2022 (UTC)[reply]

Hey there! I hope you're having a nice day!

I noticed that you reverted my edit at this article. While i would agree that prolly removing the trim levels from that section was not the best idea, i somewhat disagree with the older version of the sentence in the lead (which you restored). I made that change, because it would be a bit verbose repeating "conventional turbo engine option" two times; i also think that my version has a better reading flow.

You seem much more experienced than me; as a new user, i'd really like your thoughts on this.

Best regards! Handmeanotherbagofthemchips (talk) 15:12, 30 June 2022 (UTC)[reply]

Vossanova, sorry for the revert.

It seems to me that it was not a speculation? 81.61.205.107 (talk) 23:30, 24 August 2022 (UTC)[reply]

@81.61.205.107: "It seems to me" is the very definition of speculation. Do you have a WP:RS? --Vossanova ^o< 12:59, 25 August 2022 (UTC)[reply]

A discussion is taking place as to whether the article PMODE is suitable for inclusion in Wikipedia according to Wikipedia's policies and guidelines or whether it should be deleted.

The article will be discussed at Wikipedia:Articles for deletion/PMODE until a consensus is reached, and anyone, including you, is welcome to contribute to the discussion. The nomination will explain the policies and guidelines which are of concern. The discussion focuses on high-quality evidence and our policies and guidelines.

Users may edit the article during the discussion, including to improve the article to address concerns raised in the discussion. However, do not remove the article-for-deletion notice from the top of the article until the discussion has finished.

Flibbertigibbets (talk) 18:56, 22 November 2022 (UTC)[reply]

A discussion is taking place as to whether the article List of Low Cab Forward trucks is suitable for inclusion in Wikipedia according to Wikipedia's policies and guidelines or whether it should be deleted.

The article will be discussed at Wikipedia:Articles for deletion/List of Low Cab Forward trucks until a consensus is reached, and anyone, including you, is welcome to contribute to the discussion. The nomination will explain the policies and guidelines which are of concern. The discussion focuses on high-quality evidence and our policies and guidelines.

Users may edit the article during the discussion, including to improve the article to address concerns raised in the discussion. However, do not remove the article-for-deletion notice from the top of the article until the discussion has finished.

 Mr.choppers | ✎  18:38, 22 March 2023 (UTC)[reply]

Template:Ford China timeline has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. --woodensuperman 15:44, 26 April 2023 (UTC)[reply]

Hello Vossanova!

Do you know who else are active editors of the List of Intel Core 2, i3, i5, i7, i9 articles besides you?

I have an intention to redesign all the tables on List of Intel Core processors to use a similar style and layout to what's on List of AMD Ryzen processors, as well as what's on Rocket Lake. In particular, I would like to merge cells where information is the same, get rid of sSpec and part numbers, remove "header rows", as well as move any info that's exactly the same across all the CPUs (e.g. L2 cache, socket) out of the table and into a bulletpoint list above the table.

I would like to start a discussion before doing this, and see if other editors agree with this plan.

I just got back from merging the Core 2, i3, i5, i7, i9 tables into List of Intel Core, per the proposal on the Intel Core talk page, and ran into a major issue: the "post-expand include size limit" has been exceeded halfway through the merge. Every table from the "Penryn", "Penryn-3M" (medium-voltage, 45 nm) section onwards, is not displaying correctly because of this technical limit.

By removing excessive useless unencyclopedic info (such as CPU part numbers), trimming down info in the table, merging cells, it would cut down the data size of the article by massive amounts, thus increasing the number of CPU generations we can have in a single list article, maybe even not having to split up the article again for the time being. When I redesigned AMD Ryzen tables a few months ago, I was pleasantly surprised by how much removing branding rows, and moving common info out of the tables reduced the data size / footprint of the tables, this is without actually removing any information from the tables. Example. — AP 499D25 (talk) 11:10, 5 May 2023 (UTC)[reply]

Hi AP 499D25, I don't really know who else, if anybody, actively updates the lists of Intel processors, and I've recently lost interest in updating them myself - especially after the daunting task of adding all the new Xeon CPUs. When I did add new ones, I tried to be consistent with previous tables, making minimal changes to the cpulist template. The exception was with Alder/Raptor Lake, where I skipped the template to add columns for P-core and E-core.

While it would be nice to have all the Core processors in one list instead of one per sub-brand, I can see how it would hit max table limits like you said. For Ryzen, they tried getting around this using templates for each section, but that means having to maintain a bunch of templates rather than a single list. Otherwise, we're looking at taking data out of the tables. Part numbers and prices, as much as the OCD part of me enjoys finding and listing them, can be removed. Columns with a single value, like socket, can be moved into a single bullet point above the table. I'm not fond of merging rows per column, as different cell shapes can be a bit distracting and aren't useful in sortable tables, but you do you.

Just one final nitpick - I hate it when they are sorted by default by highest to lowest number. I've always done lowest to highest in my edits, as I can't see why a normal A-Z/0-9 order wouldn't apply here unless you had a reason for listing fastest first. Anyway, best of luck. -- Vossanova ^o< 13:18, 5 May 2023 (UTC)[reply]

Thanks for the response.

What I think I'll do, since the number of regular editors on these articles is low, is start a requests for comment (RfC) to get input from various random editors around.

Anyways, responding to some of the points you have made above:

how it would hit max table limits like you said → The PEIS limit isn't a "limit on tables", but rather, how big the article can get when all the templates and code in the article are "executed". So for example if I create a blank page, and write a template on it, which takes only 10 bytes, but that template itself is 1000 bytes, then when the page is loaded, it will "expand" to 1000 bytes or so in size from the template transclusion, even though the "raw size" of the article is 10 bytes. The maximum size for both "raw" and post-expand include is 2 MB, but the raw size of that Intel Core list article as of now is only ~430 KB. The issue occurs about halfway through the article too, which leads me to believe that these Cpulist templates are incredibly inefficient in how much resources they consume for what data is actually provided.

For Ryzen, they tried getting around this using templates for each section → This is actually incorrect due to how template transclusion works as noted above. The real reason why the Ryzen article has the tables in templates is to deduplicate them between multiple articles that would have the same table, so when you add a new CPU to a mobile Ryzen 6000 series table for example, you don't have to update the table across the two, three, or four articles that have the same table. Rather, you only need to update the template once and it will go live on all articles that have the same template simultaneously. It does make implementing common changes (e.g. adding a column) across all the tables a tedious process as you would have to do it one by one, but I suppose edits to single tables (e.g. to add a new CPU) are more common than edits to all the tables. I've noticed the list of AMD GPUs article also has all the tables in templates, but the List of Nvidia GPUs article doesn't, and someone actually pointed out that because of duplication of tables between the list article and the GPU generation / architecture articles, more often than not, one table can be more up to date than the other.

I'm going to guess the reason why there's separate i3, i5, i7 list articles rather than one "Core i-series" list article is because back when the Core i brand launched, the first CPUs that came out were only i7s, and it was probably not known at the time that i7 was going to be a sub-brand of a brand of processors, and a segmentation thing, rather than a completely different brand of CPU like with Core Duo vs. Core 2 Duo. That's the only way I can make sense of this really strange and rather stupid to me separate articles based on CPU segmentation. If anything, if an article becomes too big it should be split up based on generation / timeline, so for example article 1 covers 1st to 6th gen, article 2 covers 7th to 12th gen, etc. The List of Xeon article is sorted in a similar way, there are separate articles based on CPU architecture (Nehalem, Ivy Bridge, etc).

Regarding merged cells of same information: The tables on Intel CPU architecture articles, as well as AMD CPU & GPU, Nvidia GPU articles have had merged cells for many, many years now and I had never seen anyone complain about them on those articles at all. But your input is appreciated, I had wondered why anyone would prefer cells containing same info to not be merged. Anyways, my concern with this isn't solely on readability but also the amount of data / code that non-merged cells take up, so for example if I repeat "UHD Super Graphics 5000" seven times down a column, that takes up far more code than just writing down rowspan=7 | UHD Super Graphics 5000.

Regarding highest to lowest sorting: this is an inconsistency that I had seen on various AMD and Intel CPU articles for quite a while now, but it seemed to me that the general consensus from active editors on all those articles were in favour of highest-to-lowest-end sorting. Not only that, but also the CPUs are sorted by performance, features, etc instead of alphabetically. So for example, 10700KF would be placed before 10700K, whereas alphabetical sorting would put it after. Honestly I find it much easier to find a specific CPU in a table with the performance/features sorting rather than one with alphabetical sorting. I've seen someone actually try to change the sorting on an Intel article from high-to-low to alphabetically ascending before, only to be reverted numerous times by another editor: diff 1, diff 2. Then there's also this talk page comment. The general argument for fastest-to-slowest order is that the companies themselves list their products in that order. The Ryzen tables actually used to be slow-to-fast order, but I flipped them around in the redesign I did, in accordance with the talk comment and also the general consensus I've seen from editors on Intel articles. — AP 499D25 (talk) 13:08, 7 May 2023 (UTC)[reply]

This message is being sent to let you know of a discussion at the WP:DRN regarding Rimac Nevera. Content disputes can hold up article development and make editing difficult. You are not required to participate, but you are both invited and encouraged to help this dispute come to a resolution. The thread is "List of fastest production cars by acceleration".The discussion is about the topic inclusion of the Rimac Nevera.

Please join us to help form a consensus. Thank you!

NealeWellington (talk) 10:04, 16 June 2023 (UTC)[reply]

Hello! Voting in the 2023 Arbitration Committee elections is now open until 23:59 (UTC) on Monday, 11 December 2023. 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 2023 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) 00:22, 28 November 2023 (UTC)[reply]