Jump to content

Wikipedia talk:WikiProject Tropical cyclones

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Did you know

Articles for deletion

  • 28 Oct 2025 – Meteorological history of Typhoon Rai (talk · edit · hist) AfDed by 4meter4 (t · c) was closed as merge by Left guide (t · c) on 04 Nov 2025; see discussion (9 participants)

Good article nominees

(1 more...)

Featured list removal candidates

Good article reassessments

Requested moves

Articles to be merged

WikiProject
Tropical Cyclones

WikiProject home (talk)
Archives: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8
| 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16
| 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24
| 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32
| 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40
| 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48
| 49 | 50

Task forces

→ Western Pacific task force (talk)
→ Eastern Pacific task force (talk)
→ Atlantic task force (talk)
→ North Indian Ocean task force (talk)
→ Southern Hemisphere task force (talk)
→ Graphics task force (talk)
→ 2018 FT task force (talk)
→ Weather of YYYY task force (talk)
Newsletter (talk)
Archives: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8
| 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16
| 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24
| 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32
| 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40
| 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48
Project resources (talk)
Jargon (talk)
WikiProject statistics (talk)
Article requests (talk)
Cyclone Cup (talk)
Vital articles (talk)
Showcase (talk)
Style guidelines (talk)
Awards (talk)

Assessment

Main assessment page (talk)
→ Assessment tables (talk)
→ Assessment log (talk)
→ Assessment statistics (talk)

Tropical cyclones portal

Parent project

WikiProject Weather (talk)

Project notes

[edit]

I just created this wikiproject, after several months of contemplating doing so. I hope everyone working on hurricane articles will get involved. I went ahead and wrote a bunch of guidelines, basically based on current practices...naturally since this is something I just wrote it doesn't necessarily represent community consensus and needs to be discussed. That discussion should probably go here for now...although eventually we may make these pages a little more structured. For a general TODO list, see the "tasks" item on the project page. Jdorje 23:17, 5 October 2005 (UTC)[reply]

FARC for Effects of Hurricane Isabel in Delaware

[edit]

I have nominated Effects of Hurricane Isabel in Delaware for a featured article review here. Please join the discussion on whether this article meets the featured article criteria. Articles are typically reviewed for two weeks. If substantial concerns are not addressed during the review period, the article will be moved to the Featured Article Removal Candidates list for a further period, where editors may declare "Keep" or "Delist" in regards to the article's featured status. The instructions for the review process are here.

Proposal: add the yearly Weather of YYYY and Tropical cyclones in YYYY to the button bars

[edit]

Per a recent discussion, I realized that a lot of storm articles link articles like Weather of 2025 and Tropical cyclones in 2025, since they wouldn't be directly linked elsewhere in the article. I propose that these sorts of articles get added to the Template:Hurricane season bar, to be added alongside the timeline. The button bars appear in thousands of articles, so if this gets approved, someone technical is going to have to implement it to make sure nothing gets broken. Parts of the template allow for "List of storms" and "Statistics", which were types of article that used to exist (as in the 2005 Atlantic hurricane season) but have since been merged. I believe both of these attributes should be changed and replaced with weather by year (which has individual yearly articles going back to 2000) and tropical cyclones by year (which has yearly articles going back to 1991). ♫ Hurricanehink (talk) 21:22, 12 October 2025 (UTC)[reply]

MOS:SANDWICH issues with most tropical cyclone articles - move track map to the infobox?

[edit]

Jpuxfrd (talk · contribs) recently published Tropical Storm Alvin (2025). Like most articles, it has an infobox with an image in the top-right, and then a track map on the left side in the met history section (which is usually the first main section of the article). As part of the article approval process, the user was reminded that the text shouldn't be squeezed, but that's pretty much the default for most tropical cyclone articles. MOS:SANDWICH clearly says "a­void sand­wich­ing text be­tween two im­ages hor­i­zon­tally op­po­site each other; or be­tween an im­age and an in­fo­box, nav­i­ga­tion tem­plate, or sim­i­lar."

The easiest solution is to ignore the MOS, which is what the project has been doing since the policy was established. The more proper solution would be a more permanent fix. What about moving the track map to the infobox? That is along the lines of what already happens in the season sections, and, incidentally, on the French Wikipedia. Some articles might have to have their images moved around, but there is always the option for a gallery if there are a lot of images available (but no space). I noticed a recent back-and-forth on Hurricane Hazel, which incidentally is also about image placement and sandwiching, so it's something we all need to be more aware of. Any thoughts? ♫ Hurricanehink (talk) 18:30, 17 October 2025 (UTC)[reply]

I'd support merge into infobox. It'd fulfill similar role to mapframes or pushpin maps in like place infoboxes. grapesurgeon (seefooddiet) (talk) 19:05, 17 October 2025 (UTC)[reply]
Strong oppose as the current issue seems to be coming from users shoving too many other images into the Met history. In fact, in most cases that would actually make the sandwiching worse as a good chunk of storms don’t have long enough leads and white space becomes another issue as well. Users just need to limit the amount of images they insert into the MH and use the clear template when appropriate and not write short summaries in there as well. I see absolutely no reason to change it. MarioProtIV (talk/contribs) 20:01, 17 October 2025 (UTC)[reply]
@MarioProtIV: the problem is the sandwiching that exists in every article except the ones with at least three paragraphs of met history. I picked Hurricane Francelia at random, and there is sandwiching. The problem isn't the number of images in the met history, it's that so many articles have sandwiching in the first place, which goes against the MOS. ♫ Hurricanehink (talk) 20:04, 17 October 2025 (UTC)[reply]
I still concur the proposal would make things worse. And why is it only now suddenly an issue? Since the start of the project I can’t seem to recall any instance where there were complaints. This just seems to be an arbitrary issue that’s arisen from MH’s that are written too short, which if that is the case, questions whether the storm can fit into the season page (unless the impacts are significant). And if there were impacts some of the are needlessly bloated (and not too significant) where it can easily be trimmed down. MarioProtIV (talk/contribs) 20:15, 17 October 2025 (UTC)[reply]
Can we get like a mockup of how this would look? That follows the current infobox style and not the French one? I'm not a rules guy or anything but if it looks better than the current way we do things I think we should do it. Side note, I might point out that whether Francelia and other pages have sandwiching depends on which style of page you use. I only ever use the vector legacy, but the sandwiching doesn't seem to be there as much on the newer style. MCRPY22 (talk) 20:19, 17 October 2025 (UTC)[reply]
Here you go for Francelia - looks like it's already an option to also add the track. Here is what Alvin looks like. ♫ Hurricanehink (talk) 20:38, 17 October 2025 (UTC)[reply]
I still don’t like that idea and the fact it makes both images smaller isn’t really a positive - there was a whole discussion on collage infoboxes for TCs and the general thought there before it went silent it seems was it’s moreso a negative and the infobox image should always be of the cyclone itself. I still believe this issue has mostly come from short summaries of MH, in which that case can be expanded upon which isn’t a negative, since it doesn’t hurt to detail it more to newer readers who may not have as much as an understanding on tropical cyclones like we do. The storm path template allows the size of the image to be modified, which is basically an alternative to this without introducing new problems, IMO. MarioProtIV (talk/contribs) 20:45, 17 October 2025 (UTC)[reply]
But it would basically be what it's like in the sections for season articles, having them side by side. If users want to see a larger image of the storm, they can always click on it. And there can always be a gallery of satellite images, such as what appears in Hurricane Alex (2016). The problem isn't about MH summaries being short or not. It's the sandwiching that happens in a ton of articles. As for collages, I'm still not sure about them, but having the satellite image and track map next to each other looks right to me, since it's not overcrowding the beginning of the article. ♫ Hurricanehink (talk) 21:53, 17 October 2025 (UTC)[reply]
Yeah I gotta disagree here, having the image and track map right next to each other looks pretty bad to me. Also we gotta put the legend for the track map somewhere. The french version with the track at the bottom was ok, but not having them side-by-side like that. MCRPY22 (talk) 22:14, 17 October 2025 (UTC)[reply]
The season page does it like that because we can’t squeeze the track in the storm’s section, of which there are multiple. When a storm has its own page, the infobox (and WP:WPTC/IMG as well) agree on a satellite image for the main image, because we can write a whole lot more about that storm in its own page rather then make the season section way too long or big. The French wiki’s idea would not bode well here because of whitespace issues, particularly for those using the vector legacy skin (like I do). Even so, those with shorter leads on the newer skin might also have whitespace issues with track images attached at the bottom of the infobox. As we’ve practically have WP:IAR for this for the last 15-20 years, no big complaints have come about saying “oh we must conform to this” and many of the FA/GAs in this topic have not addressed the track image placement as a problem (IMO, one of the biggest reasons not to change anything). If it ain't broke, don't fix it. I understand change can be good, but I believe in this case, we’re creating a problem out of what boils down to a style recommendation, not an explicit rule. I don’t have problems with collages further down the article like Alex 2016, I was moreso referring to the main image someone sees when they first open the page. MarioProtIV (talk/contribs) 22:40, 17 October 2025 (UTC)[reply]
Looks broke to me...I would be for better ways to mitigate this. I think several ways to display the track would add flexibility. I'm thinking along the lines on how NRHP can be incorporated into Template:Infobox building as an extension. – The Grid (talk) 01:00, 18 October 2025 (UTC)[reply]
On a solely template-related note, the track map being put next to the satellite image is a hold out from {{Infobox tropical cyclone small}}, which I originally planned to also replace with {{Infobox weather event}} before realizing that the smaller infobox was already compliant with existing infobox standards. It's trivial to add another sub-box to the weather event infobox for the track map; one just has to decide where it's supposed to go. Chlod (say hi!) 02:31, 18 October 2025 (UTC)[reply]
I feel like the fact that it makes the infobox wider just moves the sandwiching issues. Personally, I do not find that the meteorological history is cramped by the track and infobox. I feel like this is a case where we politely ignore a policy as it would just complicate matters with little or no improvement. ✶Quxyz✶ (talk) 21:02, 18 October 2025 (UTC)[reply]
And why is it only now suddenly an issue? Since the start of the project I can’t seem to recall any instance where there were complaints. This isn't a strong argument. Plenty of bad practices that stick around for a long time, doesn't make it less bad grapesurgeon (seefooddiet) (talk) 23:34, 17 October 2025 (UTC)[reply]
  • Netural - I think moving the trackmap into the infobox might remove some of the wowness of certain TC pictures and make the infobox cramped, but that could be a good thing as it might solve some of the silly edits that we have all seen over which image should go into the infobox.Jason Rees (talk) 23:31, 17 October 2025 (UTC)[reply]
Oppose: this would clutter the infobox. The image would be harder to understand since the legend would be missing. A better solution is to expande the lead when possible. When done right, it eliminates the issue completely. If expansion doesn't completely eliminate the issue, Template:Clear can be used at the end of short leads. There will be whitespace but the actual content isn't affected. Columbia719 (talk) 00:01, 18 October 2025 (UTC)[reply]
The clear template will need to be applied on numerous articles to fix the sandwiching then. grapesurgeon (seefooddiet) (talk) 01:05, 18 October 2025 (UTC)[reply]
That's not a problem. Columbia719 (talk) 01:07, 18 October 2025 (UTC)[reply]
Imo it's ugly; I try to basically never use clear. None of my writings use it. Think there's an arbitrary attachment here to an avoidable MOS vio, and the MOS has the guideline for a reason that's being ignored. grapesurgeon (seefooddiet) (talk) 01:11, 18 October 2025 (UTC)[reply]
Can you please provide the line that says MOS discourages the clear template? Columbia719 (talk) 01:14, 18 October 2025 (UTC)[reply]
I don’t think it’s against the MOS having the clear, but I think having the track map in the infobox looks better than too much white space. See Tropical Storm Alvin (2025) which has too much white space on my screen on my home computer, but not when I view it on my smartphone. Hurricanehink mobile (talk) 01:22, 18 October 2025 (UTC)[reply]
Portions of the infobox could be made collapsible instead. The clear template should be used as a last resort. Columbia719 (talk) 01:24, 18 October 2025 (UTC)[reply]
It would need to be unfurled by default though with the option to collapse it though. This is probably the only solution I would support here for fixing sandwiching issues without messing up the look as some have alluded to in regards to the main image. MarioProtIV (talk/contribs) 02:07, 18 October 2025 (UTC)[reply]
Sorry, only the first half of my comment applied to your comment. Clear isn't in MOS, but I think most would agree its use should be a last resort. I went on a tangent by referring to sandwiching being defended by others in this thread. grapesurgeon (seefooddiet) (talk) 01:27, 18 October 2025 (UTC)[reply]

So just to check the temperature of the conversation, what if the infobox had the track map appear below the satellite image, and it was collapsable? I don't have a mockup, as I'm not 100% sure how to code that, but would that be acceptable? It would be in compliance with the MOS, wouldn't shrink the satellite image, and could hide certain portions, including the track map and the legend. ♫ Hurricanehink (talk) 20:17, 18 October 2025 (UTC)[reply]

Still very much not onboard with moving the track map altogether (in your proposal there is still the issue with whitespace even when collapsible), and as Quxyz noted, would not really make things better. A better option without moving the track map (and leaving it as is) because the infobox and the lead is what leads to some sandwiching, we can just make the “overall effects” portion collapsible (and unfurled by default), since aside from the satellite image, that takes up a lot of the space, and this solution might be better as it appeals to both sides, and the collapsible part makes the infobox shorter and allows the lead to wrap around quicker if allowed and not sandwich everything else. MarioProtIV (talk/contribs) 22:18, 18 October 2025 (UTC)[reply]

Example

[edit]
Hurricane Humberto
Track map
Map plotting the storm's track and intensity, according to the Saffir–Simpson scale

  Tropical depression (≤38 mph, ≤62 km/h)
  Tropical storm (39–73 mph, 63–118 km/h)
  Category 1 (74–95 mph, 119–153 km/h)
  Category 2 (96–110 mph, 154–177 km/h)
  Category 3 (111–129 mph, 178–208 km/h)
  Category 4 (130–156 mph, 209–251 km/h)
  Category 5 (≥157 mph, ≥252 km/h)
  Unknown

Storm type
triangle Extratropical cyclone, remnant low, tropical disturbance, or monsoon depression
Category 5 major hurricane
1-minute sustained (SSHWS/NWS)
Highest winds160 mph (260 km/h)
Lowest pressure924 mbar (hPa); 27.29 inHg
Overall effects
Fatalities1 (combined with Hurricane Imelda)
Areas affectedBermuda
Part of the 2025 Atlantic hurricane season

Thanks Chlod (talk · contribs) for this markup for having the track map in the infobox. I should note that collapsing the overall effects won't be enough for a lot of storms, and ignoring the sandwiched text isn't an option. So the main solutions to comply with the MOS are either adopting the track map in the infobox (pictured) or using the clear template any time that there is sandwiched text in the lead. This revision shows what the Alvin article looks like with the track map in the infobox (with the default of the track being collapsable). Any thoughts on this option? ♫ Hurricanehink (talk) 17:06, 24 October 2025 (UTC)[reply]

I feel like it makes the infobox a bit unwieldy and complicated. It also hides the track map, which is among one of the most important things to show with a hurricane, I'd argue even moreso than the satellite image. Also, in the Alvin example, it makes the meteorological history a wall of text with no features. I can only imagine how bad it would be with an even longer meteorological history. ✶Quxyz✶ (talk) 17:11, 24 October 2025 (UTC)[reply]
Would you prefer the track map not being hidden by default? Or is the whole thing a no-go in your opinion? If it's not good, how do you propose dealing with the sandwiched text? ♫ Hurricanehink (talk) 17:17, 24 October 2025 (UTC)[reply]
I am not sure if I have missed anything integral, but just from my experience, I feel like the track map doesn't present a serious sandwiching issue. The examples I have seen on the projectspace are far more egregious and obviously sandwiched. On my screen, over a dozen words can easily fit into the sandwiched space, which is more than I write on per line in notebook paper. ✶Quxyz✶ (talk) 17:22, 24 October 2025 (UTC)[reply]
It's not that a dozen words can fit into the sandwiched space, it's that the MOS says "a­void sand­wich­ing text be­tween two im­ages hor­i­zon­tally op­po­site each other; or be­tween an im­age and an in­fo­box, nav­i­ga­tion tem­plate, or sim­i­lar." The problem is that we've been doing it for years, which doesn't make it right, and the problem was discovered when the Alvin article was published a few weeks ago. That's probably the biggest thing "missing" and why it should be addressed now. I don't think anyone in the project knew it was against the MOS. ♫ Hurricanehink (talk) 17:55, 24 October 2025 (UTC)[reply]
It only was really “discovered” because the MH was written way too short and people have a tendency to cram another image into the section. But then id the MH is too short, that brings up the question of why is the article made, if it can easily fit in a condensed version into the season summary? This still just feels like creating a big issue out of nothing, and the track map is considered an integral part of the MH section. Moving it out would just create a wall of text which would be unflattering to read. The much easier solution is to use the “clear” template. MarioProtIV (talk/contribs) 18:04, 24 October 2025 (UTC)[reply]
I don't think the issue is the MH being short or not. As pointed out elsewhere, this problem happens anytime the lead is less than two paragraphs, at least on my screen. As pointed out earlier, there is still sandwiching in Hurricane Francelia for me. That is three paragraphs, and has a two paragraph lede. You're right that the solution is the clear template, but as you demonstrated on the Barry article, there can be a ton of whitespace by having a clear. I guess it comes down to preference: a wall of text in the infobox, or a bunch of white space after the infobox. ♫ Hurricanehink (talk) 18:13, 24 October 2025 (UTC)[reply]
Agree with Quxyz. I still really don’t like or support moving the track map all together, nor does it really seem like a huge issue like it’s trying to be portrayed as. If anything the collapsable part should be the "Overall effects" portion which seems to be a big contributor to this sandwiching issue. Have it opened by default but able to be collapsed. MarioProtIV (talk/contribs) 17:23, 24 October 2025 (UTC)[reply]
While the overall effects is the largest section (besides the image), I would not say that it prompts sprawling in the infobox. Maybe if the areas effected section has a lot listed, but even then it is debatable. ✶Quxyz✶ (talk) 17:30, 24 October 2025 (UTC)[reply]
I just tested with Alvin by removing the effects section, and even then, and the entire met history is sandwiched on my screen. ♫ Hurricanehink (talk) 17:55, 24 October 2025 (UTC)[reply]
Looks good to me, though I seem to be the only one who thinks so… MCRPY22 (talk) 17:33, 24 October 2025 (UTC)[reply]
I think it looks good. I just feel like it just isn't the best place for the track for my previously stated reasons. ✶Quxyz✶ (talk) 17:42, 24 October 2025 (UTC)[reply]
In my opinion, I think that if the track map were to be added to the infobox, it shouldn't be hidden, and ideally below the satellite image (so both are "full size"). I think an easier solution would be to add template:clear to the impacted articles however. — Iunetalk 19:48, 24 October 2025 (UTC)[reply]
Just an FYI for that make sure you put the TOC text above the template so there's not a huge separation between the two. MarioProtIV (talk/contribs) 19:51, 24 October 2025 (UTC)[reply]
Seeing as this is the easiest solution, should we codify this procedure into project guidelines? Putting the TOC above the clear template? That would fix the MOS issue that brought about this whole discussion. Hurricanehink mobile (talk) 20:30, 24 October 2025 (UTC)[reply]
Yes, I think that would be a good idea. But also leave the exception to not put those in if the lead is exceptionally long for very high impact storms with a long TOC such that it goes beyond the length of the infobox. MarioProtIV (talk/contribs) 21:01, 24 October 2025 (UTC)[reply]
I added this to the project style page. Thanks to all for the input, but it doesn't seem like we need to change things and reinvent the wheel. ♫ Hurricanehink (talk) 00:47, 25 October 2025 (UTC)[reply]

Seasonal summary timeline style

[edit]

Every hurricane season article has a "Seasonal summary" section with a timeline and these are generally very consistent (example). I assumed it was some sort of template, but was surprised to learn that it wasn't (unless it's always being substituted). In particular I was hoping to change the background color from grey to light grey so that the text is more easily readable, but there doesn't seem to be an easy way to change this for all season articles other than doing it manually, and I'm not sure if this would be deviating from some style guide somewhere (although I couldn't find anything about it at Wikipedia:WikiProject Tropical cyclones/Style). So I guess I have two questions: Why isn't the seasonal summary timeline a template? What do people think about making the background color a bit lighter? Nosferattus (talk) 17:30, 30 October 2025 (UTC)[reply]

@Nosferattus: I can’t believe no one thought to turn the timeline into a template. That should be done ASAP. As for the coloring, are there any requirements regarding the MOS with what the color should be? Hurricanehink mobile (talk) 20:54, 30 October 2025 (UTC)[reply]
I don't think the timeline would be able to be templated off because of the way its created, as well as the fact that various seasons will need to be have bigger timelines than other seasons.Jason Rees (talk) 23:59, 30 October 2025 (UTC)[reply]
Perhaps it could be a Lua Module instead. Nosferattus (talk) 01:29, 31 October 2025 (UTC)[reply]
@Nosferattus: Perhaps as i do remember being told something about the software behind it being old and outdated the last time it broke, but I am by no means an expert on templates or computer programing.Jason Rees (talk) 00:25, 1 November 2025 (UTC)[reply]
It looks like you're correct that the timeline tool does not play well with transcluded content (templates and modules). I guess that's why it's never been done. Nosferattus (talk) 01:26, 1 November 2025 (UTC)[reply]
Hurricanehink, the only requirement in the MOS is that the text and background have sufficient contrast, which is what I'm hoping to improve. The current colors are probably acceptable, but I think a lighter grey would make the tiny text stand out more and be easier to read while still being distinct from the page background. I was hoping to change it just slightly from 88% brightness to 92% brightness. Nosferattus (talk) 21:56, 31 October 2025 (UTC)[reply]
I just came back to WP after someone outside WX sent a well-argued email asking me to return. I would have to say, Nosferattus, that any brightening of the background would make some of the color bars indistinguishable from it for those with achromatopsia. Noah, BSBATalk 00:41, 4 November 2025 (UTC)[reply]
I'm afraid your statement is not quite correct. Raising the brightness of the background from 88% to 92% will increase average contrast between the background and the color bars 13%, not decrease it. And the minimum contrast difference will remain constant. If you're worried about achromatopsia, the thing that would make the biggest difference is switching all the color bars to darker colors rather than a mix of dark and light colors. Should I do that as well? Nosferattus (talk) 01:31, 4 November 2025 (UTC)[reply]
The bars have to be distinguishable from each other for intensity reasons, thus the lighter and darker colors. Any graphic using colors to convey data has to have sufficient contrast between the different bars as well as the background. This means each bar needs to be a different monochrome shade and the background cant be the same shade as one of the bars. There's not really a way to change anything without making it worse for someone else. I wouldnt recommend trying to change colors since they are set to be consistent within our templates and track maps, and they took a year and a half of discussion to get. I get what you're saying about increasing contrast between the background and text but I can't support that if a slight improvement there makes things worse for others. Noah, BSBATalk 02:03, 4 November 2025 (UTC)[reply]
I’d rather not rehash the drama over that from three years ago. That is essentially Pandora’s Box and the WikiProject is not in a state to regurgitate this again given many maps still have to be updated. We are not changing the color bars, as that is basically a WP:DEADHORSE. Additionally, I do not see any issue at all how the current contrast looks. Noah explained it better then me, see above. MarioProtIV (talk/contribs) 02:04, 4 November 2025 (UTC)[reply]
Yea just adding on, changing the bar colors is a nonstarter. The colors have been discussed plenty before, for accessibility reasons. Thanks Hurricane Noah for the explanation (and for the unexpected return!) ♫ Hurricanehink (talk) 03:11, 4 November 2025 (UTC)[reply]
While we are talking about the timeline images, it is worth noting that there is a "long term effort" to get the software we use to generate them Extension: Easy Timeline with the Chart Extension.Jason Rees (talk) 23:42, 4 November 2025 (UTC)[reply]
OK, I understand that changing the bar colors would be a bad idea, but I don't really want to do that anyway. I only suggested it as a possible way to improve visibility for those with achromatopsia per Hurricane Noah's concerns. Regardless, my original proposal to just lighten the background color to 92% brightness would also improve legibility and distinguishability for those with achromatopsia as well as for people with normal eyesight. The reason I proposed it is that I have poor eyesight and this would make it easier for me to read the tiny text. Would anyone object to slightly lightening the grey background color? Nosferattus (talk) 19:53, 6 November 2025 (UTC)[reply]
The issue I was raising is that the background as it is now is barely darker than some of the lighter color bars. If you lighten the background more, the colors would blend in for those with achromatopsia. Noah, BSBATalk 19:57, 6 November 2025 (UTC)[reply]

General warning per AN/I thread

[edit]

A recent AN/I thread had consensus to convey the following general warning.

The hard work of WikiProjects Weather and WikiProject Tropical Cyclones in covering weather phenomena is acknowledged and appreciated. However, their members are collectively reminded:

-- Tamzin[cetacean needed] (they|xe|🤷) 20:02, 6 November 2025 (UTC)[reply]

@Tamzin:, thanks for posting this. I think this needs to be a sticky for this talk page, perhaps even at the top page so it won't be archived. I often dislike working on current articles precisely because there tends to be a lot of arguing, people wanting to be the first in publishing an edit/update. I would propose this warning also be posted on the talk page of each active hurricane/typhoon/cyclone season article, since those are typically the hubs of attention during the annual cyclone season, which should draw the most eyes. It's a shame this comes toward the end of the Atlantic hurricane season, but better late than never. ♫ Hurricanehink (talk) 21:32, 6 November 2025 (UTC)[reply]
Update, I've posted this notice on the talk page for every active season article. ♫ Hurricanehink (talk) 20:04, 7 November 2025 (UTC)[reply]
  • This came out of a discussion from an IP vandal applying a different date format? Wouldn't this be a general guidance to all active WikiProjects? What exactly does the above do? Tell us to play nice or be given a slap? I wish I was joking. – The Grid (talk) 23:07, 6 November 2025 (UTC)[reply]
    My guidance is that if your WikiProject (others don't) wants to prescribe a date format, its members should strive to be the first to expand each article past the stub stage. As I said at WT:WPWX, if the IP beats you to it, you can't revert without starting a discussion on the article's talk page.
    The other IP was not a vandal. It's at most disruptive editing. ~2025-31597-25 (talk) 00:25, 7 November 2025 (UTC)[reply]
    This came out of one IP-hopper who was somewhat too intense about date format (but mostly right about it), versus an array of experienced editors who edit-warred to violate MOS:DATETIES and then repeatedly tried to get that IP blocked on false charges of sockpuppetry. (People accusing the IP-hopper of sockpuppetry had 3 weeks in that AN/I thread to provide any evidence they'd ever been blocked for misconduct, and none could.) Hence the reminders about disputes over minor issues, the sockpuppetry exception to edit-warring, and misuse of AIV/RFPP. I don't really have a lot of sympathy for anyone edit-warring about date format, right or wrong, but the important take-away is that it's not something you're allowed to edit-war over, and not something you can throw around aspersions over. I agree that this is something all wikiprojects should keep in mind, but there was consensus (per closer Rosguill) to send this warning to these two wikiprojects since there appeared to be an endemic misunderstanding of policy here. -- Tamzin[cetacean needed] (they|xe|🤷) 07:01, 7 November 2025 (UTC)[reply]
    It sounds like someone deliberately being disruptive and adding gasoline to a scotched earth situation, trying to make a point. The perfect time to transition into temp accounts too. – The Grid (talk) 23:04, 7 November 2025 (UTC)[reply]
I have a more general issue with Wikiprojects and how they don't get enough authority to manage their niche topics. In some areas, I feel like it would be excessive to add to the MOS/guidelines all of the informal policy in WPTC. Also, in some rarer cases (e.g. the sandwiching disussion from earlier), I feel like the Wikipedia-wide policies can harm tropical cyclone articles because it anticipates totally different issues.
That last bit also spirals into another complaint about the guidelines only using obvious examples and neglecting to address some more borderline cases. ✶Quxyz✶ (talk) 10:09, 7 November 2025 (UTC)[reply]
I would like to note after reading the thread (I was not previously involved) that I do understand the policy and some of the reason for global consensus, but I still have worries about either instructional creep on the global side due to the incorporation of WPTC rules there or the global side rules simply being more annoying than helpful. Of course I think WPTC and WPWX needs to be reigned in considering the fact that the WikiProjects has previously opposed several policies relating to accessibility and WP:NOTNEWS based on tradition but I still feel like the WikiProjects should have a reasonable amount of authority and autonomy. ✶Quxyz✶ (talk) 11:30, 7 November 2025 (UTC)[reply]
Wikiprojects are supposed to foster collaboration and provide a place to facilitate that. They are not and never have been meant to manage their specific topics. Global policies exist as something that the entire community decided upon that would be consistent across the site. The fact remains that this warning is too little too late since this is a problem that has been going on for over a decade. Noah, BSBATalk 12:26, 7 November 2025 (UTC)[reply]
Once again, I do understand that they are not supposed to act as policy generators in their current state. More or less, that comment was for me to complain about the current state of Wikipedia's guidelines. Also, if my ideas were to come to fruition, the WikiProjects would still have to largely respect global rules, but could add on their own in cases where the global rules are insufficient or not specific enough, like deciding RS in a specific field or section order in an article. Also, if a policy on a WikiProject were bad, it should just be removed regardless if it conflicts with global consensus. This is all pretty much just me ranting about hypotheticals, but my point is that the global guidelines are not specific enough nor do I believe they should cover every single subject and case possible. ✶Quxyz✶ (talk) 12:39, 7 November 2025 (UTC)[reply]
I could also see these policies becoming subpages to different global policies like the various notability requirements (WP:NASTRO, WP:NWEATHER, WP:NGEO) but that would have to be normalized into wider use. ✶Quxyz✶ (talk) 12:47, 7 November 2025 (UTC)[reply]
To be clear, you can have guidelines that are both global consensus and specific to a topic area. That's why I gave MOS:LDS as an example when I drafted this warning: It's a rather niche style guide, applying to roughly 20k articles, but it nonetheless is a full-fledged global guideline on equal footing with the rest of the MoS. There is nothing stopping WPTC and WPWX from doing a similar thing, if y'all can get consensus from it. -- Tamzin[cetacean needed] (they|xe|🤷) 12:51, 7 November 2025 (UTC)[reply]
I haven't really dabbled much into editing the guidelines, how does one go about adding new ones? ✶Quxyz✶ (talk) 17:55, 7 November 2025 (UTC)[reply]
If one or both of these wikiprojects wanted to get their style guidelines promoted to part of the MoS, I believe the thing to do would be first have an internal discussion about making sure the guidelines are in the most presentable, broader-community-ready state; then probably have a pre-RfC discussion at WT:MoS asking for input from experienced MoS editors; and then finally have an RfC there or at WP:VPP. I'll throw a ping here to WhatamIdoing, who was the one who at AN/I suggested this warning include the link to WP:PROPOSAL, and might have further thoughts. -- Tamzin[cetacean needed] (they|xe|🤷) 18:19, 7 November 2025 (UTC)[reply]
I'm happy to help anyone who wants to make a PROPOSAL. You can also get help at Wikipedia talk:Policies and guidelines, and if you want a MOS page, at Wikipedia talk:Manual of Style.
Just to make the situation clear: The problem with they don't get enough authority to manage their niche topics is that it's not "their" topics. WP:A WikiProject is a group of people who want to work together. It is not a topic area. The group does not WP:OWN the articles or the topic in any way.
It is perfectly 'legal' to have two separate groups of people working on the same areas (see, e.g., Wikipedia:WikiProject First aid and Wikipedia:WikiProject Medicine/Emergency medicine and EMS task force). It's also common for groups to overlap significantly (e.g., Wikipedia:WikiProject Chemicals and Wikipedia:WikiProject Pharmacology, or Wikipedia:WikiProject Military history and Wikipedia:WikiProject History).
Self-selected groups of editors can't have any "authority" over any articles because our structure allows other self-selected editors to appoint themselves a "WikiProject" over the same thing, and if the two groups make opposite "rules", then we have a real mess. (See, e.g., WPCHEM's preference for Template:Chembox and WPPHARM's preference for Template:Drugbox. You can only put one at the top of an article, so which group deserves the "authority" to impose their preference over the other's objections?)
Consequently, the established practice is that anyone/any group can write your advice, and it's treated the same as anybody else's advice. There's no "authority" involved. If you want to make something a community-wide rule, then it needs to be accepted by the community, and the authors have to cede all control over the future contents of that page to the whole community. The process for doing that is outlined in WP:PROPOSAL. WhatamIdoing (talk) 19:05, 7 November 2025 (UTC)[reply]
I partly did not understand that the MOS could have subject specific guidelines. Also, I was envisioning the WikiProjects in a vastly different way compared to how they are now. The WikiProjects would be like different branches off of the whole of Wikipedia to manage each field. The point is somewhat moot though as it should be possible now to do what I wanted, id est, get things decided in policy. Once again, I did not understand that subject specific guidelines were as broad as they are. I was really only aware of the various notability guidelines. ✶Quxyz✶ (talk) 12:17, 8 November 2025 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Tropical_cyclones&oldid=1321063185"