Talk:2019 Formula One World Championship/Archive 4

Alfa Romeo
According to this BBC article, the Alfa Romeo team will still be based in Switzerland: "The Swiss team say the ownership and management structure remains unchanged but the Sauber name will disappear." Besides this, Autoweek quotes team principal Frédéric Vasseur confirming where the newly-named team will be headquartered: "This has given a boost of motivation to each team member, be that trackside or at the headquarters in Switzerland, as the hard work invested has become reflected in our results." I think it is clear that Alfa Romeo will remain a Swiss team, so the recent spate of edit warring can end. -- Scjessey (talk) 17:07, 5 February 2019 (UTC)
 * We know Sauber raced under a Swiss licence, but we've no idea whether Alfa will change that, so the nationality under which they will race is, as yet, unconfirmed. So it's probably best to stick with the "none" flag, for the time being. -- DeFacto (talk). 17:16, 5 February 2019 (UTC)
 * Alfa Romeo gave no indication the organisation would be moved from Switzerland to some other country, and we needn't speculate. It would frankly be bizarre to do such an upheaval. The article should reflect the current state of affairs, which is that it is a Swiss team. -- Scjessey (talk) 17:26, 5 February 2019 (UTC)
 * They don't need to move to change the flag they race under - look at all the British teams that race under foreign flags, and as Alfa aren't Swiss, it's not unreasonable to imagine they might choose to change it. -- DeFacto (talk). 17:47, 5 February 2019 (UTC)
 * But they are currently a Swiss team, as backed up by reliable sources. It makes no sense to remove the Swiss flag just in case they decide to change nationality. -- Scjessey (talk) 17:55, 5 February 2019 (UTC)
 * Very good point, but with the name change they, effectively (apparently) become a new constructor. Probably best not to worry about it, and wait to see how it turns out. -- DeFacto (talk). 18:11, 5 February 2019 (UTC)
 * They're a Swiss-based team, not necessarily a Swiss-licenced team. Because the constructor changed, they have to make a new registration with a national motorsports governing body. We cannot simply assume that they have done that with the Swiss one (ACS). We need a source to support that. What you're doing is making your own synthesis out of some facts.Tvx1 19:16, 5 February 2019 (UTC)
 * Alfa Romeo Racing with Swiss flag. Official source. The full constructors name is Alfa Romeo Racing-Ferrari, see here.--79.19.108.206 (talk) 12:44, 6 February 2019 (UTC)
 * Also this. -- Scjessey (talk) 13:36, 6 February 2019 (UTC)
 * I don't see their licence nationality mentioned on that page, but look at the graphic on the Alfa entry on this one (as posted above by 79.19.108.206), they seem to think it is going to remain Swiss. -- DeFacto (talk). 14:23, 6 February 2019 (UTC)
 * The F1.com is rather slow in updating however. It still lists Sauber's records for Alfa Romeo as well, notwithstanding they appear to be separate constructors.Tvx1 15:50, 6 February 2019 (UTC)
 * Toro Rosso's full Constructor/Engine name as according to the FIA entry list is "Scuderia Toro Rosso (STR14)-Honda", I think we should keep Alfa's constructor name as just "Alfa Romeo" for now until we have more sources. Speedy Question Mark (talk) 16:53, 6 February 2019 (UTC)
 * What do you mean "More Sources", there's literally only one relevant source for an entry list and the entry list is it. Duds 2k (talk) 18:05, 6 February 2019 (UTC)
 * I note the "Chassis" was changed to TBA, which makes sense but if that's the convention, the entry for Ferrari is now wrong Duds 2k (talk) 18:09, 6 February 2019 (UTC)
 * Let's change Toro Rosso's to "Scuderia Toro Rosso (STR14)-Honda" then if that's the only source we need. (!) Speedy Question Mark (talk) 18:29, 6 February 2019 (UTC)
 * Don't be obtuse. The column is for the name of the chassis, not the name of the constructor.  The359  ( Talk ) 18:34, 6 February 2019 (UTC)
 * The FIA publishes separate entry lists for the different grands prix. These generally have a column labeled constructor. We always use both the season and Grand Prix entry lists to verify the constructor names.Tvx1 18:53, 6 February 2019 (UTC)
 * @The359, I'm using the same logic as that's the name listed on the FIA entry list. Speedy Question Mark (talk) 19:26, 6 February 2019 (UTC)
 * No, you're not. The359  ( Talk ) 20:48, 6 February 2019 (UTC)
 * They're not always identical on the different entry lists. Sometimes the abbreviations STR or very rarely RBR were used to save space. Since STR14 is put between brackets, I doubt that is actually intended to be part of the constructor name. That appears to be the chassis type. Regardless I don't really think that it's very debatable that the contested constructor name is "Alfa Romeo Racing".Tvx1 21:29, 6 February 2019 (UTC)
 * Exactly, by "Speedy"'s logic the STR one should just be "Toro Rosso" as that's the bit of the team name that isn't "Team". It isn't though. And yeah if it changed on a future race entry list it might well be worth changing but right now we have 1 entry list, 1 source and I'm confused why it's even a discussion other than a user has decided what it should be called and is edit warring the cited entry from the only available official source Duds 2k (talk) 21:45, 6 February 2019 (UTC)

As far as I can tell, "Alfa Romeo Racing" is the only name the team has used to date. Therefore we should treat it as the constructor name until we have evidence to the contrary. 1.144.104.89 (talk) 01:03, 7 February 2019 (UTC)
 * @The359, It was the exact same logic you were using, if that's how it is listed on the FIA entry list (as "Scuderia Toro Rosso (STR14)-Honda") and if that's apparently the only source we can use then that must be the constructor name that we use for Toro Rosso. I'm using that as a example I'm not saying we should change it to that, these FIA lists aren't always that consistent. Speedy Question Mark (talk) 15:07, 7 February 2019 (UTC)

Seriously, guys, this edit warring over the flag icon has to stop immediately. In my opinion, it should remain as SUI until we have a source that changes that, but edit warring is much worse than it being wrong. Cut that shit out. -- Scjessey (talk) 17:04, 7 February 2019 (UTC)
 * The constructor changes, a new registration is required. We cannot assume the license is still Swiss. We need to support content with reliable sources. We need a source here of one of the relevant people discussing the license.Tvx1 17:16, 7 February 2019 (UTC)
 * That is no defence of your edit warring. -- Scjessey (talk) 17:35, 7 February 2019 (UTC)
 * I'm not one of the ones who were edit-warring. I just restored the last good version prior to the edit war. I hadn't edited the page for two days prior to that.Tvx1 18:03, 7 February 2019 (UTC)
 * See WP:WRONGVERSION. -- Scjessey (talk) 12:35, 8 February 2019 (UTC)

This precedent was established so long ago that I wouldn't even know where to begin to look for a source, but the reason teams like Red Bull use the full "Red Bull Racing" as their constructor name is because FOM (I think Bernie specifically) felt that a name like "Red Bull-Honda" could be misconstrued as a Red Bull-sponsored Honda factory team. Given that Alfa Romeo was purely a sponsor of Sauber last year, I suspect they have chosen the full team name as their constructor name for similar reasons. Regarding Toro Rosso - last year they also included "(STR13)" in their constructor name and we also chose to ignore it. Note that the name of that column is actually "Name of the Chassis." I suspect the person at Toro Rosso who fills out this paperwork is under the impression they need to include the actual chassis designation, not just the constructor. Obviously (STR14) is not intended to be part of the constructor name. Wicka wicka (talk) 14:44, 8 February 2019 (UTC)


 * Shouldn't the constructor be Sauber and not Alfa Romeo Racing? Alfa is only a title sponsor with the team's ownership remaining unchanged with the chassis still produced by Sauber. Fecotank (talk) 05:36, 22 February 2019 (UTC)


 * By that logic, Toro Rosso is still Minardi, Racing Point is still Jordan and Mercedes is still Tyrell.


 * Last year, the team competed under the name "Alfa Romeo Sauber F1 Team" and the constructor was Sauber. This year they are "Alfa Romeo Racing" and the constructor is Alfa Romeo. The car might have been built in the same factory by the same people (and is even known as the C38 as a continuation of Sauber's naming tradition), but they are treated as a new constructor because the results will be credited to Alfa Romeo. The rules also state that the name of thr constructor must be incorporated into the name of the chassis, and the chassis is known as the Alfa Romeo Racing C38, not the Sauber C38. Mclarenfan17 (talk) 10:23, 22 February 2019 (UTC)
 * Hello! Constructor name is based on the "Name of the Chassis" column in the FIA's official entry list. It's listed as Alfa Romeo Racing there, hence that's what we use. Wicka wicka (talk) 13:14, 22 February 2019 (UTC)

Literally every source online, whether it be Formula1.com, Motorsport.com, etc says that Alfa Romeo Racing will race under the Swiss flag. The only "baseless speculation" is people pretending that they won't race under the Swiss flag for whatever reason. There is no evidence that Alfa Romeo Racing won't race under the Swiss flag. There is evidence that Alfa Romeo Racing will race under the Swiss flag. I don't understand how you can argue that unsourced evidence magically makes sourced evidence untrue. They're not going to magically switch to the Italian flag 2 weeks before the race. Leave it as the Swiss flag. Alfa Romeo Racing will race under the Swiss flag. This shouldn't be an argument. JoeyofthePriuses (talk) 03:28, 4 March 2019 (UTC)

Request for comment on table sorting
I've started this RfC because an ongoing discussion has reached a stalemate. Hopefully the voices of some uninvolved editors will help clarify the situation. The issue is as follows: how should the sorting function be applied to tables in the article? Specifically, we are interested in the entry table. Mclarenfan17 (talk) 04:10, 24 February 2019 (UTC)

First, some context as to how this situation came about. Prior to 2014, the sport used a system of assigning numbers to drivers based on their team's performance in the previous year's championship. This gave editors an easy way to structure the entry table. However, in 2014, the sport changed its system so that drivers could choose a personal number that they would carry for the duration of their careers. This presented a challenge for editors since the table could no longer be structured according to numbers; for example, Renault currently have #3 and #27 whereas last year they had #27 and #55. After some discussion, it was decided that the organisation of tables from 2014 had to be logical and the structure had to be obvious to the reader. The tables are now arranged alphabetically by constructor and drivers were arranged numerically within their teams.

We then discovered that we could add markup to the tables allowing readers to reorganise the table as they saw fit. For example, you can sort based on engine supplier so that you can see which teams are using the same engine at a glance. We aldo sought to apply this to other columns, such as the number column, and this is where the point of contention arises. Mclarenfan17 (talk) 04:22, 24 February 2019 (UTC)


 * My position (I've done this as a separate comment to keep the above as neutral as possible) is that the number column does not behave as the reader would expect it to. I believe that the reader would expect the column to be sorted sequentially, which for 2019 is as follows:
 * {|class="wikitable" style="font-size: 85%;"

!Team !No. !Driver
 * Renault
 * align="center"|3
 * Ricciardo
 * McLaren
 * align="center"|4
 * Norris
 * Ferrari
 * align="center"|5
 * Vettel
 * Alfa Romeo Racing
 * align="center"|7
 * Räikkönen
 * Haas
 * align="center"|8
 * Grosjean
 * Red Bull Racing
 * align="center"|10
 * Gasly
 * Racing Point
 * align="center"|11
 * Pérez
 * Ferrari
 * align="center"|16
 * Leclerc
 * Racing Point
 * align="center"|18
 * Stroll
 * Haas
 * align="center"|20
 * Magnussen
 * Scuderia Toro Rosso
 * align="center"|23
 * Albon
 * Scuderia Toro Rosso
 * align="center"|26
 * Kvyat
 * Renault
 * align="center"|27
 * Hülkenberg
 * Red Bull Racing
 * align="center"|33
 * Verstappen
 * Mercedes
 * align="center"|44
 * Hamilton
 * McLaren
 * align="center"|55
 * Sainz Jr.
 * Williams
 * align="center"|63
 * Russell
 * Mercedes
 * align="center"|77
 * Bottas
 * Williams
 * align="center"|88
 * Kubica
 * Alfa Romeo Racing
 * align="center"|99
 * Giovinazzi
 * }
 * However, when you sort by number, you get the following:
 * {|class="wikitable" style="font-size: 85%;"
 * Sainz Jr.
 * Williams
 * align="center"|63
 * Russell
 * Mercedes
 * align="center"|77
 * Bottas
 * Williams
 * align="center"|88
 * Kubica
 * Alfa Romeo Racing
 * align="center"|99
 * Giovinazzi
 * }
 * However, when you sort by number, you get the following:
 * {|class="wikitable" style="font-size: 85%;"
 * Giovinazzi
 * }
 * However, when you sort by number, you get the following:
 * {|class="wikitable" style="font-size: 85%;"
 * {|class="wikitable" style="font-size: 85%;"

!Team !No. !Driver
 * rowspan=2|Renault
 * align="center"|3
 * Ricciardo
 * align="center"|27
 * Hülkenberg
 * rowspan=2|McLaren
 * align="center"|4
 * Norris
 * align="center"|55
 * Sainz Jr.
 * rowspan=2|Ferrari
 * align="center"|5
 * Vettel
 * align="center"|16
 * Leclerc
 * rowspan=2|Alfa Romeo Racing
 * align="center"|7
 * Räikkönen
 * align="center"|99
 * Giovinazzi
 * rowspan=2|Haas
 * align="center"|8
 * Grosjean
 * align="center"|20
 * Magnussen
 * rowspan=2|Red Bull Racing
 * align="center"|10
 * Gasly
 * align="center"|33
 * Verstappen
 * rowspan=2|Racing Point
 * align="center"|11
 * Pérez
 * align="center"|18
 * Stroll
 * rowspan=2|Scuderia Toro Rosso
 * align="center"|23
 * Albon
 * align="center"|26
 * Kvyat
 * rowspan=2|Mercedes
 * align="center"|44
 * Hamilton
 * align="center"|77
 * Bottas
 * rowspan=2|Williams
 * align="center"|63
 * Russell
 * align="center"|88
 * Kubica
 * }
 * The table is not sorting sequentially. It is sorting the table by team based on the lowest number used by the team. This was introduced because while it is possible to sort the table sequentially, doing so breaks up every multi-row cell (such as the "team" cell in the above example) and creates a duplicate of those cells for each driver. However, if you then try to re-sort the table by constructor, those multi-row cells do not merge back together (it's not possible); the only way to restore the original format is to refresh the page.
 * I believe that while this is a nuisance to the reader at best, it does not fundamentally break the table; everything is still readable. In order to wind up in this situation, the reader has to go through a specific set of actions and while inconvenient, it also has a simple solution. I also have my doubts as to how frequently this problem occurs; I don't think many readers would use the sort function in the first place, and of those who do, I doubt it is a long-term issue for them. To my mind, this is the lesser evil than having the sort function act in a way that the reader does not expect. Mclarenfan17 (talk) 04:55, 24 February 2019 (UTC)
 * This is not really a WP:RFC issue, it's better suited to WP:VPT. Anyway, with the table at the time that this thread was started, what you have in the last two columns ("No." and "Driver name") is not pairs of rows but single rows containing line breaks in the form of  tags. The line breaks do not create new rows, they create the illusion of separate rows. Aside from the sorting problem, this creates a accessibility issue. As far as the sorting javascript is concerned, the values to be sorted are based on the attributes such as   found at the start of each cell. If you want each driver to be listed in individual rows so that you can sort them numerically (or alphabetically), you need to explicitly mark them up as individual rows (this also fixes the accessibility issue). Something like this:
 * align="center"|26
 * Kvyat
 * rowspan=2|Mercedes
 * align="center"|44
 * Hamilton
 * align="center"|77
 * Bottas
 * rowspan=2|Williams
 * align="center"|63
 * Russell
 * align="center"|88
 * Kubica
 * }
 * The table is not sorting sequentially. It is sorting the table by team based on the lowest number used by the team. This was introduced because while it is possible to sort the table sequentially, doing so breaks up every multi-row cell (such as the "team" cell in the above example) and creates a duplicate of those cells for each driver. However, if you then try to re-sort the table by constructor, those multi-row cells do not merge back together (it's not possible); the only way to restore the original format is to refresh the page.
 * I believe that while this is a nuisance to the reader at best, it does not fundamentally break the table; everything is still readable. In order to wind up in this situation, the reader has to go through a specific set of actions and while inconvenient, it also has a simple solution. I also have my doubts as to how frequently this problem occurs; I don't think many readers would use the sort function in the first place, and of those who do, I doubt it is a long-term issue for them. To my mind, this is the lesser evil than having the sort function act in a way that the reader does not expect. Mclarenfan17 (talk) 04:55, 24 February 2019 (UTC)
 * This is not really a WP:RFC issue, it's better suited to WP:VPT. Anyway, with the table at the time that this thread was started, what you have in the last two columns ("No." and "Driver name") is not pairs of rows but single rows containing line breaks in the form of  tags. The line breaks do not create new rows, they create the illusion of separate rows. Aside from the sorting problem, this creates a accessibility issue. As far as the sorting javascript is concerned, the values to be sorted are based on the attributes such as   found at the start of each cell. If you want each driver to be listed in individual rows so that you can sort them numerically (or alphabetically), you need to explicitly mark them up as individual rows (this also fixes the accessibility issue). Something like this:
 * }
 * The table is not sorting sequentially. It is sorting the table by team based on the lowest number used by the team. This was introduced because while it is possible to sort the table sequentially, doing so breaks up every multi-row cell (such as the "team" cell in the above example) and creates a duplicate of those cells for each driver. However, if you then try to re-sort the table by constructor, those multi-row cells do not merge back together (it's not possible); the only way to restore the original format is to refresh the page.
 * I believe that while this is a nuisance to the reader at best, it does not fundamentally break the table; everything is still readable. In order to wind up in this situation, the reader has to go through a specific set of actions and while inconvenient, it also has a simple solution. I also have my doubts as to how frequently this problem occurs; I don't think many readers would use the sort function in the first place, and of those who do, I doubt it is a long-term issue for them. To my mind, this is the lesser evil than having the sort function act in a way that the reader does not expect. Mclarenfan17 (talk) 04:55, 24 February 2019 (UTC)
 * This is not really a WP:RFC issue, it's better suited to WP:VPT. Anyway, with the table at the time that this thread was started, what you have in the last two columns ("No." and "Driver name") is not pairs of rows but single rows containing line breaks in the form of  tags. The line breaks do not create new rows, they create the illusion of separate rows. Aside from the sorting problem, this creates a accessibility issue. As far as the sorting javascript is concerned, the values to be sorted are based on the attributes such as   found at the start of each cell. If you want each driver to be listed in individual rows so that you can sort them numerically (or alphabetically), you need to explicitly mark them up as individual rows (this also fixes the accessibility issue). Something like this:
 * This is not really a WP:RFC issue, it's better suited to WP:VPT. Anyway, with the table at the time that this thread was started, what you have in the last two columns ("No." and "Driver name") is not pairs of rows but single rows containing line breaks in the form of  tags. The line breaks do not create new rows, they create the illusion of separate rows. Aside from the sorting problem, this creates a accessibility issue. As far as the sorting javascript is concerned, the values to be sorted are based on the attributes such as   found at the start of each cell. If you want each driver to be listed in individual rows so that you can sort them numerically (or alphabetically), you need to explicitly mark them up as individual rows (this also fixes the accessibility issue). Something like this:


 * I've only given three teams, in order to demonstrate the concept briefly. Notice that the  and   attributes are no longer necessary for the "No." column. We can also eliminate the   attribute for the "Driver name" column, I don't understand why it was present to begin with. -- Red rose64 &#x1f339; (talk) 16:05, 24 February 2019 (UTC)
 * Thank you but we're not asking a technical question. We are aware of this solution. The problem many of us have is that sorting by number or driver under this scenario splits the rowspans, which cannot be fixed without refreshing the page. The question being posed is whether or not sorting by numbers is a useful enough feature to add given that it breaks the rowspans. Wicka wicka (talk) 16:27, 24 February 2019 (UTC)
 * Redrose64, this WikiProject is well aware of the situation on how the sorting technics works. We had a large discussion five years ago, and we decided that rows being split when clicking on the sort button is something we do not want. The table as it is in the article, per the format used since that discussion. We consciously designed the table so that sorting can be used without that splitting occurring. That's why these parameters are present and warranted. We also decided to make columns where sorting is just not valuable unsortable, to keep things clear. We've used that format for five years without any complaint about sorting from any reader. I thus strongly disagree with the OP's claim as to what readers expect. I really feel they're proposing a solution looking for a problem here.Tvx1 16:28, 24 February 2019 (UTC)
 * To me this is the crux of the disagreement. We decided long ago how to format these tables and they have served us well since then, without complaint. Yet these editors are asserting, entirely without evidence, that users expect something different. I just feel like we need an actual reason to make a change, and I haven't seen even one. Wicka wicka (talk) 19:02, 24 February 2019 (UTC)
 * I've never accepted "we've always done it that way" as a particularly valid argument. It's too restrictive because it limits what can be done, especially since the current article winds up being indebted to other articles.
 * The objections to changing the sorting markup is based on one thing: the inability to merge cells back together once separated. It's a purely cosmetic argument. Mclarenfan17 (talk) 08:19, 26 February 2019 (UTC)
 * No it's not, it's an accessibility a readability argument. The duplication of cells makes the information more difficult to read because there's an increased volume of content to parse and it also renders sorting of other columns, e.g. power unit, less usable, because there is a mess of duplicated information.Tvx1 13:36, 26 February 2019 (UTC)
 * Tvx1, it's the opposite. Use of rowspans and breaks ("  ") in the current table data are bad practice for accessibility. Removal of these, thus providing a simple table - which can be fully sortable too - is best practice for accessibility (as intimated by  above). See MOS:ACCESS and WP:DTABTUT. -- DeFacto (talk). 13:59, 26 February 2019 (UTC)
 * Firstly, there are rowspans in the current table. Secondly, WP:DTABTUT does not mention the "  " parameter at all, so I don't know why you mention that. Thirdly, while MOS:ACCESS does mention it, I don't think its use here create a problem here. It is not used to emulate a row that isn't reflected in the HTML table structure. There's still one row per team and they are correctly identified in the headers. Moreover, I have tested it with a screen reader and it works just fine.Tvx1 14:40, 26 February 2019 (UTC)
 * Yes, I know there are [no?] rowspans in the current table, but there are in the first proposal for a replacement. WP:DTABTUT tells of the problem with rowspans. I'm pointing out that neither tables with "  " or rowspans are desirable, and that fully formed cells for each item of data give the best all-round solution - full sortability and accessibilty compliancy. -- DeFacto (talk). 14:50, 26 February 2019 (UTC)
 * Based on what? Wicka wicka (talk) 14:57, 26 February 2019 (UTC)
 * No. As explained countless of times fully separate rows for each item of data does NOT create the most efficient form of sortability. A number of columns are negatively affected because more, most unnecessary duplicated, information needs to be parsed. Moreover the accessibility issue you speak does not exist. While the usage of  could create such an issue, testing has proven that it doesn't in this case. MOS:ACCESS does not forbid the usage of   . I'm beginning to understand you do not fully understand that guideline. When things work properly, they work.Tvx1 18:33, 26 February 2019 (UTC)
 * I did not expect my suggestion to be rejected out of hand with comments like "we are aware of this solution" and "this WikiProject is well aware of the situation on how the sorting technics works". Somebody here opened an RfC by adding a tag, which has broadcast this discussion far and wide: an RfC is an open invitation for anybody to weigh in, not just the regulars for WikiProject Formula One.
 * Anyway, there are clearly at least two conflicting opinions on what it means for a table to be accessible, so I've dropped a note at Wikipedia talk:WikiProject Accessibility. -- Red rose64 &#x1f339; (talk) 19:20, 26 February 2019 (UTC)
 * We were just trying to explain that your example was already proposed and did not solve the problem. No one was suggesting that your comments aren't welcome. Wicka wicka (talk) 20:22, 26 February 2019 (UTC)
 * , not all problems are solvable. Try putting this in Excel and have all data in individual cells with rowspans and do data sort or graphing operations on them. It's simply not possible. Here you have to pick between accessible information, a 'pretty table' and column sort-ability and you can have at most 2 out of 3. I'd advise proper table cells for the drivers and marking the driver columns as unsortable. Then fight the eternal fight with people who will want to make those columns sortable and who don't care about the visual sorting glitch. But at least it will be accessible no matter what you choose between in terms of column sort-ability. —Th e DJ (talk • contribs) 21:26, 26 February 2019 (UTC)
 * I absolutely agree. This is the fight I have been fighting for weeks. Wicka wicka (talk) 22:54, 26 February 2019 (UTC)
 * I will also point out that the table is not complete yet. An important column will be added once the entries for the first round are announced. The column which shows which drivers entered which round. And experience from the previous years told us that the format currently in use is the most efficient to display the proper chronology of entries, especially once replacement drivers come into the mix.Tvx1 02:28, 27 February 2019 (UTC)
 * As a screen reader user, I agree with TheDJ here. Graham 87 05:43, 27 February 2019 (UTC)
 * , I'm confused here. I've actually tested this table with a screenreader and I cannot identify problem (Well actually I did notice one slight inconvenience which I have fixed since), so I really cannot understand what problem you would confronted with.Tvx1 12:52, 27 February 2019 (UTC)
 * It's the line breaks in the cells, as noted above. Not too bad with only two items, but separate columns would still be better. Also, abbr isn't enabled by default in most screen readers, so it's effectively useless. — Preceding unsigned comment added by Graham87 (talk • contribs) 13:28 27 February 2019 (UTC)
 * Seperate columns?? How would you suggest we implement that? As said before, I have tested the present table with a screen reader and it works just fine, with regards to conveying each's formatted row's information. I really can't see the problem. As for the abbr. I added that, because I was looking for a way to provide alternate text for the abbreviation "No.", as that was misread by my screenreader as the negation "no". So how should I format this properly then?Tvx1 13:31, 28 February 2019 (UTC)
 * Hi, to help me understand the accessibility issue, can you clarify a couple of your points please. 1) Why do you think it is it better to use rowspans rather than duplicated row data for the team data that is common between the team's drivers - given that it removes the possibility of tidy sorting by car number or driver name? 2) What do you mean when you say "proper table cells for the drivers" - are you saying do not use  to force a break in a single cell? Thanks. -- DeFacto (talk). 07:21, 27 February 2019 (UTC)
 * TheDJ and Graham87 are referring to MOS:DTAB, the paragraph beginning Avoid using tags in adjacent cells to emulate a visual row. I should have linked this in my post of 16:05, 24 February 2019 (UTC). Please note, and its near-exact equivalent  are not "parameters", they are [//www.w3.org/TR/html5/text-level-semantics.html#the-br-element HTML tags] that are supported in Wiki markup. -- Red rose64 &#x1f339; (talk) 21:33, 27 February 2019 (UTC)
 * thanks for that clarification. Are you able to, equally eloquently, explain the accessibility objection (assuming there is one) to eliminating the rowspans, and simply having one full row per driver (i.e. two rows per constructor, one for each driver). That would produce a simple grid table, albeit with the constructor details duplicated for each of their drivers, but each column would then be truly sortable. --- DeFacto (talk). 22:02, 27 February 2019 (UTC)
 * As far as I know there is no accessibility problem if that is done as you have just described. -- Red rose64 &#x1f339; (talk) 00:28, 28 February 2019 (UTC)
 * Yes, Redrose64, again we were aware of the potential for an issue. You should notice the suggestive, rather than imperative, language use in that quote. Moreover, I already addressed that in my previous replies. I did test it with a screen reader and it works just fine. There is a link further in that paragraph of the guideline which shows clear examples of when this creates a problem. Examples which clearly differ from this particular case. The examples show what I already pointed out is not being done here: "using tags in adjacent cells to emulate a visual row". The examples shows clearly what this action describe. One row in the code being used to emulate two full rows visible in the article, thus also including 's in the headers. That's no the case at all in our table. Our table has one row coded which also show one row in the visible table. It's just that two cells per row have more than one entry. But because each row and each column has  just one clearly identified header, the screen readers handle that perfectly. The accessibility issue just does not exist in this table. I really don't understand how I can make this any clearer.Tvx1 13:31, 28 February 2019 (UTC)
 * Here is the first row of the table as it presently stands:  Now, are you seriously telling me that there are no  in that? -- Red rose64 &#x1f339; (talk) 12:29, 2 March 2019 (UTC)
 * No, I’m not and I haven’t done so as far as I’m aware. Did you even read my comments?? I’ve carefully explained that while the are there, they do not create an accessibility issue in this table. They don’t create a problem for screen readers to handle this table. These  don‘t actually emulate full seperate rows, but merely seperate multiple data points which are all connected to one same row and column header. As said before, I have tested it with a screan reader and it works fine. In any case, this is not dependant of the sortability being discussed.Tvx1 13:58, 2 March 2019 (UTC)
 * Yes you have, and it's right there on this page - you wrote I already pointed out is not being done here: "using tags in adjacent cells to emulate a visual row". I have just pointed out that is exactly what is being done there. Do not take me for a fool. -- Red rose64 &#x1f339; (talk) 20:54, 2 March 2019 (UTC)
 * Please read other people’s comments more carefully and please don’t act so condescending. I didn’t write that we don’t “use tags in adjacent cells". I wrote that we don’t "use  tags in adjacent cells to emulate a visual row". The latter part is key. We use  tags in this table, but not in a way that creates an accessibility issue. I’ve tested it and I’ve explained it multiple times. I’m not going to keep repeating myself.Tvx1 23:08, 2 March 2019 (UTC)
 * This code  makes two cells on a single row. The two  tags give the impression to sighted readers of there being two rows. To a screen reader user, there is no association between the number 7 and the name Kimi Räikkönen that also excludes from that association the number 99 and the name Antonio Giovinazzi - it puts the two numbers together, and the two names together. This is what MOS:DTAB is all about, so it is an accessibility issue, and if there is any more of this denial and I shall post at WT:ACCESS again. -- Red rose64 &#x1f339; (talk) 10:58, 3 March 2019 (UTC)
 * It's not. I have tested it in a screen reader and it works. These numbers and names are not only related to one another. They are also carried by the teams and more precisely the cars. While they are two data points stacked vertically in some cells they still belong to one and the same row. They are connected to one and the same header. These headers are the likes of "Ferrari", "McLaren-Renault", "Red Bull Racing-Honda" etc. And do you really believe that people who are read out something like "Alfo Romeo Racing, Number: 7, 99, Driver name: Kimi Räikkönen, Antonio Giovinazzi" do no have the remote intelligence to immediately work out that information? In any case, the imperfection is not caused by the sortability question at hand but rather by the contested information being in separate columns. Maybe merging them is better as that would directly connect the numbers with the drivers. And threatening to call in the MOS:DTAB cavalry isn't showing much signs of respect. You're really making a mountain out of a molehill here.Tvx1 11:50, 3 March 2019 (UTC)
 * , I think the reason is so passionate about using line breaks is because of seasons like 2017, in which there were so many driver changes that one three teams had three drivers and one team had six. It becomes far easier to maintain the table if you can just add a new line instead of a new cell and new rowspans. I suppose merging them is a good possible compromise. Wicka wicka (talk) 13:41, 4 March 2019 (UTC)
 * I don't think anyone suggested duplicate rows is an accessibility problem, it's just completely unnecessary. It duplicates most of the table and adds a ton of clutter in service of solving a problem that doesn't exist. Wicka wicka (talk) 15:30, 28 February 2019 (UTC)
 * As Wicka Wicka says, it's mostly a readability problem.Tvx1 15:46, 28 February 2019 (UTC)
 * Duplication is quite normal in sortable tables, it keeps the content clear regardless of column sort order. However, duplication of team data could be reduced if we split this ungainly table into two separate tables - one with a row per team for team details and one with a row per driver for driver details including team. That would seem to me to be the most elegant solution here. -- DeFacto (talk). 16:08, 28 February 2019 (UTC)
 * You have an incredibly flawed understanding of the word "elegant." It's baffling that you continue to suggest duplicating rows and duplicating tables in order to solve a problem that, again, you cannot even prove exists. Wicka wicka (talk) 16:36, 28 February 2019 (UTC)
 * see this edit by : ... it's an accessibility argument. -- DeFacto (talk). 16:01, 28 February 2019 (UTC)
 * That's just a question of language. I meant accessibility as in how good the text is accessible to our eyes, not necessarily as in "per Wikipedia's MOS:ACCESS". I guess I should have used the word "readability". Fixed now.Tvx1 18:19, 28 February 2019 (UTC)
 * The issue is an accessibility issue, but fortunately in this case, not a great one. The crux of the matter is that (leaving aside links) a screen reader will read "Alfa Romeo Racing"; "Alfa Romeo Racing-Ferrari"; "C38"; "Ferrari 064"; "7, 99"; "Kimi Räikkönen, Antonio Giovinazzi". As long as we can assume that the reader will be able to work out that 7 goes with Kimi Räikkönen, and 99 goes with Antonio Giovinazzi, then it's not a practical problem for this table. You can see, of course, how that would soon become a serious problem if the number of drivers per team were greater, or if more pieces of information were given about each driver. One of the main objections to these mild breaches of accessibility is that they give others the impression that it's okay to use tags in more complex cases where it definitely will pose significant problems for screen readers. The old excuse of "they did it so why can't we?" gets trotted out so regularly to justify editors' personal preferences. --RexxS (talk) 20:08, 3 March 2019 (UTC)

Point for fastest lap
Sky Sports is reporting that the driver who sets the fastest lap in a race will be awarded a championship point, as long as he finishes tenth or higher. This subject to final approval but expected to be in place by the Australian GP. Suggest it is not added to the article until final approval is given. Mjroots (talk) 16:31, 8 March 2019 (UTC)
 * BBC reporting the same but I agree, until it's official it should not be included. SSSB (talk) 18:06, 8 March 2019 (UTC)
 * Wooo! Back to 1959! -- Red rose64 &#x1f339; (talk) 22:58, 8 March 2019 (UTC)
 * Wikipedia is meant to predominantly rely on secondary sources, so waiting for an "official" primary source is usually unnecessary. -- Scjessey (talk) 14:12, 10 March 2019 (UTC)
 * But we are not waiting for a primary source, we are waiting for it to be concrete, currently it is a proposal, there is no guarantee that it will actually happen. SSSB (talk) 15:42, 10 March 2019 (UTC)
 * shaGuar F1''' 19:56, 11 March 2019 (UTC)
 * Again it has not been confirmed, it is still under discussion. SSSB (talk) 20:51, 11 March 2019 (UTC) Now it has. SSSB (talk) 20:54, 11 March 2019 (UTC)

In the event that two drivers set an identical fastest lap time...
Well? No points? Half-points? Point to whoever got it first? Admanny (talk) 23:37, 11 March 2019 (UTC)
 * Pretty sure it will be whoever set it first. That's what happens in qualifying. There was one race where first three on the grid set an identical time in qualifying. Mjroots (talk) 06:31, 12 March 2019 (UTC)
 * In the 1950s they split the point. Although as they were only timing to the nearest second, there was a race where 7 people got 1/7 of a point for fastest lap. But I guess they'll half it, as they half points for incomplete races. Joseph2302 (talk) 07:24, 12 March 2019 (UTC)
 * We will find out if and when it happens, until then its not really important. SSSB (talk) 08:04, 12 March 2019 (UTC)

New official 2019 entry list
FIA has already updated the official entry list on 28 February 2019. The "Team Name" for Ferrari will be only "Scuderia Ferrari" without the new sponsor Mission Winnow.--79.52.96.245 (talk) 15:59, 28 February 2019 (UTC)
 * ✅.Tvx1 18:26, 28 February 2019 (UTC)
 * Thanks! I've already done it for Italian Wikipedia :)--79.52.96.245 (talk) 18:57, 28 February 2019 (UTC)

Based on this new list, perhaps the entry list table should be redesigned to delineate between "company name" and "team name" instead of the more generic "constructor" we currently have? Also, it's high time we abandoned this farce of not having the Swiss flag next to the Alfa Romeo entry, since the entrant is "Sauber Motorsport AG" based emphatically in Switzerland. -- Scjessey (talk) 14:10, 10 March 2019 (UTC)
 * Mercedes-Benz Grand Prix Limited. Red Bull Racing Limited. Renault Sport Racing Limited. Where are these corporations based and what flag do they fly under? Wicka wicka (talk) 17:30, 11 March 2019 (UTC)
 * According https://www.formula1.com/en/teams.html they're entered under the Swiss flag. 2A02:A210:A001:A380:8D42:54BE:7076:E786 (talk) 18:04, 11 March 2019 (UTC)
 * It's not fully updated yet. SSSB (talk) 18:20, 11 March 2019 (UTC)
 * the flag isn't based on the country where the team is registered and located, it's based on the nationality of the licence they choose to race under. Otherwise, as is alluding to above, Mercedes, Red Bull and Renault would have to race under British flags, being all based and rooted in the UK. -- DeFacto (talk). 19:12, 11 March 2019 (UTC)
 * Right, okay. We have no sources to suggest it will be anything other than Switzerland, which it has been for years and years. If we are waiting for confirmation, all the flags should be set to "unknown", right? -- Scjessey (talk) 19:43, 11 March 2019 (UTC)
 * the big difference between what's happened to Sauber and all the others though, is that Sauber has changed its constructor name to one that was Italian last time was used, so an increased level of doubt has been introduced. I agree though that each flag needs a reference validating its use in the article for the 2019 season. -- DeFacto (talk). 19:58, 11 March 2019 (UTC)
 * Why is https://www.formula1.com/en/teams.html not a reliable source? As to the difference between the racing license and the base: that link shows the German flag for Mercedes and shows the base (after clicking on the team) as Brackley UK and so the link does disambiguate between the two. 2A02:A210:A001:A380:8D42:54BE:7076:E786 (talk) 22:08, 11 March 2019 (UTC)
 * Because it still lists the team named "Sauber". We know that's not correct. It clearly has not been properly updated yet, even with the first race just days away.Tvx1 18:40, 13 March 2019 (UTC)
 * Teams and constructors are not necessarily synonymous. We've forgotten this because since 1981, each constructor has not been allowed to supply more than one team in one season. But even since that restriction came in, teams like HRT Formula 1 Team, Larrousse and Scuderia Italia have bought their chassis from constructors such as Dallara or Lola - and Lola have supplied more than one team (in different seasons). Go back before 1981, say to 1975, and it was much more complicated - with constructors like Lotus, McLaren and March supplying several teams simultaneously; or teams like Embassy Hill and Penske Racing using cars from more than one constructor - in the same races. No, team is what counts - constructor has nothing to do with it. -- Red rose64 &#x1f339; (talk) 21:57, 12 March 2019 (UTC)
 * The modern regulations define a constructor as the company that owns the IP to a car design, not who literally constructs the car. Dallara is not a "constructor" in the context of HRT or Haas, they are simply an outsourced partner. Wicka wicka (talk) 15:45, 13 March 2019 (UTC)

Defining a race
The article should define what a Grand Prix is for the following reasons:

1) "other articles do something different" is not an argument; if we only ever do what other articles do, then we are writing this article to meet the needs of other articles first 2) the reader shouldn't have to read another article to understand this one 3) this article is about the entire championship, not just the changes Mclarenfan17 (talk) 07:27, 17 March 2019 (UTC)


 * ''1) All season articles must be standardized."
 * Please direct me to the Wikipedia policy that says that. I'll save you the time and tell you that there is no such policy.
 * ''"2) Oh really? Then why YOU removed note about point for fastest lap cause its "already written somewhere else"."
 * Yes, it is already addressed under the "regulation changes" section of this article.
 * ''"I, as a reader, looked at the points system table and didnt understand that only top 10 finisher gets point."
 * Then perhaps you should read the entire article first.
 * "4) This is related to race regulations, not calendar. Calendar is only calendar, not race procedure."
 * And you don't think the length of a race is relevant to the calendar, especially considering that not sll races are the same length? Mclarenfan17 (talk) 07:57, 17 March 2019 (UTC)
 * I have one question to you. Why it's always you who do things to make articles worse and sometimes even unreadable (like that table without flags, cause now you need to look the whole table to find driver instead of immidiatelly finding e.g. Mexican flag for Sergio Perez)? Alex (talk) —Preceding undated comment added 08:10, 17 March 2019 (UTC)
 * It's not unreadable. Those flagicons actually make the article less readable because they interrupt the natural pattern that the eye follows in the English language (left to right, top to bottom).
 * It's not unreadable. Those flagicons actually make the article less readable because they interrupt the natural pattern that the eye follows in the English language (left to right, top to bottom).


 * Now, would you please answer my questions? Mclarenfan17 (talk) 08:15, 17 March 2019 (UTC)
 * 1) It's common sense (which you seems not to have) that all season articles (not only F1) must follow the same standarts of writing from season to season. 2) It doesnt matter if it's adressed in another section. Reader doesnt have to read whole article to find this info. ALSO it's included in changes section, so its only related to current season. But this info will also be nessecary in 2020, 2021... articles so the note should be in every + info about that in changes section only for 2019 article. 4) If you think it's that that nessesary maybe include distance in table for every race like in wrc? But if seriously, this info is not that necessary to reader. If it was, it would be included somewhere in main part of article. Still not in calendar.And as for flags, it became COMPLETELY unreadable without them. I actually dont care about etry list (but i see zero point in including it cause its not WRC and it will be the same for almost every race in season), but flags near drivers in results table must be there. It can take up to 5 seconds to find driver you need, and with flags it always takes 1-2 sec at max. Also if flags wont be necessary, there wouldnt be any flags in official F1 graphics. But they are there cause it's better for viever. Also you haven't answered why you intention is always to make something unreadable? Alex (talk) 08:54, 17 March 2019 (UTC)
 * I agree that we should include the top ten fastest lap clause in the season standings section, not everyone will read the entire article, I know that I certainly don't when I look back at past seasons, as for the rest of the problems discussed her I agree with Mclarenfan17, if we can make things better we should and the removeal of flagicons everywhere does not reduce readability. SSSB (talk) 09:19, 17 March 2019 (UTC)
 * ''"It's common sense (which you seems not to have) that all season articles (not only F1) must follow the same standarts of writing from season to season."
 * No, common sense says that they should be similar. If they are identical, we could never change the format year on year to take into account rule changes.
 * ''"Reader doesnt have to read whole article to find this info."
 * That's what you do with encyclopaedia articles.
 * ''"But this info will also be nessecary in 2020, 2021... articles so the note should be in every + info about that in changes section only for 2019 article."
 * There is no reason why we cannot have prose in the 2019 article and notes in subsequent articles.
 * ''"If you think it's that that nessesary maybe include distance in table for every race like in wrc?"
 * Ask me again when Grands Prix are run to different lengths on different surfaces over a different number of stages like the WRC. Until then, stop making stupid arguments.
 * ''"flags near drivers in results table must be there."
 * Not according to WP:MOSFLAG. Mclarenfan17 (talk) 09:25, 17 March 2019 (UTC)
 * 1) Why you could never change the format? You can. But then you should change every previous article in accordance to the new one. It's usually not done just because people are lazy, but it still doesnt mean that old articles should remain the same. 2) Then you can just go to another article to find that info about 305 km. 3) That note should be either in every article when point for fastest lap is awarded or not present in any of them. 4)By the way, about surfaces. I think it was you who removed colours from WRC articles that indicated surface type, or i am mistaken? Cause, as i said, it's usually you who try to make everything less readable. 5) "They are useful in articles about international sporting events, to show the representative nationality of players (which may differ from their legal nationality"). Alex (talk) 09:39, 17 March 2019 (UTC)


 * Changing the format on one article does not make you obliged to change the format on any other article, each article is an independent entry on wikipeida, consistency in a choice not an obligation, I agree flagicons are useful in the articles but they only need to be shown once in the entry table, nowhere else. SSSB (talk) 09:45, 17 March 2019 (UTC)
 * Using flagicons only once is also not an obligation. As i told, remove them from entry table and it will be only in results tables then. Results table is much more necessary (or you dont agree?) then entry table. Also i have no idea why you even decided to add that entry list table, which will be just copied from article to article with no changes (unlike WRC). Alex (talk) 09:50, 17 March 2019 (UTC)
 * I know there is no obligation for them to be there just once, but putting flagicons everywhere is unnecessary and it actually makes the tables less readable as suggested in WP:MOSFLAG, why mention Hamilton's (or any other drivers) nationallity 3-4 times when once will do, extra flagicons serve no purpose. The entry table was discussed at length at the talk page and there was a consensus for its addition. SSSB (talk) 09:58, 17 March 2019 (UTC)
 * Cause it's faster to find Hamilon in the table when you see British flag. You wont need to look at all driver names to find him. Will just need to look at British drivers. I agree that maybe there is not much purpose in including flags everywhere in the articles about championships where all drivers are from the same country, but in world championsip its a need to include flags in results tables. They serve the purpose of extra visual representation of a driver. And about concensus, it's already 4vs2 in favour of keeping flags. Alex (talk) 10:20, 17 March 2019 (UTC)
 * Firstly, this discussion is 1v2 (alex95-ukraine vs me and Mclarenfan17), if you want to know Hamilton's result go to the entry table, find him (its got the british flag so you should manage) and looks at the results table, its not that hard. SSSB (talk) 10:31, 17 March 2019 (UTC)

Let's not get too carried away here. We're supposed to be discussing the issue of defining a race. The question of flags is for another talk page.

Alex9501, we're willing to hear you out, but right now you come across as very aggressive. You have avoided answering the questions asked of you by others and the arguments you have presented so far amount to "because I say so". Mclarenfan17 (talk) 10:44, 17 March 2019 (UTC)
 * 1) It doesnt matter how much people present in this discussion. Others showed their opinion somewhere else or by their edits. This is enough. 2) I dont know what more to discuss here. I've written arguments for both topics but i see only "this is irrelevant cause i said that" and "we two think that flags shoudlnt be there so they wont be there" in reply. Even despite article, which one of you (or maybe both) linked, states that flags are usefull to represent nationality. As for questions, actually it's you who ignored a few of my questions like that question about wrc and at lest one other. As for defining a race there is nothing more to say. Its calendar section, not race regulations. Its been like currently for years and you changed that without consensus just because you wanted to. Alex (talk) 11:15, 17 March 2019 (UTC)


 * WP:EDITCONSENSUS applies. The definition of a race was added and when nobody objected, it was accepted as a consensus. Then you came along and claimed it had to be removed, because other, similar articles don't do it, which is WP:ALLORNOTHING and not an argument since other, similar articles do do it. Mclarenfan17 (talk) 06:35, 18 March 2019 (UTC)
 * I sympathize with the effort to avoid having to force readers to navigate between articles, but I think you're being over concerned there. We can't possible have every piece of jargon combined with a full explanation. Specific terms are adressen during GA and FA nominations and every time we are reminded that we have a perfect vessel to deal with this. Our Glossary of motorsport terms. So I really believe the full explanation of a grand prix is undue here.Tvx1 01:54, 19 March 2019 (UTC)

Fastest lap indicator
I feel like there should be some sort of indication next to the finishing position of the drivers that get the fastest lap in the World Driver's/Constructors' Championship Standings. I was thinking a star would be good so, for instance, Bottas' Melbourne race result would look like: 1*

And then in the template notes you could just say: "* - Driver received 1 world championship point for the fastest lap of the race." This way, at a glace, people could know which drivers got which fastest laps. Ya feel me? — Preceding unsigned comment added by Ethanmeister (talk • contribs) 17:03, 17 March 2019 (UTC)

, we already have an indicator for the driver who got fastest lap, italics. SSSB (talk) 17:09, 17 March 2019 (UTC)


 * @ &mdash; but that indicates who set the fastest lap regardless of who now gets the bonus point. I think that what @ is proposing is a way of indicating who got the bonus point, if anyone did. Mclarenfan17 (talk) 06:37, 18 March 2019 (UTC)
 * , we tried to do that with the note in the table that shows points distribution stating that "the point for fastest lap will only be awarded if the driver finishes in the top ten", but you wanted to remove it because it was already mentioned in the article, the idea being the note together with the italics it is clear whether or not the point is awarded. SSSB (talk) 08:04, 18 March 2019 (UTC)
 * That's in a separate table. We're talking about the results matrix. Mclarenfan17 (talk) 09:26, 18 March 2019 (UTC)
 * I know what we are talking about, but the results table shows the results not the point allocation, the point allocation belongs in that separate table I talked about. Therefore we should put the note stating the fastest lap point requirement in that table and that matched with the italics in the results table then shows who if anyone got the point for fastest lap. SSSB (talk) 10:21, 18 March 2019 (UTC)
 * I had been thinking about these indicators as well. However as this affects all articles with such results tables, I will raise this at WT:F1.Tvx1 01:57, 19 March 2019 (UTC)

A † is already used to indicate a retired driver that was classified, why not use ƒ or something to indicate fastest lap in the same way?

Tyres
I would find it interesting to know which tyres were provided by the tyre manufacturer for each race. For the avoidance of doubt, I don't mean the tyres chosen or used by each driver, I expect that would be too much detail. — Preceding unsigned comment added by Pylgrim (talk • contribs) 07:33, 28 May 2019 (UTC)


 * Hi, firstly I think this kind of inclusion is best suited to individual race reports. I also happen to know that we actually do  have that kind of information available at 2019 Australian Grand Prix and that it was included in several race reports pre 2019. Personally I would be against such an addition as knowing which tyres from the c1-c5 range doesn't have any bearing on the race report (the only reason they were there before was to specify that soft would be hardest tyre at some races however this is no longer a concern). I would therefore consider the inclusion of such information redundant and bordering on violating of WP:NOSTATS. Than again I am only one editor and if others if the consensus is for such information to be included I won't push to hard against it. SSSB (talk) 08:19, 28 May 2019 (UTC)
 * I always included this information in the race articles I brought to GA for 2015 and 2016. I agree that these articles are where the information should be. Unfortunately, the race articles do not get much attention anymore these days. I am too busy with other stuff to do them (I am also quite bored by F1 at the moment, if I'm perfectly honest...). Zwerg Nase (talk) 08:47, 28 May 2019 (UTC)

Does a Formula One race have to happen or weekend to start before the race's page is created?
I am new here and I joined after noticing that links to the races which have not yet taken place link back to this page. Is that the usual practice? Are race pages added only after the Grand Prix weekend has started? I believe there is plenty of useful information that can be provided prior to the race starting.

KenyanJake (talk) 09:42, 29 May 2019 (UTC)KenyanJake
 * , we tend to unredirect when the official entry list for the Grand Prix is realesed (will be found here for Canada). This is usually the Thursday before the weekend. Sometimes we may do this earlier if there is sufficent information available about the event (i.e. other than it will take place and some drivers and teams are expected to take part) Hope this helps, SSSB (talk) 12:27, 29 May 2019 (UTC)


 * Why though? This seems arbitrary and heterogenous with the rest of Wikipedia. There is plenty of information that could be stored in this page. Why redirect if people want specifically to navigate to the page? — Preceding unsigned comment added by Striker161 (talk • contribs) 21:57, 3 June 2019 (UTC)
 * , plenty of information such as what. I certainly can't think of much. Wikipedia's Notability policy on events would suggest that at this point articles on the 2019 Canadian Grand Prix and Grands Prix thereafter should not be created as anything more than redirects as there isn't any news on the event other than it is scheduled to happen happen. If you disagree with me on this you are of course welcome to be bold and create articles on future Grands Prix however at this stage there really isn't any information specific to the 2019 Canadian Grand Prix (which is appropriate for an encylopedia) to create an article only info which shouldn't be on an encylopedia (such as start times) or info which is/should be on different pages (such as 2019 Formula One World Championship, 2018 Formula One World Championship, Circuit Gilles Villeneuve or Canadian Grand Prix). On a seperate note please take care with your indentations, I will fix the one above for you. SSSB (talk) 07:47, 4 June 2019 (UTC)

Mission Winnow
Please don't edit war over the use (or lack thereof) of the "Mission Winnow" sponsorship. As Mclarenfan17 said, the note is by far the better solution because it doesn't uglify the table. -- Scjessey (talk) 12:31, 11 June 2019 (UTC)

Also, where is it written that because we did it in 2011, we have to do it in 2019? The change in entrant name literally has no bearing on the article&mdash;unlike Force India/Racing Point in 2018. The 2011-style markup is complex and unnecessary and if anything, there is more value in changing the 2011 article to adopt the 2019 markup than there is in changing the 2019 article to adopt the 2011 markup. Mclarenfan17 (talk) 12:41, 11 June 2019 (UTC)

I agree with and. It looks nicer and is simpler if we use the name they entered the season as and we include a footnote explaining that at some events they used a different name. This is by far the most elegant and simple solution that has been presented, really I fail to see the problem with it. SSSB (talk) 08:11, 12 June 2019 (UTC)

@ &mdash; really now? You're actually making demands about the order edits should be made in? You know that's not how Wikipedia works. Mclarenfan17 (talk) 09:12, 12 June 2019 (UTC)

I have been thinking about this as well. I can understand the point of having both entrant names in the table on seperate lines. But the issues arise from the way some want to tie the flag to both names simultaneously. I think the manner uses is clumsy (it is out of alignment with the other entries in that column) and it also has technical issues. The problem is that in this way, the flag is only visually tied to both names, but not technically. As a result a number of readers are negatively affected when trying to read the table. I do understand the argument for having both names, but in absence of on other solution I'd be tempted to just duplicate the flag. That way it functions both visually and technically. On a side note, I think Renault in is better precedent. That also involves a sponsor change.Tvx1 09:54, 12 June 2019 (UTC)


 * The footnote method works just fine. The decision to run under two entrant names has no greater impact on the article than the single column of the table. Mclarenfan17 (talk) 10:40, 12 June 2019 (UTC)
 * That doesn't mean that no other solution can be found that isn't even more satisfying. I think Admanny latest version is a reasonable compromise, but by all means we can discuss this further.Tvx1 10:44, 12 June 2019 (UTC)


 * They used a variation on their formal entry name for three races. The entrant column is the only place in the article where that name appears. The note is a more appropriate place to address the discrepancy than any other solution. Mclarenfan17 (talk) 10:53, 12 June 2019 (UTC)


 * What part of do not edit-war about this did you not understand? Your latest revert was not needed. We could have discussed this further without it. It's clear that some users do think it's needed to make the different entrant names more visible. I don't have a strong preference myself either way, but can I see the arguments either way. The most important thing for me is that it's technically sound.Tvx1 11:25, 12 June 2019 (UTC)


 * Indeed. Edit warring is bad. Once I began this thread, there should have been zero changes to the material in question until a solution had been worked out here. -- Scjessey (talk) 13:32, 12 June 2019 (UTC)

And yet, only one person involved was dragged to ANI. As per WP:EDITWAR:
 * ''"An edit war only arises if the situation develops into a series of back-and-forth reverts."

You don't need three edits in 24 hours to be in an edit war. So why weren't the others involved in an edit war referred to the admins? My money is on "because they didn't disagree with one particular editor" despite the fact they still have not participated in this discussion even with multiple pings.
 * ''"What part of do not edit-war about this did you not understand?"

If I had to guess, I'd say it's the same part that you don't understand. This edit of yours clearly meets the definition of "a series of back-and-forth edits" since it was the second time you imposed it on the article and you were already aware of this discussion when you made it. Mclarenfan17 (talk) 03:33, 13 June 2019 (UTC)
 * I am hatnoting the above because it is completely irrelevant for this discussion, take this to user talk pages. Further, Mclarenfan17, you were not taken to ANI for edit warring, you were taken to AN3 for breaking the 3 revert rule, this has been pointed out several times, please take notice. SSSB (talk) 07:06, 13 June 2019 (UTC)

Since we were drifting off-topic, I'm going to try to get back on track with this. The issue is how to provide the different entrant name used by Ferrari in the entry list. This what we currently have: started to change that to this per a 2011 precedent: Later Admanny tried this compromise, but it was reverted as well:

The middle option I listed is definitely a no-go because it's clumsy with the alignment out of whack with the other rows and with it only functioning visually but the not properly technically. The bottom way seems like a good compromise which works both visually and technically, but some editors seem not keen on that either. Of course, it should be possible to find other suggestions. I hope that we can finally agree on whether or not we need to change from the existing format and if so how should present it.Tvx1 10:44, 13 June 2019 (UTC)


 * Option 1 - I find options 2 and 3 completly unnecessary espically given 's only arguement is this is how we did it previously. I fail to see the benefit of the proposed changes. Personally though I prefer option 2 over 3. If we include both names then they should have equal prominance. If it doesn't work technically can you please expalin how, it seems allright to me, your earlier complaints about it being out of whack, I diasgree, I think it looks fine better than option 3. SSSB (talk) 13:03, 13 June 2019 (UTC)
 * Take a look at how it looks . It's out of alignment with the rest of the entries in that column. As for the technical issues, because the flag spanning two rows is only generated visually it isn't parsed properly as being connected to both "rows" and some readers, e.g. those using assistive technology, are not properly conveyed the content to.Tvx1 16:54, 13 June 2019 (UTC)
 * it's out of alignment. Only just. If that your main opposition, in my opinion that's just you being difficult and wanting to make things look pretty unnecessarily. As for your second problem couldn't we just use the flagicon for the first one and then insert a break before inputting the second one (like option 4 but without the redundant flag). SSSB (talk) 17:20, 13 June 2019 (UTC)
 * That would amount to option 3, wouldn't it?Tvx1 09:57, 14 June 2019 (UTC)
 * No l, option 3 has the sec0nd name as small, this is unnecessary besides that is my third preference after keeping as is and option 5. SSSB (talk) 10:25, 14 June 2019 (UTC)

SSSB (talk) 17:34, 13 June 2019 (UTC)
 * Option 1 - leave it as it is. No change necessary. Double stacking is ugly and unnecessary, given the perfectly serviceable note. -- Scjessey (talk) 15:23, 13 June 2019 (UTC)
 * Comment - Of course another option which I mentioned in my first comment in this section is to just duplicate the flag.Tvx1 17:02, 13 June 2019 (UTC)
 * Comment - adding another flagicon would be a clear violation of MOS:FLAG, it is completely obvious. Personally if we can't go for option 1 I suggest the following (option 5):
 * Yeah, that works too. Anything that is a single line is likely to get my support. -- Scjessey (talk) 18:31, 13 June 2019 (UTC)

Standings
How do u edit the standings? JamesVilla44 (talk) 17:54, 30 June 2019 (UTC)

Rich Energy
Watch out for "News" editors, Rich Energy appear to have dropped Haas and no doubt someone will edit the team name any second even though we don't know what it might end up being Duds 2k (talk) 17:43, 10 July 2019 (UTC)


 * For now it's probably most reasonable to assume that it is "Haas F1 Team" because a) that's the name they have always used and b) the team was "Rich Energy Haas F1 Team" until this weekend. Given that Silverstone is round 9 of 21, they will spend the majority of the season without Rich Energy backing, so the best way to represent it in the article is "Haas F1 Team" with a note. Mclarenfan17 (talk) 06:53, 11 July 2019 (UTC)

the above discussion may have specifically discussed Ferrari however I fail to see why you don't think it applies to Haas, I see very little difference between the 2. They both are participating in some races with a title sponser and some without. Whether or not they compete with a sponser again is not relevent. Please justify why you think this article should employ double standards. SSSB (talk) 11:00, 11 July 2019 (UTC)
 * Haas is just like Renault in 2009. ING ended their sponsorship, and thus the plain "Renault F1 Team" is now on a separate line. I don't see why not the same applies for Haas. Ferrari still has a sponsorship with Mission Winnow and are alternating between the two, so I can understand why some people want to keep Mission Winnow on a single line. But Rich Energy is gone, so we'll have to see until the entry list is released what their new entry name is; but for now I agree with Mclarenfan17 that it's safe to assume it would be "Haas F1 Team". Admanny (talk) 11:09, 11 July 2019 (UTC)
 * But as has been explained to you before articles don't need to be consistent with each other and consensus can change. Further it is important that articles are consistent with them selves. By having two lines for Haas but one for Ferrari the article is inconsistent with itself. As there has been consensus for Ferrari to appear on one line with a footnote for the article to be consistent with itself Haas must also appear on one line with a similar footnote. In short what appears on the 2009 page doesn't and shouldn't impact how it should appear here. SSSB (talk) 11:50, 11 July 2019 (UTC)


 * ''"Haas is just like Renault in 2009. ING ended their sponsorship, and thus the plain "Renault F1 Team" is now on a separate line. I don't see why not the same applies for Haas. Ferrari still has a sponsorship with Mission Winnow and are alternating between the two, so I can understand why some people want to keep Mission Winnow on a single line. But Rich Energy is gone"
 * That's a distinction without a difference. It would take a lot of prose detailing that for the reader, all of which would do very little (if anything) to enhance the reader's understanding of the article. Mclarenfan17 (talk) 12:04, 11 July 2019 (UTC)


 * Currently, Haas appears to still consider Rich Energy to be their sponsor, so perhaps Wikipedia should avoid jumping the gun until the name change is actually made official: https://twitter.com/HaasF1Team/status/1149234399982100481 - 129.215.90.68 (talk) 14:33, 11 July 2019 (UTC)


 * Apparently, the contract termination tweet was false. Rich Energy has rebutted it. And frankly, it should have been glaringly obvious. The part that claimed them intending to beat Red Bull Racing should have raised the flags straight away. Also note that the allegedly "official" Rich Energy twitter account does not sport the icon asserting it to be a confirmed official account. Another lesson for these journalists of Autosport and the likes to think twice, or even thrice, about using twitter as a source.Tvx1 15:49, 11 July 2019 (UTC)


 * ''"perhaps Wikipedia should avoid jumping the gun until the name change is actually made official"
 * Based on all of the available information, the termination of the contract was a reasonable conclusion to make at the time. It has since been proven incorrect, but that does not mean that the article was misleading or outright wrong. You know as well as anyone else that what is true on Wikipedia is what we can prove, and at the time we could prove that there was a statement announcing the contract had been terminated.
 * ''"And frankly, it should have been glaringly obvious."
 * Which would have required us to speculate.
 * ''"Another lesson for these journalists of Autosport and the likes to think twice, or even thrice, about using twitter as a source."
 * Then that's Autosport's mistake, not ours. Mclarenfan17 (talk) 22:47, 11 July 2019 (UTC)

Championship standings table has only been partially updated
It's listing the results for GBR but the total points haven't been updated yet. 82.73.236.185 (talk) 15:32, 14 July 2019 (UTC)
 * It's been updated now. Thanks. DH85868993 (talk) 10:30, 15 July 2019 (UTC)

German Grand Prix
There is currently no 2019 German Grand Prix page and we are only 4 days away from the race itself. Could someone create a 2019 German Grand Prix page? JamesVilla44 (talk) 09:47, 24 July 2019 (UTC)

Constructor's Championship standings
Not all the standings in the Constructor's Championship board are correct. Someone had better edit them so that everything is synched with the Driver's Championship board. 85.211.72.172 (talk) 17:04, 28 July 2019 (UTC)
 * ✅: The standings are in separate templates from the article. Bbb2007 (talk) 17:17, 28 July 2019 (UTC)

There's been no visual change at all. The "Constructor's" board is still not synched with the "Driver's" board. 85.211.72.172 (talk) 06:41, 29 July 2019 (UTC)


 * I've just had a quick look and everything looks correct. I think where you might be getting confused is that in the constructors table we sort each teams results with the best result first followed by the worse result. It doesn't work on the basis of one row per driver. Thanks, SSSB (talk) 16:55, 29 July 2019 (UTC)

Removing centimetres as units of measurement
You removed centimetres from my contribution about technical regulation changes for this season. I do not object to including inches as they are helpful for American readers, but for most people in the rest of the world centimetres are a more intuitive unit of measurements than millimetres, as 1 cm is already pretty small (2.54 times smaller than an inch). I included both with the handy template Convert, mainly because the regulations are written in millimetres, then you, instead of simply adding inches, removed centimetres. Can we agree to include all three of them? — Preceding unsigned comment added by Bobi.1 (talk • contribs) 12:03, 8 August 2019 (UTC)


 * I used mm because that is what the regulations use and also other Formula One articles. I added inches for those who use imperial measurements. I removed cm because any use who knows what mm will understand cm and vice versa. I don't mind if we use cm or mm and we have no obligation to use one or the other, I don't care which one we use but to use both is just silly in my opinion. It just feels like we are including units for no reason other than we can. It is common knowledge among metric users that 1 cm is 10 times bigger than 1 mm, knowing what a front wing is or a rear wing is more obscure knowledge amongst metric users than cm to mm conversion. Remember we dont have to use mm because the regs do and we dont have to use mm because other similiar articles do as the articles are written to be read independent of each other and Wikipedia is independent from the FIA. So to conclude you can replace mm with cm if you wish but please refrain from including both. Thanks, SSSB (talk) 12:49, 8 August 2019 (UTC)
 * Honestly, I think the measurements should always be given in millimetres and inches. I've never seen any form of technical papers written with centimetres. I think the reader will expect millimetres and it would be peculiar if with did anything else. -- Scjessey (talk) 13:00, 8 August 2019 (UTC)
 * I disagree, we are not a technical report, so we don't need to follow the precision of one. cm and mm are both suitable here. SSSB (talk) 13:17, 8 August 2019 (UTC)
 * We don't need to be deliberately different either. If our readers generally encounter millimeters and inches in the reliable sources on this subject than it makes sense to keep our articles in balance with them.Tvx1 14:15, 8 August 2019 (UTC)
 * Like I said I'm not particularly fussed, I'm just pointing out we have no obligation to follow any given system. SSSB (talk) 14:38, 8 August 2019 (UTC)


 * I agree that this article is not a technical report but aimed towards fans who read it to get an overview of the changes without having to read the FIA documents. so we should not blindly copy the regulations. Even Formula 1 technical regulations used centimetres for most measurements over 2 cm until 2000, and I guess it was only changed in early 2000s because some team tried to argue 'if it is given in centimetres, and our wing rounds down to the nearest centimetre, it should be legal'. For example, in one version of the regulations there is the number 40000mm², which would make no sense to put in an article instead of 400cm² or 4dm². And while mental maths in metric is not hard, it is best to use the most suitable unit of measurement. Bobi.1 15:33, 8 August 2019 (UTC)
 * It's true that this article is not technical report, but that doesn't mean we are prohibited from using millimeters. Using that subdivision is not synonymous with "blindly copying the regulations". The most logical thing to do remains keeping our articles in balance with the sources for this and using sub-units that our readers generally encounter in the general sources (like this one) as well, per WP:ASTONISH.Tvx1 12:10, 9 August 2019 (UTC)
 * I think the current version is ok. Millimetres with inches between brackets is the most logical way to me and echoes the units used in the sources. The convert template was primarily designed to be used to easily display equivalent units from different measuring systems (e.g. Metre vs Miles or °C vs °F), not really to display different divisions of the same unit of the same measuring system. Moreover inches and centimetres are not each others proper equivalent. The imperial equivalent of centimetres would be feet.Tvx1 13:04, 8 August 2019 (UTC)
 * Metres and Miles are not equivalent, Km and Miles are. Just because they are the same number of steps up from the smallest unit doesn't make them equivilant. We should use common sense when determining which units should go together. Anything between 1cm and a 1m could easily use either cm or mm with inches. Using feet would just be weird with anything less than 1 foot and illogical when you can use inches ( approx. 12 inches in a foot.) SSSB (talk) 13:14, 8 August 2019 (UTC)
 * Yes, you're right. I meant to write metres and yards.Tvx1 14:07, 8 August 2019 (UTC)
 * I support millimetres as the primary unit as they are the common unit in automotive engineering, and a convert into inches for those in many parts of the English speaking world who prefer British imperial or US customary units. -- DeFacto (talk). 20:29, 8 August 2019 (UTC)
 * That is exactly my thoughts also. -- Scjessey (talk) 11:02, 9 August 2019 (UTC)