AARoads:The Interchange

From the AARoads Wiki: Read about the road before you go
Jump to navigation Jump to search

Debates about Scope


This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

The vote counts come down to in 5 favor, 3 opposed, 1 neutral. There is consensus to include bridges/tunnels, but there still needs to be criteria defined as to when to include them. --Rschen7754 02:44, 20 January 2024 (EST)

  • I'm torn on this one. The big ones will still have their articles on Wikipedia, so we don't need to decide for a while. Imzadi 1979  14:02, 19 June 2023 (EDT)
  • I think these might fall outside our scope. Dough4872 16:05, 19 June 2023 (EDT)
  • Except for something like wikipedia:Brooklyn–Battery Tunnel where the road is the bridge, I think this is outside our scope. --Rschen7754 19:14, 19 June 2023 (EDT)
    • Something to consider: for that topic, we'd probably write it and title it as the highway designation and only mention the tunnel in a secondary capacity. In other words, we'd have merged it the other way.
  • This question is easier to answer "no" now that tunnels are part of the bridge project on Wikipedia. VC 20:54, 19 June 2023 (EDT)
  • As I've said on Discord, only where it feels like we need them. Golden Gate, Tappan Zee, I-35W collapse. Things of that nature. –Fredddie 21:56, 20 June 2023 (EDT)
    • I'm sure the editing community we'd attract would probably create some of these anyway. I say we revisit the topic later when there's a bit more stability in the rest of the article corpus. Imzadi 1979  23:25, 20 June 2023 (EDT)
  • Yes, but not actively. As long as the Wikipedia article is useful for our needs let's just link to that one, and clone or create articles here as needed when the Wiki-a-holes strike. Moabdave (talk) 14:08, 21 June 2023 (EDT)
  • As needed, as per Moabdave. Scott5114 (talk) 23:51, 21 June 2023 (EDT)
  • Generally agree with Moabdave, most bridge articles seem to be fine on Wikipedia at the moment, but if notability requirements get pushed up higher on enWiki, there might be a need to bring some articles over to AARoads.JJBers (talk) 09:46, 19 September 2023 (EDT)
  • Some bridges and tunnels are important enough to highway coverage that I think we should have articles on them, like we do for other pieces of infrastructure (e.g. interchanges), but I think most of them are out of scope. (So essentially what Fredddie said.) TheCatalyst31 ReactionCreation 00:18, 25 October 2023 (EDT)

City streets

This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

The vote counts come down to 8 in favor, 4 opposed. There is consensus to include city streets, but there still needs to be criteria defined as to when to include them. --Rschen7754 02:46, 20 January 2024 (EST)

  • Not really. There will be some crossover/overlap, but I'd like to stick to roadways with state/provincial highway designations or major county road designations. Imzadi 1979  14:02, 19 June 2023 (EDT)
  • City streets have a different character and fall outside our scope which focuses mostly on numbered highways. Dough4872 16:05, 19 June 2023 (EDT)
  • Outside our scope, but I could see making exceptions for something like wikipedia:Santa Monica Boulevard. --Rschen7754 19:14, 19 June 2023 (EDT)
  • Most city streets are outside of our scope, but I support including principal arterials in this wiki, at minimum as part of a list article. Which level of government maintains the road and whether the road is numbered should not override the importance of a street for serving to move traffic. VC 20:57, 19 June 2023 (EDT)
  • I'll go against the grain here and support having articles on major streets in most cities and even some small towns or rural regions, provided they are identified as important by a higher body/level of government. SounderBruce 02:02, 20 June 2023 (EDT)
  • I'm OK with them to a degree. I think we could have a really good article on Broadway in NYC. But I would enforce a limit of how many streets we should have. 1 article per 50,000 residents is a number that has come up before. –Fredddie 21:56, 20 June 2023 (EDT)
  • Same reasoning as bridges and tunnels. If the wikipedia article is usable for us, use it. If it's not, then we can create our own.Moabdave (talk) 14:10, 21 June 2023 (EDT)
  • No. A comprehensive article on, say, Broadway in New York City is going to cover a lot of ground that, frankly, none of us are interested in or good at writing or researching. Better to leave that to the urbanists. Scott5114 (talk) 23:51, 21 June 2023 (EDT)
  • Massively in favor; the only difference between roads and streets is whether a government's slapped a route number on it. The argument of streets not being important enough is inconsistent- if that were true, we'd have to wipe New Jersey Route 59 from this wiki. Streets in a city are equally as important as roads out in the country. BMACS1002 18:00, 13 August 2023 (EDT)
  • I want to say yes but then we're gonna have to have a real discussion on what constitutes a notable city street. TCN7JM 06:46, 31 August 2023 (EDT)
  • Big yes. Why? At least in Toronto, some very important roads simply have no number because Toronto doesn't use numbered routes. I would argue that Yonge Street in Toronto would be more important than the majority of numbered county roads in the rest of the province. Similarly, Winnipeg has a ton of numbered city routes, but I'd argue that a lot of those are rather insignificant. Andrepoiy (talk) 12:56, 3 October 2023 (EDT)
  • I'm okay with having some streets, especially major arterials that are highways in all but a number designation. I think streets that are more significant for cultural reasons are better suited to Wikipedia, though, and minor streets probably aren't suitable to either place. TheCatalyst31 ReactionCreation 00:21, 25 October 2023 (EDT)

Hyper-specific road hardware and features

Things like "Thrie-beam guardrail", "3M programmable signal head", "Brifen cable barrier", etc.

  • Yes, if we can ensure that the content is in depth enough and not overly commercialized—AARoads may well be the only place on the Internet where some of these things are discussed, and it would be helpful to document what we know as a reference tool. Scott5114 (talk) 23:51, 21 June 2023 (EDT)
  • I think we can cover these features. Dough4872 21:36, 22 June 2023 (EDT)
  • The more I think about this one, the more I think that we don't need articles about these topics. Instead we can work them into general articles about guardrails, traffic lights, and barriers. –Fredddie 20:50, 24 October 2023 (EDT)
  • No. I can't really say that I am a fan about more generic articles like Traffic light either, just because they will not be deleted from enwiki and probably will be left to stagnate here. --Rschen7754 22:35, 24 October 2023 (EDT)
  • Yes, though I think Fredddie's approach of covering these in the general articles makes sense in most cases. I think we can recruit some specialists to the wiki to write about these (for instance, there are a bunch of traffic light fans on the forum). TheCatalyst31 ReactionCreation 00:27, 25 October 2023 (EDT)

Secondary/County/minor highway systems

Note: I have taken the liberty of archiving a couple of dozen short sections that formerly resided here. They were all regarding secondary/minor route systems and should system X have articles, just entries in a list or be excluded from scope. This is not me declaring the decision is final for any individual system. I made this decision at a combined level that these discussions were bloating this page, and all more or less said the same thing. Most of these only had one or two votes summarized as "probably not notable enough for dedicated articles, listical is probably the best option. However, if someone can create a quality article for such a highway, go for it! We don't need the listicles to save articles from the notability police here!" If anyone feels any of these systems needs additional discussion or disagrees my summary statement applies to a specific system, feel free to restore or re-open the discussion for that system. Dave (talk) 01:52, 16 November 2023 (EST)

I strongly disagree with the mass archiving as there was significant discussion and disagreement on several of them. I will begin restoring them shortly. --Rschen7754 03:12, 16 November 2023 (EST)

Alberta secondary (500+)

Note that 900s are future realignments of primary routes

  • 900+ should remain separate. Undecided on the rest. --Rschen7754 01:53, 20 June 2023 (EDT)
    • Leave as standalone for now. Most of the routes are currently handled by table in List of Alberta provincial highways, but they are dozens of miles long. I am uncomfortable with any mass merging action at present. It is possible some could be downgraded to RCS but I'd leave that to a future time. I don't want to start another discussion, but the park access/urban access roads can be left as a table. --Rschen7754 13:50, 2 December 2023 (EST)
  • Tables or RCS for the 500–800 series. Mention the 900s in the article of the related primary route. VC 19:25, 21 June 2023 (EDT)


Manitoba secondary routes
This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

These will be left as standalone. --Rschen7754 00:20, 5 January 2024 (EST)

RCS. The notable ones or ones with a lot of information can be standalone articles. VC 22:02, 21 June 2023 (EDT)

  • Leave as standalone, most are dozens of miles in length and a spotcheck of some earlier this year turned up articles that would have met GNG on Wikipedia. Can be revisited if it doesn't work out. --Rschen7754 16:39, 2 December 2023 (EST)
  • Leave as standalone per Rschen7754. TheCatalyst31 ReactionCreation 00:02, 3 January 2024 (EST)
Winnipeg city routes
This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

The default will be RCS, however more notable ones can remain standalone (to be hashed out in individual discussions). --Rschen7754 01:17, 17 February 2024 (EST)

RCS. The only one that clearly should remain a standalone article is Winnipeg Route 90, which is part of Canada's National Highway System. City routes that are wholly or mostly concurrent with a provincial highway should redirect to the provincial highway article. VC 21:50, 21 June 2023 (EDT)

  • The ones labeled limited access on List of Winnipeg City Routes, or that have limited access portions like Route 42, should remain standalone. For the rest, I think they should go down to listicles - I will point out that a good 1/3 of the RJLs are nonnotable junctions. VC's disclaimer about concurrency should be considered when deciding what to leave standalone. --Rschen7754 16:47, 2 December 2023 (EST)

Missouri secondary state routes

  • A list might be nice, or at the very most an RCS list. Almost all of them are too obscure for a full article, though. Scott5114 (talk) 00:09, 22 June 2023 (EDT)
  • The supplemental road system capstone article is sufficient. There are individual routes that could be notable, such as Route M in Jefferson County and Route D in St. Louis County. VC 21:23, 23 June 2023 (EDT)
  • I agree with VC. I think an RCS list is asking a lot. Like I mentioned in #Iowa spurs, after a while there's only so much you can say. –Fredddie 22:50, 23 June 2023 (EDT)
  • It would be nice to have a table list, but I'm not sure about RCSes outside of the larger urban counties. TheCatalyst31 ReactionCreation 00:42, 25 October 2023 (EDT)
  • Per TC31, however there are a few that are freeways that should remain separate articles. --Rschen7754 12:39, 25 November 2023 (EST)


Nevada urban routes 500-699
This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

These will be done by table unless there is enough for standalone articles. --Rschen7754 14:18, 2 January 2024 (EST)

  • If these roadways are better known by name, then we should title them by name, with disambiguation as necessary. The notable ones should have standalone articles, and the non-notable ones should stay as table entries. VC 21:18, 28 June 2023 (EDT)
  • Per VC but listicle instead of table. --Rschen7754 14:07, 27 November 2023 (EST)
  • The current content policy says articles should be titled alike with others in the same system; we did not import the Use Common Names policy from enwp, given that here all of our articles derive their notability from the system they're a part of. So they should be titled as their SR number rather than their local name (though the latter should of course be a redirect). Otherwise, yes, standalone articles for the interesting ones and everything else can be tableified. —Scott5114 [EXACT CHANGE ONLY] 23:21, 31 December 2023 (EST)
Nevada secondary 700-895
This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

These articles will be in listicles. --Rschen7754 23:26, 12 December 2023 (EST)

Listicle for most, dedicated articles where enough content exists to support one. Moabdave (talk) 14:22, 21 June 2023 (EDT)

  • Per Dave. --Rschen7754 14:07, 27 November 2023 (EST)
Nevada county roads
I think that's too harsh. Most road lists of county routes came from a scraping a government created existing list or map. This was just a more direct scraping than most. However, why re-type such a list if one is already available? IMHO, the only problem with that article is it needs to be more explicit that the table was generated by the Elko County commission, above and beyond a footnote. I did something similar with the table of mountain passes in the route description for U.S. Route 50 in Nevada. I might play with this table to do something similar.Dave (talk) 15:37, 28 November 2023 (EST)
For clarity, my vote is table at most, though I could even say no coverage. --Rschen7754 01:22, 17 February 2024 (EST)

New Brunswick collector routes (>199)

This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

These will be tables, with standalone articles possible for notable ones. --Rschen7754 01:19, 17 February 2024 (EST)

  • Table, with standalone articles for notable routes. We might also consider RCS for the 100s, with standalone articles for notable ones. VC 21:21, 28 June 2023 (EDT)
  • I don't support RCS for the 100s as that would leave us with possibly only 12 standalone articles. Eyeballing Google Maps I'm inclined to leave the 200s+ as they are now, though I will admit that comparisons could be made to the Texas FMs. Most are ~10 miles long. There are no known newspaper archives from the modern era, which doesn't help. --Rschen7754 22:08, 4 December 2023 (EST)
    • Not sure I want to go all the way down to table, but given the comments below I think standalone is excessive, so listicle. --Rschen7754 19:07, 3 February 2024 (EST)
  • Table, with notable ones getting standalone articles. Some of them are unsigned, like New Brunswick Route 270, and I don't think they should be standalone. Hell, the example I mentioned doesn't even have an article. LilianaUwU (talk / contributions) 19:05, 3 February 2024 (EST)


We do expect to cover at least some interchanges, but not every interchange. How do we decide this? Do we come up with our own wikipedia:WP:GNG? --Rschen7754 02:12, 21 June 2023 (EDT)

Yeah, I think interchanges should only be covered if there is significant coverage in multiple sources. Dough4872 07:50, 21 June 2023 (EDT)
Same for bridges and tunnels. If the wikipedia article meets our needs, link to it. Clone or create if not.Moabdave (talk) 14:43, 21 June 2023 (EDT)
Part of me wants to have an article for every system interchange, but maybe pare that back to named system interchanges. –Fredddie 01:17, 22 June 2023 (EDT)
In California almost everything has a name (the list of names is hundreds of pages long), but that doesn't mean they are notable. --Rschen7754 01:46, 25 June 2023 (EDT)
That's why I'd limit it to system interchanges, which are freeway-to-freeway. –Fredddie 18:03, 30 June 2023 (EDT)
There would still be 50 in the LA area alone. --Rschen7754 02:17, 25 October 2023 (EDT)
As long as it has a proper name that is/was in widespread use beyond the DOT offices, I see no reason to not include interchanges. SounderBruce 00:36, 28 June 2023 (EDT)
I'd add that the name should be both enduring and not merely descriptive. Imzadi 1979  05:50, 12 September 2023 (EDT)
  • I think this is a good place for stuff Wikipedia wouldn't cover. Any interchange with a non-generic name generally has decent coverage of its name, we can be more detailed with ramp descriptions since we don't need a book or newspaper describing it. What I will still hold steadfast against is the plethora of what I call "SimCity 4 interchange types"... there's no such thing as a clover stack! - Floydian (talk) 14:43, 30 September 2023 (EDT)
There is such thing as a clover stack. See, for example, I-85 & I-26. Ran4sh (talk) 22:40, 9 November 2023 (EST)

Poll: interchanges

Starting this poll so we can at least get a better sense of what is being included here (and maybe archive this section off the page one day). --Rschen7754 01:26, 17 February 2024 (EST)

Interchanges must be named, and the name must appear in outside sources besides the department or ministry of transportation.
  • Yes. --Rschen7754 01:27, 17 February 2024 (EST)
  • Yes. Dough4872 09:20, 17 February 2024 (EST)
  • Yes. SounderBruce 20:39, 27 February 2024 (EST)
  • No. Named by who? Are colloquial names that got major local press coverage, like the Big X, OK? –Fredddie 00:12, 28 February 2024 (EST)
    • I would be okay with that affirmative clarification. I don't think the El Toro Y is an official name, for example, and I don't think a lot of the California interchanges are either. --Rschen7754 00:37, 28 February 2024 (EST)
There must be more that can be said about the interchange beyond ramp descriptions and content that could belong in the articles about the intersecting roads.
  • Yes. Otherwise we open ourselves up to hundreds of articles that are just descriptions of the map - and for interchanges, that is overkill. --Rschen7754 01:27, 17 February 2024 (EST)
  • Yes. Dough4872 09:20, 17 February 2024 (EST)
  • Yes. SounderBruce 20:39, 27 February 2024 (EST)
  • Yes. This is another reminder that we need to describe why things are important. –Fredddie 00:12, 28 February 2024 (EST)

City-detail articles

Feel this could be controversial, but for some Interstates in large states, perhaps city-detail (or metropolitan-detail) articles could be appropriate. For example, for Interstate 5 in Washington, I had to truncate a lot of Seattle-specific content that could very well fill out its own article (say Interstate 5 in Seattle). Other cities have the luxury of using named freeways to write about city-specific details, but no such luck in other states that never named their freeways. SounderBruce 00:36, 28 June 2023 (EDT)

How did the newspapers refer to the proposed freeway before the proposed freeway was designated I-5? Did they call it something like "Tacoma–Everett Expressway"? VC 15:18, 5 July 2023 (EDT)
I think that in general this is a bad idea, since someone might see that Seattle has city-detail articles (due to overflow content) and try to start something absurd like "Interstate 35 in Ardmore, Oklahoma" or something like that. I feel like the annex would be a great place to hold this kind of overflow content, however. —Scott5114 [EXACT CHANGE ONLY] 20:44, 5 July 2023 (EDT)
I also think this is a bad idea generally for similar reasons as Scott. I could only see this as maybe a major metropolitan area sub article, like maybe an "Interstate 75 in Detroit", but by scope it starts at Flat Rock and runs to Waterford to encompass the suburbs of the Motor City. Maybe. It think we'd get too many minor ones, like someone trying to do "Interstate 75 in Flint", which I'd laugh at while deleting as out of scope. Imzadi 1979  16:22, 6 July 2023 (EDT)
It was simply referred to as the "Seattle Freeway" or "Central Freeway", but that was quickly dropped after completion. Since there's no definitive name (many just call it "the freeway" if not using the number), it's a tough one. SounderBruce 16:32, 6 July 2023 (EDT)
Select cases yes, but to be honest it leaves a bad taste in my mouth to codify it in policy that it's ok. My personal pet peeve is when I invest the time to read or review a roads article and the route description is nothing more than a regurgitation of Google Maps, consisting of endless repetitions of highway x proceeds in <insert cardinal direction here> until it's junction with y. It then turns <insert new cardinal direction here>. I feel like my time has been wasted as I could just pull up Google Maps myself and get the exact same information faster. I fear an explosion of such articles, as if one is describing a short roadway (of say less than 30 miles) that's the type of route description that tends to happen, just because you have the space so fill it. I'm ok with it on a case-by-case basis as we do have some very good "city level" articles, Arroyo Seco Parkway is one. But that's also due to some unique circumstances with that road. So IF we could codify some good criteria that would have to be met before just assuming a city/metro detail article is warrented, I'd be ok with it. But a blanket approval, no. Dave (talk) 11:54, 6 July 2023 (EDT)
I like the idea but as Scott said, how do we prevent Interstate 80 in Walcott, Iowa from happening? Issue special dispensations? Father son and holy moly that's a lot of detail, better split it off. –Fredddie 13:08, 6 July 2023 (EDT)
The jist seems so far seems to be "not opposed but concerned about its misuse". The criteria for state detail articles is sizable spans in 3 states. So there is some precedent to codifying guidelines for sub articles. How about someting like, "Split into city or regional sub articles if and only if the main article is at least a B class article (new scale, so GA in Wikipedia land) and the route description is at least x length of reviewed prose. Would that create the right incentives of yes, but only when the parent article is a quality article and long enough to break out? or is this an enwiki style policy where the cure is worse than the disease? Dave (talk) 13:25, 6 July 2023 (EDT)
We could have a minimum criteria (X population, Y prominence, or being the center city of a top X metropolitan area). I just want to make sure we can have comprehensive coverage of urban highways without it overshadowing the rest of the highway. SounderBruce 16:32, 6 July 2023 (EDT)
Why don't we hash out a list of potential city-detail articles and limit it to those? I think we can toss out any three-digit Interstate right away as well as the two 35E/35W splits since they're essentially already this same idea. I'll start working on a list. –Fredddie 17:35, 6 July 2023 (EDT)
Actually, having looked at it for five minutes, I'm not sure this is the right way. I think a case-by-case basis would be best and I would support Seattle straight away. That being said, we should absolutely look into lists of Interstates in metro areas. These could potentially morph into lists of numbered routes and then location pages that would eventually replace our enwiki bluelinkings. –Fredddie 17:48, 6 July 2023 (EDT)
General question: What kind of size limit do we want on articles? The biggest highway article enwiki is w:Ontario Highway 401 at 215 KB markup size and 48 KB prose size. The biggest Interstate article enwiki is w:Interstate 40 in Tennessee, which is 205 KB markup size and 59 KB prose size. w:Interstate 5 in Washington is 187 KB markup size and 56 KB prose size. w:U.S. Route 113 is 168 KB markup size and 65 KB prose size. If SounderBruce can greatly expand the size of I-5 WA with a lot more Seattle detail, how large do you think we should go before we need to split out the Seattle area details? VC 19:08, 6 July 2023 (EDT)
IMHO ON-401 and I-40 in Tennessee are probably too big. I reviewed the latter and it was too much prose for one sitting (at least for me). But I would be careful about having a hard length cutoff before you can split. As we've seen, roadgeeks are more than capable for filling up a route description with, let's just say barely relevant stuff to quickpass whatever criteria they are aiming for, Exhibit a. "Route x is NOT part of the NHS. It's NOT part of the Autobahn network, it's NOT a British motorway". I don't want to encourage more of that. That's in part why I suggested the parent article must be GA or higher before can be split into city detail articles. Dave (talk) 00:49, 7 July 2023 (EDT)

List of highways numbered X

Example: w:List of highways numbered 1

This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

Clear consensus for adding these pages in some form, but see below. --Rschen7754 01:43, 10 November 2023 (EST)

  • No, just because they can be replaced by categories. --Rschen7754 01:37, 25 October 2023 (EDT)
    Can they, though? What if routes are only covered as part of a listicle or in some similar fashion that crams multiple routes into a single page? TC (Eli) 01:45, 25 October 2023 (EDT)
  • Strong yes, because these are useful for AARF's "Lowest route number you haven't been on" game, and categories cannot contain redlinks. (Someone wanting to see where the closest 174 or whatever to them might be disappointed if we don't have an article on a particular 174, but the information they are looking for is whether 174 exists, not whether the article exists.) —Scott5114 [EXACT CHANGE ONLY] 01:43, 25 October 2023 (EDT)
Also, these originated as disambiguation pages. We will still need "Route 6" to redirect somewhere. And functionally, that dab page is going to look identical to a "List of highways numbered X" page. —Scott5114 [EXACT CHANGE ONLY] 02:05, 25 October 2023 (EDT)
  • Yes. Even if it's just a routelist, this would be harmlessly fun at worst and actively useful at best. TC (Eli) 01:45, 25 October 2023 (EDT)
  • As a caveat to what Scott said, you can have a redirect in the category or you could just put a list in the wikitext portion of the page and then remove them when they turn blue. Consider me for having them and agnostic to where they should go. –Fredddie 01:51, 25 October 2023 (EDT)
  • I think we should have these as disambiguation for routes with the same number. For example, someone searching for “Route 1” will be redirected to the page where they can see all highways numbered 1. Dough4872 07:41, 25 October 2023 (EDT)
  • I think this information should exist in some form. I have no opinion of that is best done via disambiguation pages or something like a category. Dave (talk) 12:16, 25 October 2023 (EDT)
  • Yes. They're useful for both disambiguation and various roadgeek purposes. TheCatalyst31 ReactionCreation 12:22, 25 October 2023 (EDT)

Poll: import or start over

Should these pages be imported from enwiki or should we start over? Concerns have been raised about missing routes. --Rschen7754 01:43, 10 November 2023 (EST)

  • I would think it would be easier to add missing routes as they are noted rather than start over. --Duke87 01:50, 10 November 2023 (EST)
  • Import. I think the enwiki articles are in good enough shape that it'll be less work to clean them up, fix missing routes, etc. than it will be to create 1000-odd lists from scratch. TheCatalyst31 ReactionCreation 11:13, 10 November 2023 (EST)
  • Test a couple. I think we should at least try out what remaking a list would entail. If it's a pain in the ass, then we can import. –Fredddie 16:39, 10 November 2023 (EST)
  • Starting over would probably be a lot less effort and more complete if a script were written to run through TravelMapping data and generate the lists that way. —Scott5114 [EXACT CHANGE ONLY] 17:23, 10 November 2023 (EST)
I've done most of the work getting the info off TM manually - there needs to be more done (and include the frad/fram systems) to get it completely sorted (gleaning off text out of the number file, actually checking whether two different routes are part of the same route or duplicate numbers, etc) but then there's a (bot?) conversion of a system and route/banner/name combination into our naming conventions. I'm not sure it's easier! There's also the issue of TM criteria and scope being different to that here. Si404 (talk) 06:28, 17 January 2024 (EST)
Thank you so much for doing this. I've chosen the (auspicious) number 238 to do a comparison: [1]
  • ausvicc C238 238 - missing from enwiki
  • autl5 L238 Seekirchner Landesstraße 238 - missing from enwiki
  • autl6 L238 Kohldorferstraße 238 - missing from enwiki
  • autl7 L238 Niederthaier Straße 238 - missing from enwiki
  • beln N238 238 - missing from enwiki
  • canmbp MB238 238
  • cannl NL238 238
  • canpe PE238 238
Quebec Route 238 is missing from TM. (Update: I've been told this does not exist, however this is something that we would have to filter out)
  • crirs RS238 238
  • czeii II238 238 - missing from enwiki
  • deub B238 238 - missing from enwiki
  • deubbl L238 238 - missing from enwiki
  • deunwl L238 238 - missing from enwiki
  • deurpl L238 238 - missing from enwiki
  • deushl L238 238 - missing from enwiki
  • deusns S238 238 - missing from enwiki
  • espn N238 238 - missing from enwiki
  • gbna A238 238 - missing from enwiki
  • gbnb B238 238 - missing from enwiki
  • irlr R238 238 - missing from enwiki
  • islth TH238 238 - missing from enwiki
  • itass SS238 238 - missing from enwiki
  • jpnh N238 238
  • nldp N238 238 - missing from enwiki
  • poldw DW238 238 - missing from enwiki
  • roudj DJ238 238 - missing from enwiki
  • swel L238 238 - missing from enwiki
  • usaar AR238 238
  • usaaz AZ238 238
  • usaca CA238 Fremont 238
  • usafl FL238 238 - missing from enwiki
Georgia State Route 238 is missing, former
Indiana State Road 238 is missing, former
Iowa Highway 238 is missing, former
  • usai I-238 238
  • usaks KS238 238
  • usaky KY238 238 - missing from enwiki
  • usamd MD238 238
  • usame ME238 238
  • usamn MN238 238
  • usamts SR238 238
  • usanm NM238 238
  • usany NY238 238
Ohio State Route 238 is missing, former
  • usaor OR238 238
  • usapa PA238 238
  • usapr PR238 238
  • usari RI238 238
South Dakota Highway 238 is missing, former
  • usatn TN238 238
  • usatx TX238 238
  • usatxf FM238 238
Utah State Route 238 is missing, former
  • usava VA238 238
  • usawy WY238 238
It seems that neither source is 100% complete. --Rschen7754 14:44, 18 January 2024 (EST)
I ran a SPARQL query on Wikidata items with the road number property set to 238, and it's the least complete of the three by fair, but it also includes Japanese prefectural highways that aren't in either of the other two. TheCatalyst31 ReactionCreation 22:56, 18 January 2024 (EST)
  • Import - We will save a lot of time by just importing the lists from Wikipedia and cleaning up as needed. Dough4872 17:58, 10 November 2023 (EST)
  • I will also note that as a point of order, [2] merged away a lot of the lists over 1000. For those it may be a lot harder to import and we may have less of a choice there. --Rschen7754 11:15, 11 November 2023 (EST)
  • Start over. I'm kinda over cleaning up enwiki stuff. It'd be nice to do it our way. TC (Eli) 15:01, 11 November 2023 (EST)
  • Bot Create, This seems like a case where a bot could auto-generate the pages. I think it's safe to say that any page with numerals in the title is a highway article, unless that numeral is a year. A bot could parse Special:allpages, strip out all pages with no numerals, then strip out the numerals that are likely years (for example any four digit numeral, check for the presence of infobox road in the article), then sort and dump. Could then even possibly pull the termini or decomissioned date from infobox road from the article being parsed if we wanted to list those. There would still be some cleanup work involved, however, it should be less work than either bluelinking enwiki imports or starting from scratch. If someone who actually codes bots thinks I've been smoking crack, my second choice is do a test run of say 5 articles that are imported, then bluelinked, verses 5 that are created from scratch, and go with the winner.Dave (talk) 01:02, 28 November 2023 (EST)
  • Bot(?) Create - We have a lot of lists already, eg those in Category:Lists of roads in the United States. They have Template: routelist row, which has a field 'route' containing the number. Grabbing all the ones with x and putting them on 'List of Routes numbered x' would make a good base. Then information from wikipedia, TravelMapping, wegenwiki, SABRE, etc can be used to supplement and enhance these. Si404 (talk) 06:28, 17 January 2024 (EST)
    • Unfortunately I don't think every list was converted over to that template. Internationally there are very few that use it. --Rschen7754 00:06, 21 January 2024 (EST)
  • Bot create It appears to me that the most complete and easily parsed source is TM data, thus the bot should be run using that data and everything else should be used to fill in. The big question of course is, who will code the bot. --Rschen7754 00:06, 21 January 2024 (EST)


This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

Incidents will not be covered. --Rschen7754 02:33, 20 January 2024 (EST)

Incidents (for example, crashes - like 1999 Ontario Highway 401 crash).

  • Not in scope. --Rschen7754 01:30, 31 December 2023 (EST)
  • I'd think these would just be discussed on the relevant route or system pages as necessary. TC (Eli) 01:33, 31 December 2023 (EST)
  • Out of scope, not germane to the purposes of a gazetteer. (Particularly notable incidents should of course be mentioned in the road's history section.) —Scott5114 [EXACT CHANGE ONLY] 01:44, 31 December 2023 (EST)
  • I'd agree that they're out of scope for us. It may be worth importing WP:CARCRASH (that I wrote) as official guideline. –Fredddie 02:26, 31 December 2023 (EST)
  • I would say dedicated articles for them are outside our scope, but we can still include a brief mention in the history section of a road article with a link to the Wikipedia article. Dough4872 10:02, 31 December 2023 (EST)
  • Incidents and particularly dangerous stretches of road can be discussed in highway articles, but incident articles are usually as much about things like weather and driving behavior as anything that would be in our scope. TheCatalyst31 ReactionCreation 14:11, 31 December 2023 (EST)

Special checking stations

This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

Low participation but there were no objections. --Rschen7754 01:28, 17 February 2024 (EST)

For example: w:California Border Protection Stations, w:United States Border Patrol interior checkpoints. --Rschen7754 02:06, 31 January 2024 (EST)

  • I think we can cover these articles on our wiki, much like we cover rest areas and weigh stations. Dough4872 09:02, 31 January 2024 (EST)

Project and Structure pages

What project pages will we need over time? We have a placeholder Main Page that will be expanded at some point to be all pretty and shiny. We have this discussion page that will get a fancy new name. Imzadi 1979  15:04, 19 June 2023 (EDT)

Imagine merging the roads projects on enwp, and then turning that merged project into the whole wiki. This page would be WT:HWY/WT:USRD/Village Pump/etc. We'd need some analogs to the project departments with their appropriate subpages, and while it's not a favorite, but we'd need some sort of MOS, even if we kept it lightweight. This can be merged with the standards pages into a simplified Standards manual. So:
What policy pages will we need beyond a basic blocking policy? Deletion policy, of course. Some admin discussion forum? Other pages? Imzadi 1979  15:44, 19 June 2023 (EDT)
We would have to work through this slowly, but civility/behavioral, sourcing, alternative accounts, bots, user rights come to mind. --Rschen7754 19:27, 19 June 2023 (EDT)
Although, we might be able to combine a few topics. The civility policy could cover the use of alternate accounts and socking as a general behavioral practice, or alternate accounts and bots could go together. Sourcing/citations could even be covered as part of the Standards manual. I should have mentioned with my previous list, but a Graphics Department could handle Maps too. Imzadi 1979  14:45, 20 June 2023 (EDT)
We forgot the all-important and most controversial topic: naming conventions. --Rschen7754 00:07, 21 June 2023 (EDT)
Yes, once we have an editor base can we have a redo of the SNRC poll? A fresh start means a fresh start. IMHO the one used to decide Wikipedia naming conventions got it wrong. So if we're ever going to re-address it, now is that time.Moabdave (talk) 14:46, 21 June 2023 (EDT)
Article naming is a part of Standards. Hat tip to Scott5114 for the idea of a Manual on Uniform Road Articles (MURA). MURA would have subdivisions for Scope, Article titles, Article structure, Basic style/formatting, RJL and routelist tables, Sourcing/citations. Basically a one-stop reference for someone creating a new article. Imzadi 1979  23:19, 21 June 2023 (EDT)

Policy page

I started a draft policy page at User:Fredddie/Policies where I borrowed heavily from enwiki's WP:LOP. I was intending that everything be loose and flexible. When we iron out the scope and have SRNC2, I'd like to link to those pages. –Fredddie 00:44, 22 June 2023 (EDT)

For speedy deletions I would also include uncontroversial maintenance, maybe clearly out of scope pages (i.e. pages on Pokemon). As far as overall, while I think there will be a lot more detail eventually on some policies (especially content), I think this is a good interim document that summarizes our expectations. --Rschen7754 14:09, 22 June 2023 (EDT)

Individual Page Proposals

Below are all the project page proposals that have been put forward thus far. The spaces below have been set out to vote on whether the sections are needed, and if it should be a department, initial volunteers to get the department started, and nominations for who should be the port of call of that department (that is, department heads). BMACS1002 21:05, 5 November 2023 (EST)


Discussion moved to #Specific assessment guidelines so is with a related discussion. Dave (talk) 13:10, 3 December 2023 (EST)


This one seems to already be up and running, but I invite people to sign on under the Participants header. I'd nominate either myself or User:Mxn as head of the department. BMACS1002 21:05, 5 November 2023 (EST)

AARoads:Markers or AARoads:Graphics


Same as AARoads:The Library. --Rschen7754 16:03, 2 December 2023 (EST)


Another no-brainer, in my opinion; I mainly include this to get the ball rolling on fleshing out the task force. BMACS1002 21:05, 5 November 2023 (EST)

This is one scenario where the coordinator or editor-in-chief position should exist. --Rschen7754 01:47, 10 November 2023 (EST)


I believe User:Imzadi1979 is still working on a standards document/Manual of Style for us. —Scott5114 [EXACT CHANGE ONLY] 00:09, 6 November 2023 (EST)

AARoads:Alternate accounts

I have redirected this to the relevant section of the conduct policy. —Scott5114 [EXACT CHANGE ONLY] 00:09, 6 November 2023 (EST)


This will probably redirect to the relevant section of the administration policy, when it is written. —Scott5114 [EXACT CHANGE ONLY] 00:09, 6 November 2023 (EST)

This policy, or the relevant section of the administration policy if we go that route, should be a priority since it's the only red link in the welcome template. TheCatalyst31 ReactionCreation 11:58, 6 November 2023 (EST)


I have redirected this to the relevant section of the conduct policy. —Scott5114 [EXACT CHANGE ONLY] 00:09, 6 November 2023 (EST)


I have redirected this to the relevant section of the conduct policy. —Scott5114 [EXACT CHANGE ONLY] 00:09, 6 November 2023 (EST)


I'm not really sure we need a "deletion policy". We have a scope section of the content policy, and at some point we'll probably want to codify what's ok to speedy delete, but do we really need much else? This could maybe redirect to AARoads:Deletion requests. —Scott5114 [EXACT CHANGE ONLY] 00:09, 6 November 2023 (EST)

Should explain how the process works, do we want 5 days? 7? 14? Until there is consensus? And what that is - is 50% enough? (especially if there are Delete/Merge/Redirect votes) --Rschen7754 00:34, 6 November 2023 (EST)
I've been assuming 14 days is a good enough time for anything. And yes, a simple majority for any one option should be sufficient for that option to carry—perhaps if no option gets a majority, it gets relisted in the form of an approval vote? —Scott5114 [EXACT CHANGE ONLY] 16:23, 7 November 2023 (EST)
If this is what we want to go with, which I think is reasonable and agree with, I think we should add it in a box at the top of AARoads:Deletion requests and redirect AARoads:Deletion there. Dough4872 19:59, 19 November 2023 (EST)
Can admins close discussions that they have voted in? --Rschen7754 19:39, 22 November 2023 (EST)
Poll: Deletion

Going to get this poll going so we can clear up expectations. --Rschen7754 20:54, 27 November 2023 (EST)

This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

Discussions will last 14 days. --Rschen7754 14:15, 12 December 2023 (EST)

How long should discussions last?
  • 14 days, this is a smaller wiki and we want to encourage participation. --Rschen7754 20:55, 27 November 2023 (EST)
  • Minimum 14 days, but if someone votes at 11:59, there should be a 48-hour extension after the last comment to allow for more discussion. This I think would dissuade sniping–Fredddie 21:13, 27 November 2023 (EST)
  • 14 days should be sufficient. Dough4872 21:19, 27 November 2023 (EST)
  • 14 days seems to be the standard on this wiki. —Scott5114 [EXACT CHANGE ONLY] 01:37, 28 November 2023 (EST)
  • 14 days sounds good to me - there's no rush if we're having a discussion about it. TheCatalyst31 ReactionCreation 11:36, 28 November 2023 (EST)
This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

It shall be permissible to close discussions with very clear consensus after seven days, but SNOW closes shall not be done unilaterally and seven-day closes should be rare. The wide majority of discussions should probably use the full 14 days. TC (Eli) 05:05, 16 December 2023 (EST)

Is it permissible to close discussions with very clear consensus after 7 days?
  • Yes, we're not all about bureaucracy. --Rschen7754 20:55, 27 November 2023 (EST)
  • Yes, but someone should ask for a SNOW close, it should not be done unilaterally. –Fredddie 21:13, 27 November 2023 (EST)
  • Yes - Only if there is unanimous consent for one option, even if one person goes against the majority then it needs to be 14 days. Dough4872 21:19, 27 November 2023 (EST)
  • Eh, I'm not really sure what the harm is in letting a discussion run the full two weeks, even if it's apparently obvious how the vote is going to go.. We've all seen the discussions where it looks like it's gonna turn into a pile-on, but new information comes to light partway through, and the tide turns. I'm not entirely opposed to having it as an option, however. —Scott5114 [EXACT CHANGE ONLY] 01:37, 28 November 2023 (EST)
  • Yes, with the caveat Fredddie added. TheCatalyst31 ReactionCreation 11:36, 28 November 2023 (EST)
This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

Admins can close discussions they have voted in, though caution is advised in contentious cases. --Rschen7754 14:15, 12 December 2023 (EST)

Can admins close discussions that they have voted in?
  • Yes, although I would caution admins to be careful in contentious cases. --Rschen7754 20:55, 27 November 2023 (EST)
  • Yes per Rschen. –Fredddie 21:13, 27 November 2023 (EST)
  • Yes - agree with what Rschen said here. Dough4872 21:19, 27 November 2023 (EST)
  • Yes, closing a discussion should be no more than a procedural vote-counting exercise, so there is no reason to restrict the closer from participating. —Scott5114 [EXACT CHANGE ONLY] 01:37, 28 November 2023 (EST)
  • Yes per Rschen. TheCatalyst31 ReactionCreation 11:36, 28 November 2023 (EST)
This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

Should no option earn an absolute majority, the discussion shall be relisted in the form of an approval poll of all options that received at least one vote in the discussion. The option with a plurality of votes in the approval poll after 14 days shall prevail. Should no option earn a plurality of votes in the approval poll, the discussion shall be closed as "no consensus", which defaults to the page being kept. TC (Eli) 02:57, 31 December 2023 (EST)

If no option (redirect/merge/delete etc.) gets an absolute majority, should the discussion be relisted?
  • Yes eliminating the outlier options. --Rschen7754 20:55, 27 November 2023 (EST)
    • Per Scott, although I have expressed concerns regarding banning comments in approval polls. --Rschen7754 20:09, 12 December 2023 (EST)
  • Yes, but only once. That way we don't have an endless relistings. What I'm thinking is that if a proposal fails, it should be reworded and tried again. –Fredddie 21:13, 27 November 2023 (EST)
  • Yes - I think we can relist for another 14 days to see if an option gets a majority, if not then the discussion should default to keep. Dough4872 21:19, 27 November 2023 (EST)
  • It should be relisted in the form of an approval poll of all options with votes at the previous discussion. Whichever option has a plurality in the approval poll should govern. —Scott5114 [EXACT CHANGE ONLY] 21:40, 27 November 2023 (EST)
    • What if the approval poll is tied? –Fredddie 16:21, 2 December 2023 (EST)
      • I suppose at that point we would do a runoff between the tied options (if there are fewer of them than the number of options presented), just close as no consensus/status quo (if all of the options listed are tied), or pay out at 8 to 1 (if the discussion is found to actually be a baccarat table). —Scott5114 [EXACT CHANGE ONLY] 21:31, 19 December 2023 (EST) —Scott5114 [EXACT CHANGE ONLY] 21:31, 19 December 2023 (EST)
  • Seconding Scott's proposal. TheCatalyst31 ReactionCreation 11:36, 28 November 2023 (EST)
This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

Administrators shall be allowed to delete the following in all cases without a listed discussion: spam, vandalism, blatant hoaxes, attack pages, test pages, clear copyright violations, reposting of previously deleted material, and pages that are obviously not related to roads. Administrators shall also be allowed to perform routine maintenance deletions (such as unused template subpages, orphaned talk pages, or duplicate articles) without a listed discussion. Finally, administrators shall be allowed to delete any user's userpage without a listed discussion should that user request it. TC (Eli) 02:40, 31 December 2023 (EST)

Can the following cases be speedy deleted by an administrator without a discussion? (If you object to any, please say so). Spam, vandalism/attack pages, pages clearly out of scope, maintenance actions (i.e. unused template subpages or orphaned talk pages), userpages upon author request, clear copyright violations, reposting of deleted material.
  • Yes. --Rschen7754 20:55, 27 November 2023 (EST)
  • Yes.Fredddie 21:13, 27 November 2023 (EST)
  • Yes. - We should also make clear what cases we can use speedy deletion on the Deletion page. Dough4872 21:19, 27 November 2023 (EST)
  • Yes, although rather than "pages clearly out of scope" I would prefer to be more specific and say "pages not related to roads" or something like that, so as to kind of define how clear it needs to be (obviously a page about a certain type of salami sandwich eaten only in North Platte, Nebraska should be speedy-worthy, but if it looks even passingly road-related we should probably have a delreq for it just so we know we're not accidentally deleting an unsigned SR or a local freeway that isn't named like a freeway or something like that). —Scott5114 [EXACT CHANGE ONLY] 21:45, 27 November 2023 (EST)
    • That is generally what is meant - stuff that is unambiguously out of scope, or written in a language other than English. --Rschen7754 01:18, 28 November 2023 (EST)
      • That's the thing, "clear" and "unambiguous" is kind of a matter of opinion. (For example, I certainly wouldn't take "language other than English" to be "unambiguously out of scope" as currently defined in the content policy.) So I'd like the fences between "speedy delete", "needs a delreq to determine if it's in scope", and "clearly within scope" to be explicit. We mostly have "clearly within scope" nailed down in the content policy, we just need the border between the other two categories visited established. —Scott5114 [EXACT CHANGE ONLY] 01:46, 28 November 2023 (EST)
  • Yes I'd add test pages, blatant hoaxes, and duplicate articles to that list too. TheCatalyst31 ReactionCreation 11:36, 28 November 2023 (EST)


I have redirected this to the relevant section of the content policy. —Scott5114 [EXACT CHANGE ONLY] 00:09, 6 November 2023 (EST)

AARoads:User rights

I have redirected this to AARoads:User rights requests since there is a short summary of the various user rights available at the top of it. —Scott5114 [EXACT CHANGE ONLY] 00:09, 6 November 2023 (EST)

Consensus considered harmful?

Wikipedia likes to make a big deal about not being a democracy. There are reasons for this; wikipedia:Wikipedia:Polling is not a substitute for discussion has a good summary of most of the arguments. (One I've seen made, which that page doesn't really touch on, is that this prevents people from recruiting meatpuppets or sockpuppets to bolster their side.) Instead, editors look to establish a consensus on topics of discussion.

Consensus is a laudable goal and one we should shoot for whenever possible. However, the downside of consensus is that sometimes it's not achievable, because one or two people involved in the discussion just do not possess the ability in any fiber of their being to just shut the fuck up and drop it already. When one of these people wedges themselves into a consensus-driven process, the result is just a discussion that goes around and around in circles and never ends. In discussions where there's a deadline for reaching a decision, like a deletion discussion, this often leads to a "no consensus" outcome that has all the gravitas of a tied NFL game or a hung jury. At best, it's a temporary end to the discussion; at worst it's a waste of everyone's time who participated.

So what I'd like to propose is that AARoads wiki is a democracy. At least, some of the time. If we have a nice, simple discussion where it looks everyone is more or less on the same page and just needs to hammer out details (like everything on this page above this section), great, we go with that and let the discussion go to its natural conclusion. (The analogy would be to a voice vote in a legislature.) But if it doesn't look like there's likely to be an agreement, perhaps we should just go ahead and do an actual poll of some kind. Our community will probably be small enough that even one or two people not agreeing with everyone else will likely constitute a large enough percentage of the respondents that the traditional yardsticks of "consensus" won't really be useful. Also, I've personally never cared for the fuzziness of what threshold constitutes "consensus" anyway; as far as I can tell it's mostly just admins eyeballing the discussion and saying "yeah, that's good enough for me". Supposedly strength of argument is to be taken into account, but if your argument is really strong enough, you should be able to influence a vote anyway.

wikipedia:Wikipedia:Village pump (proposals)/Archive 201#RfC on draftifying a subset of mass-created Olympian microstubs is a good example of the absolute unholy mess that can result when using this approach. TLDR (because there really is too much to read) is that there was a bunch of arguing that went on for pages and pages, an admin closed it no consensus, someone brought it to an appeal forum and managed to browbeat the closing admin into withdrawing his closure, and then another admin came along and closed it in favor those doing the browbeating. If it were just a simple matter of counting votes rather than a judgement call, the closure would have been a lot more simple and tidy. (Well, maybe not... but that's what community bans are for. ;) )

For straightforward pass/fail two-option polls, a simple (50% plus one vote) majority would probably suffice. For multiple-option polls (e.g. what Wikipedia calls RFCs), it would probably be a good idea to do something like instant-runoff voting, a.k.a. ranked choice voting (just because we're voting doesn't mean we have to import the bad ideas of democracy like first past the post!). We would also need to establish when a discussion goes to a vote; I imagine someone calling for a vote and then someone else seconding it would be enough to trigger one. I do think we would need to clarify that a vote isn't necessarily permanently binding and can be overturned by a later discussion or vote, but maybe we should specify a limitation on when a new vote can take place, to keep sore losers from triggering repetitive vote-a-ramas. (Perhaps another vote on the same subject cannot take place for some fixed time period. Or we could borrow a rule from the US Senate and say that nobody can start a vote and then also vote the same way as they did last time. Or do something like a California recall election, where some percentage of the total number of voters in a given vote must call for a new vote to overturn it.)

I'd like to hear everyone else's thoughts on this, because it would be a pretty substantial change from Wikipedia, but I think it might be a worthwhile one that would stave off some unnecessary drama. —Scott5114 [EXACT CHANGE ONLY] 01:32, 22 June 2023 (EDT)

I like this idea and we should consider implementing mw:Extension:SecurePoll, which has the option for single-transferable voting. That way there is even more objectivity to the results. –Fredddie 01:46, 22 June 2023 (EDT)
I agree with the thrust of it but not with SecurePoll. Besides being able to see where people are at in real time and potentially their reasons for voting that way, I do not have a lot of faith in the usability of the SecurePoll extension and its maintenance or ease of use.
Some other thoughts: I would suggest scrapping the canvassing policy and replacing it with a minimum edit count (and tenure?) required for voting. Of course during the first few months we might have to relax that requirement. --Rschen7754 02:01, 22 June 2023 (EDT)
Yeah, the canvassing policy is stupid and I don't support bringing it over. I'm not so sure a tenure requirement is really necessary, although some states do have a tenure requirement for voting (in Nevada it's 30 days, for instance). If there is no tenure requirement, I do think it should be routine procedure to automatically checkuser any new account voting in a poll. —Scott5114 [EXACT CHANGE ONLY] 02:15, 22 June 2023 (EDT)
I think we might run into problems in Europe if we did that. Also, CU only does so much as it is deleted after 3 months (and of course, we have database constraints). --Rschen7754 02:24, 22 June 2023 (EDT)

I fully support the idea of making this wiki more of a democracy and using majority votes and RCV for multiple option items as opposed to the consensus idea that Wikipedia uses. Dough4872 15:21, 22 June 2023 (EDT)

I was thinking about it a little more. I was thinking SecurePoll originally because it's a Mediawiki thing. But we're not relying on the WMF, so we don't need to use their solutions. A simple Google Form, which are free and fairly easy to use, gets the job done just as well. And so long as you have the link and everyone is truthful in saying who they are, we can have transparency in voting. –Fredddie 19:33, 22 June 2023 (EDT)
I like the idea of just having the vote take place on the wiki itself using some sort of RCV template. Then have an open-source script that you paste the wiki text into and it tells you the result. The benefit of this arrangement is that anyone could then run the same script and verify the result.
This means that votes would be public, which they aren't with SecurePoll or a Google form, but I'm fine with this as 1) this is the way discussions on wikis normally are anyway 2) public votes are used in legislatures, which is probably a better model for what we'll be doing than the "private citizens voting for a candidate" model 3) the reasons for secret ballot are so that you don't face repercussions for your vote or be bribed to vote a certain way (since with a secret ballot nobody can know whether the bribe was successful or not. Repercussions can be handled with the conduct policy, and if you're bribing people for votes on a road wiki, you're just kind of pathetic. —Scott5114 [EXACT CHANGE ONLY] 19:44, 22 June 2023 (EDT)
Personally I like to see what way people are voting and why, because it might influence my own decision - and I often tailor my comments that way too. Because otherwise we have to allow voter's guides for secure polls. --Rschen7754 20:09, 22 June 2023 (EDT)

Wikipedia's governing by consensus policy is a joke. As is clearly visible at most contentious RFC's,AFD's, RFA's etc. typically one side browbeats the other in to submission until the abused party gives up. Consensus has come to mean which side shouts the loudest and wont' back down. I'll be quite happy if I never hear that horribly misused wikiword again. I'm ok with keeping Wikipedia's convention of including a rational with a vote so that the judge can give it more or less weight. However, if we go that route I would request we include a rule you CANNOT reply to someone else's !vote. You can say "support per X" or "I disagree with X's reasoning" but in YOUR vote space. None of this browbeating the other side into submission crap that has become the norm in Wikipedia. I would actually make it a blockable offense, I feel that strongly about it. Dave (talk) 19:07, 22 June 2023 (EDT)

Approval or range, not ranked choice. See https://rangevoting.org, more specifically https://rangevoting.org/CompleteIdioticIRV2.html. HotdogPi (talk) 19:30, 8 September 2023 (EDT)
You know, I think I like approval voting in a wiki context, as it would be dead simple to implement and easy to understand (just sign your name to everything you approve of; no comments in the votes are needed because there's no need for oppose votes). —Scott5114 [EXACT CHANGE ONLY] 17:30, 16 September 2023 (EDT)

This is very interesting to me, coming from OSM, where the term "consensus" has only ever been used as either a cluebat or a lament about partisan gridlock. On the OSM Wiki, canvassing is not only allowed but basically expected, and there's basically no control against sockpuppetry in the chaos that is OSM's fragmented communication landscape. The wiki's tagging proposals require a three-quarters supermajority. [3] However, since the wiki is merely supplemental documentation for the actual database, there's no guarantee that an approved or rejected proposal leads to any outcome other than words on a page. This greatly lowers the stakes, so that it would be utterly pointless to game the system. Unfortunately, a close call will inevitably generate reams of afterparty debate, punctuated by calls for consensus.

Given all the discussions that always go around in circles anyways, I've always looked up to English Wikipedia's nod to the idea of striving for consensus, even though it all goes downhill from there. (I also participate in another Wikipedia that counts votes.) I don't have any objection to the proposal to scrap consensus as a process, because a community as young as this one needs to experiment with new approaches rather than cargo-cult old traditions. That said, it may be worth (re)reading rfc:7282 for any principles that would be worth keeping in some other fashion.

 – Minh Nguyễn 💬 18:24, 16 September 2023 (EDT)


So as a point of order: it seems that we've moved to majority voting in some form for many of the discussions. Is that what we will go for? And shooting down the notion of a canvassing policy as enwiki has it? --Rschen7754 01:46, 10 November 2023 (EST)

Yes, it seems that the consensus is not caring about consensus, funnily enough. We should probably create a procedure page codifying how AARoads:Approval voting works. —Scott5114 [EXACT CHANGE ONLY] 17:25, 10 November 2023 (EST)

I think that we need more clarity on what "approval voting" is. Is it the default mode of making decisions, or a decision making process of last resort (i.e. ArbCom)? Most of the recent polls have allowed rationales, for example, and I would be strongly opposed to omitting those by default. --Rschen7754 14:09, 28 November 2023 (EST)

I've attempted to clarify my thoughts on that at AARoads:Approval voting. The goal of not having rationales after votes is not to disallow voters from justifying their votes, but rather to avoid a rehash of a debate that should have already happened. I think there are benefits to clearly separating the "debate" and "voting" portions of a discussion, which I've tried to outline in the link above; after all, nearly every legislature in the world does this. —Scott5114 [EXACT CHANGE ONLY] 16:06, 1 December 2023 (EST)
I strongly disagree. The approval voting process seems to be predicated that every discussion, or at least a number of them, that need such a formalized process are as a result of contentious discussion. That is quite divorced from the reality that we are a wiki that is not bureaucratic and does not thrive on process, unlike English Wikipedia - and thus discussions tend to die out and need to be revived. Disallowing rationales would not be a benefit here and would disenfranchise or at least make it harder for people from giving opinions late in the process. It would require aggressive clerking which is unfriendly. It would make us more bureaucratic than English Wikipedia, which is really saying something. Not to mention that the mechanics of approval voting favor earlier proposals over later ones. The legislature argument is a red herring: they don't operate in asynchronous environments like we do.
This is also not to mention that numerous polls have already taken place on this wiki, on this very page, and have generated results. "Approval voting" as proposed is set up to be a process that nobody uses; as the initiator of many polls, I intend to keep them titled as polls to avoid invoking the bureaucracy that "approval voting" requires. --Rschen7754 21:22, 1 December 2023 (EST)

Is this something that can be closed now? Approval voting seems to have been implemented and is working well. –Fredddie 17:15, 2 January 2024 (EST)

Under Scott's definition, there has only been one approval vote on this wiki. Everything else has not been an "approval vote", because it has comments, among other things. --Rschen7754 20:15, 2 January 2024 (EST)

Assessment scale

I started a mockup of an assessment scale over at User:Imzadi1979/Assessment. Thoughts? Imzadi 1979  23:23, 25 June 2023 (EDT)

I assume anything in Annex wouldn't be assessed? --Rschen7754 23:28, 25 June 2023 (EDT)
I like this assessment scale, it kind of goes with the assessment based on the completeness of the big three sections that we have used on Wikipedia for years along with having more formal processes similar to GAN/ACR/FAC, with the notable change of merging ACR and FAC. I think we can have an “Annex-class” for pages that are part of the annex that don’t need to follow the article assessment scale. Dough4872 23:32, 25 June 2023 (EDT)
I don't think there'd be much need for an "annex" class—that was necessary on enwp because we needed to tag pages relevant to our project and tell the template to ignore the assessment. Here, we can just leave the assessment template off (or feed it a generic "N/A" argument).
I do agree that annex pages shouldn't be assessed, however. In most cases they will not be articles we can judge by the same criteria (and some people who might be interested in using the annex wouldn't be interested in having their page assessed anyway). —Scott5114 [EXACT CHANGE ONLY] 02:26, 26 June 2023 (EDT)
I think of the Annex, under the current ideas of what it would be, as its own project. Putting that content into its own namespace implicitly assesses it, thus we don't need to assess it explicitly. Imzadi 1979  16:02, 27 June 2023 (EDT)

What about importance? Are we going to carry that over? Personally I've found it useless, to be honest. --Rschen7754 03:01, 29 June 2023 (EDT)

I think we can use the same importance scale that we use on Wikipedia. However, I can also see us not really needing an importance scale either. Dough4872 18:11, 29 June 2023 (EDT)
Agreed it would be useless; highways come pre-sorted by importance for your convenience. If we need something like the importance categories in the future we can just group by highway system. —Scott5114 [EXACT CHANGE ONLY] 01:09, 1 July 2023 (EDT)
There are of course outliers. For example Clark County Route 215 is significantly more notable and important than the average county route, even Clark County route. But I don't see the need to create infrastructure just to tell people that, it's fairly self evident. It would be about like those classy Wikipedia templates "This section is empty" or "This lead may be too long".

I've taken some time to think about this and I don't think assessments are worth the effort anymore. On enwiki, we incentivized destubbing articles and that was great because it meant reducing the likelihood of the article being deleted. That's (very likely) not going to happen here, so the same kind of incentives won't work. Plus, it was easy to game the system if you had a buddy for mutual back scratching, which led to many Good Articles that frankly weren't very good. I'd be much happier with tags that we could place in a section that needs some work. Hell, we could even turn off their display for people who aren't logged in. I guess the incentive would be that it's our content on our website, so we want to make it good to increase readership. This all being said, I am not against a formal review for "featured content" for lack of a better term. I just don't think we need the bureaucracy of grading articles. –Fredddie 00:49, 26 July 2023 (EDT)

You're correct that our incentives have changed a bit, and yes, assessment is a large amount of bureaucracy, especially if we're going to do a global reassessment rather than simply carry over the Wikipedia assessments. However, there's that old management axiom "If you can't measure it you can't improve it" (which is credited to so many people on the first page of Google results I'm just going to arbitrarily say Theodore Roosevelt came up with it). Assessments are subjective, but they are the only tool we have to see whether the project is moving forward or not. Frankly, without the assessments I become hilariously ineffective as an editor, because my entire editing workflow is structured around them; Oklahoma still has lots of articles with no history section or entirely unreferenced route descriptions, but without those being tagged "start" or whatever I'll spend more time finding them than if I can just go to the assessment list, sort worst to best, and grab what comes up. That, and I personally find it really hard to stay motivated without some sort of measurable progress I'm working toward. Without it, it just feels like I'm pouring time and energy to an endless task; at least if the number goes from 3.954 to 3.838 or whatever I have some proof to myself I did something. I suppose rather than using an assessment scale, we could just have a checklist of things that a featured article needs and then keep track of which articles have one check, which have two, etc... but that's just assessment with the serial number filed off.
Also, don't forget...because this isn't Wikipedia, if someone is engaging in bad faith conduct like falsifying assessments for useless wiki points...ban their ass. —Scott5114 [EXACT CHANGE ONLY] 07:57, 27 July 2023 (EDT)
This reply is woefully late, but I get the same editing push by making sure "maintenance categories" are empty. The thought being is if there are no articles in the "Crappy history section" category, then I know everything is good. That's basically how I bided my time on enwiki. If we can tie the two together, you get your points and I get maintenance cats to empty, then everybody wins. –Fredddie 15:49, 21 August 2023 (EDT)
I would disagree, while the statistics have been abused in the past, baby:bathwater. Also for the reasons Scott states. --Rschen7754 20:36, 21 August 2023 (EDT)

I like the proposed assessment scale, and support keeping assessment around in general. The benefits of having a metric to keep track of article quality outweigh the downsides of editors abusing the metrics. TheCatalyst31 ReactionCreation 15:03, 19 September 2023 (EDT)


I have implemented this as {{level of service}} (or {{LOS}} if you're in a hurry). It accepts class (for the class, A-E), region (state, province or country), and type (e.g. state highway, Interstate, turnpike, system, w/e). I've placed it on Kansas Turnpike, Michigan State Trunkline Highway System, and K-107 (Kansas highway) as a proof-of-concept. —Scott5114 [EXACT CHANGE ONLY] 00:41, 22 September 2023 (EDT)

I like this a lot. Can you expand a little more on how we should use the "type" field? What does it currently accomplish and is there any standard way it's intended to be used? TC (Eli) 00:54, 22 September 2023 (EDT)
This is meant to be used to indicate the type of highway. So Interstate 80 would be something like {{LOS|class=C|region=United States|type=Interstate}}. Other options would be "U.S. route", "State highway", "System", "County road", or however you want to categorize it. The categories it files the article under are by region, type, or both. (So you would have, e.g. D-Class South Dakota articles, D-Class state highway articles, and D-Class South Dakota state highway articles.) —Scott5114 [EXACT CHANGE ONLY] 06:21, 22 September 2023 (EDT)
It sounds like we would need a list of acceptable options. I would prefer using abbreviations, but then we get into problems like whether WA is Washington or Western Australia. (Though Georgia could be a problem). I assume the state categories would also need to feed into the national categories. --Rschen7754 12:28, 22 September 2023 (EDT)
I feel like this should go onto the talk page. The load times of saving onto the main page are one reason. --Rschen7754 22:38, 24 October 2023 (EDT)
Agree, I think article assessments would better belong on the talk page. Dough4872 08:37, 10 November 2023 (EST)

Poll: Assessment

I think that we should get this initiative started soon, so here we go: --Rschen7754 21:11, 1 December 2023 (EST)

This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

The scale shall be adopted. TC (Eli) 05:15, 16 December 2023 (EST)

Should the overall scale at User:Imzadi1979/Assessment be adopted?
  • Yes. We can continue to refine it later, but this is a good starting point. --Rschen7754 21:13, 1 December 2023 (EST)
  • Yes - This is good to use given it is based off what was used on Wikipedia. Dough4872 21:52, 1 December 2023 (EST)
  • Yes, per above BMACS1002 22:29, 1 December 2023 (EST)
  • Yes It's a familiar system and should work well, and we can always iron out kinks after our initial pass of assessments. TheCatalyst31 ReactionCreation 00:40, 2 December 2023 (EST)
  • No, but only because I don't think assessments are the best ways to track progress. –Fredddie 16:30, 2 December 2023 (EST)
  • Yes. I don't really think the previous system was broken, so no need to fix it. TC (Eli) 15:05, 5 December 2023 (EST)
This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

Article assessments shall be placed on the talk page. TC (Eli) 05:15, 16 December 2023 (EST)

Should article assessments go on the article itself or on the talk page?
  • Talk page, if only to deal with the page load times. --Rschen7754 21:13, 1 December 2023 (EST)
  • Talk page - This would help with page load times and mirror what was done on Wikipedia. Dough4872 21:52, 1 December 2023 (EST)
  • Talk page per above, though we should reconsider when improvements are made on the servers. BMACS1002 22:29, 1 December 2023 (EST)
  • Talk page per above. TheCatalyst31 ReactionCreation 00:40, 2 December 2023 (EST)
  • Neutral. I don't care where they go. –Fredddie 16:30, 2 December 2023 (EST)
  • Neutral. I liked the mockup Scott provided a while ago of the emblem on the page itself and would like to see that become common practice. If that is not reasonable, so be it. TC (Eli) 15:05, 5 December 2023 (EST)
This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

Relevant articles that attained Featured Article status on the English Wikipedia shall be provisionally assessed as A-Class on the AARoads Wiki. TC (Eli) 05:15, 16 December 2023 (EST)

Until processes are developed for A-Class, should English Wikipedia featured articles be awarded A-Class on a provisional basis?
This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

Relevant articles that attained A-Class status on the English Wikipedia shall be provisionally assessed as A-Class on the AARoads Wiki. TC (Eli) 05:15, 16 December 2023 (EST)

Until processes are developed for A-Class, should English Wikipedia A-Class articles be awarded A-Class on a provisional basis?
This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

Relevant articles that attained Good Article status on the English Wikipedia shall be provisionally assessed as B-Class on the AARoads Wiki, though effort shall be taken to review these articles and reassess as necessary. TC (Eli) 05:15, 16 December 2023 (EST)

Until processes are developed for B-Class, should English Wikipedia good articles be awarded B-Class on a provisional basis?
  • Yes, though I suspect that some may be removed once the process is in place. --Rschen7754 21:13, 1 December 2023 (EST)
  • Yes Dough4872 21:52, 1 December 2023 (EST)
  • Yes BMACS1002 22:29, 1 December 2023 (EST)
  • Yes, though we'll want to re-review these eventually. TheCatalyst31 ReactionCreation 00:40, 2 December 2023 (EST)
  • No. I think a lot of the criticism USRD got with regards to good articles was justified. I'm not saying all of them are bad but a significant portion of them are. –Fredddie 16:30, 2 December 2023 (EST)
  • Yes but only because I think there are more articles that are "legitimate" GAs than those that were promoted due to QPQ garbage. TC (Eli) 15:05, 5 December 2023 (EST)
This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

Relevant lists that attained Featured List status on the English Wikipedia shall be provisionally assessed as AL-Class on the AARoads Wiki, though some believe the distinction between AL-Class and A-Class is unnecessary. TC (Eli) 05:15, 16 December 2023 (EST)

Until processes are developed for A-Class, should English Wikipedia featured lists be awarded AL-Class on a provisional basis?
  • Yes. --Rschen7754 21:13, 1 December 2023 (EST)
  • Yes Dough4872 21:52, 1 December 2023 (EST)
  • Yes BMACS1002 22:29, 1 December 2023 (EST)
  • Yes TheCatalyst31 ReactionCreation 00:40, 2 December 2023 (EST)
  • Yes, but I don't think there should necessarily be a distinction between A and AL. –Fredddie 16:30, 2 December 2023 (EST)
  • Yes with the same caveat as Fredddie. TC (Eli) 15:05, 5 December 2023 (EST)

Specific assessment guidelines

We have multiple ideas for how to implement Imzadi's article grading/assessment scale above. I don't think we're ready for a formal poll just yet. However, please provide your comments on one or all of these ideas:

Please give your thoughts to help prepare us for a formal vote. Dave (talk) 12:34, 3 December 2023 (EST)

General comments

  • Just as a note, my essay is solely intended to be that and is not meant to be a basis for assessment. It is also very CA-specific. --Rschen7754 16:20, 3 December 2023 (EST)

Essay comments

Point scale comments

  • My rationale for assigning points the way I did was to incentivize good writing in the RD and history sections over just having a sentence or two each in the RD and history and a fully fledged junction list and calling it a C-Class article. An article with a complete RD and history section would rank higher than the article with just having a sentence or two each in the RD and history and a fully fledged junction list. In terms of the old Wikiwork scale (remember it would only go up to 4.0 here), there is a big difference between a 2.000 C-Class article and a 2.999 C. To that end, I think the "GPA" should be advertised with the rating. " 3.219" –Fredddie 12:51, 3 December 2023 (EST)
Ahh, now I get it. In that case the "optional" grading scale I initially proposed with my checklist draft wouldn't work for these aims, as the checklist still has all or nothing requirements. I'll take a second look. However, I suspect having a checklist isn't compatable with point scale and we'd have to have one or the other. However, I'm torn. I understand your logic that having a point scale could encourage article improvement even withing the same grade/rank. However, my mind is still wrapped around the idea of "minimum requirements".Dave (talk) 13:08, 3 December 2023 (EST)
I like it but would propose some changes. As the grading scale for Route description and History are substantially similar I'd make that generic and just have a grading scale for each prose section (i.e. level 2 heading with prose, not lists or tables). I say this as some highways legitimately have sections for pop culture (US 66 for example), incidents, controversy, etc. Making the prose grading scale per section would cover those. So I'd also have a criteria to grant points if a section beyond the "big two" is present and appropriate or deduct points for a section that is filler or a distraction. IMHO we need to encourage prose beyond the typical roadgeek details, but do it in a quality manner, not just dumping grounds for a list of Family guy episodes.
I'd also award points for any source that isn't an on-line map, to encourage more such sources. I have such changes made at the bottom of my linked checklist above.Dave (talk) 14:31, 3 December 2023 (EST)
I think a point scale might be a good idea to assign assessment as opposed to basing it on the presence or absence of the “big three” sections on Wikipedia. However, I am worried a lot of it could be subjective as editors may have different opinions on prose length, prose quality, etc. I think using a point scale or checklist based on the point scale might be better for assessing A or B class articles in formal review processes in which an editor or editors can determine whether or not an article should be promoted. However, I think C, D, and E class should be less formal and simply be based on presence or absence of the big three sections. Dough4872 16:47, 3 December 2023 (EST)
I have a similar concern. I initially tried a hybrid approach in my draft, part grading scale, part absolute minimum for that very reason. But my effort sucked, and the checklist alone wasn't bad, so that's what I went with. However, if you, or anybody else, has an idea for a hybrid scheme, I'd love to see the draft. Dave (talk) 00:42, 4 December 2023 (EST)

Checklist comments

It seems that Imzadi's assessment scale is going to be implemented without much for editing, so I think now we should focus on a banner. I think we can work it into {{talk header}} rather than create a new template. Some questions I have:

  • What non-state/province task forces should we use?
  • Should there be some pseudo task forces for regions? (Upper Midwest US, Canadian Maritimes, etc.)
  • Should we tag non-article pages? (Categories, redirects, dab pages, etc.)
  • Article histories from enwiki? (FAC and ACR only)
  • What maintenance categories should we have? (needs-map, needs-jctint, etc.)
  • Is there anything we need to do to future proof? (Preview-class? similar idea to Travel Mapping preview status)

If you have any other suggestions, please add them. –Fredddie 17:58, 18 December 2023 (EST)

I like the idea of working assessments into the talk header template, we don’t need project banners like on Wikipedia. I think we should stick with the same task forces that were used on Wikipedia, I don’t see any reason to have regional task forces as they will seem redundant to the state/provincial task forces. I’m okay with tagging non-articles but at the same time I don’t really think there is a need to tag them as they won’t be assessed as part of the letter assessment scale intended for articles. I don’t think we need Wikipedia article histories on here as this is a new and separate wiki and eventually we may wanna reassess articles that passed GAN/ACR/FAC on Wikipedia. I think the maintenance categories we used on Wikipedia are good to carry over onto here in order to point out articles that are missing features such as a map, junction list, mileposts, etc. Dough4872 18:15, 18 December 2023 (EST)
Whatever we do should be international friendly. Also, there are some articles that won't have a task force or country like the road terminology that should be accounted for. --Rschen7754 20:01, 18 December 2023 (EST)

Interwiki link colors

There was some talk somewhere about changing the color of interwiki links (such as the "bluelinks" to enwiki) to differentiate from other external links. I'd like to propose the following colors:

  • #0000cc for unvisited links
  • #800080 for visited links.

According to mw:Design/Link colors, both of these colors are different than any of the default skin colors so there shouldn't be any issue there.

Any thoughts? –Fredddie 22:31, 19 September 2023 (EDT)

I like this idea for a color change for interwiki links. Dough4872 23:47, 21 September 2023 (EDT)
No gripes here. TC (Eli) 05:06, 22 September 2023 (EDT)
A typical paragraph will have several interwiki links to Wikipedia. Will the #0000cc be distracting compared to the current color? The Chinese Wikipedia developed a w:zh:Template:Internal link helper for linking to other Wikipedias and Wikidata within article text. It highlights the link in #007a5e (and turns #d73333 on hover). I find the green to have just the right amount of contrast, but I haven't checked how it fares with color blindness. – Minh Nguyễn 💬 03:12, 24 September 2023 (EDT)
I think it might make more sense for the more saturated colors (i.e. the two proposed ones) to be used to internal links and the less saturated for external. For one, that underscores the "this is on the same topic" vs. "this is on a different topic" distinction, so it seems like it would be more intuitive to make the most relevant links more noticeable. Secondly, since there will be more external links than internal links, it makes more sense for those to blend in more to keep from overwhelming the user. —Scott5114 [EXACT CHANGE ONLY] 19:00, 30 September 2023 (EDT)
This makes more sense, I agree. TC (Eli) 01:20, 10 November 2023 (EST)


Due to recent events on English Wikipedia (which won't be directly discussed here), I do think that our international articles are at risk. While we do have backups from 2023, it would be nicer to be able to disengage entirely without having to worry about what goes on there... while also trying to bring over as many editors as possible. We have not wanted to do a mass blind import, however, due to concerns that it would result in a large mess. I think that it would be easier to import slowly and be able to make fixes along the way, rather than having to do it in a hurry because GEOROAD fell suddenly.

Mexico seems the logical place to start. Unfortunately we don't have any active editors, however quite a few of us have been there. Some questions to think about:

  • Is now the time? I would have preferred that we get assessment done, but that is taking a while.
  • What are we considering notable? Federal and state highways? The ejes of Mexico City?
  • What about sources? I'm not 100% sure we have a comprehensive log at the federal level. What do we do about states where we can't find a route log?
  • Do we give each country its own resource page? Or upmerge somewhere?
  • What do we call the articles? At the federal level it is Mexican Federal Highway x, and we don't really use demonyms anywhere else.
  • Other things that need discussion? --Rschen7754 00:55, 22 January 2024 (EST)
I'd say now is as good as any time to start importing; the highways and ejes are the a good start for sure. I think the states we don't know a lot about we can use TM data to build state highway lists. I support creating "task force" pages for each country. When/if we start getting into the Caribbean, the territories can be a part of the European countries' task forces. As far as naming goes, I wonder how prevalent "Federal Highway x" is worldwide. We might be able to eschew disambiguators, otherwise, "Federal Highway x (Mexico)" suits me just fine. The state highways, I would put at "State Highway x (state)". I thought I remember talking about using disambiguators for everywhere but the US and Canada. –Fredddie 18:06, 22 January 2024 (EST)
The problem is that TM only has data for Queretaro, Mexico State, and DF (ejes). There's 29 other states, though admittedly I haven't been that thorough in my searching. --Rschen7754 20:05, 22 January 2024 (EST)
I will add that I support creating task force pages on an as needed basis only. I don't want us to waste all our energy building up the projectspace and not the articlespace. –Fredddie 19:22, 22 January 2024 (EST)
I'm not sure why we would disambiguate other countries in a different way than we do the United States (without a good reason specific to that country); that would seem like it would violate the principle of least astonishment without providing any benefit in exchange. We should keep things consistent. —Scott5114 [EXACT CHANGE ONLY] 00:22, 23 January 2024 (EST)
I'm willing to revisit AA:NC, especially regarding the State Highway/Road/Route states. I thought the responses for keeping NCs the way they were at enwiki were based on tradition more than anything else. Whenever we get to Europe, I want to avoid naming conventions like "Belgium A1" or "Germany Bundesautobahn 8" simply because that's the least astonishing name. –Fredddie 14:06, 23 January 2024 (EST)
I would imagine the alphanumerics would still use the parentheses form since that would be consistent with the K- and M- routes in the US. I don't think there's any need to disambiguate Bundesautobahn in particular unless there are other German-speaking countries that use that term (does Austria?), since in English the term autobahn is fairly closely linked to the German network. On the other hand, for other countries that give their highways a proper name to go with the number, I can't think of any reason having "Oklahoma State Highway 5" but "State Highway 5 (New Zealand)" would make any real sense. —Scott5114 [EXACT CHANGE ONLY] 00:50, 24 January 2024 (EST)
If the goal is to bring more editors here, the logical place is to start importing where we have people who have expressed interest, before that interest is lost, not add more work to the already active editors. Just my $.02, no doubt either way Mexico will be imported eventually.Dave (talk) 19:26, 22 January 2024 (EST)

I say we import the country and regional task forces from HWY on Wikipedia as a start and can create more specific country task forces at a later time when enough resources are found to warrant splitting off. For now our first focus should be importing articles, we can work on getting project space cleaned up later on. Regarding Mexico, importing numbered federal and state highways and the Mexico City ejes is a good idea and for now we can keep the naming conventions from Wikipedia. Dough4872 21:06, 22 January 2024 (EST)

I think we should start with importing what's on enwiki to give us a good base to start with; that's most of the federal highways and a handful of state highways, plus the ejes. I think it's also a good idea to look for route logs and keep track of what we find, since that gives us something to build route lists from. Once we have lists it'll hopefully be easier to write more articles.TheCatalyst31 ReactionCreation 21:35, 22 January 2024 (EST)

I created AARoads:Mexico and listed what I have for sources so far. I wasn't very thorough at the state level for looking at sources. --Rschen7754 21:07, 23 January 2024 (EST)

6 system/list articles were imported just now for Mexico. --Rschen7754 22:48, 29 January 2024 (EST)

Mexico has been imported. The naming convention question is still open. --Rschen7754 19:15, 3 February 2024 (EST)

I'm sure this is coming in the MURA, but do we want to introduce the 10 junction infobox limit to international? –Fredddie 16:41, 12 February 2024 (EST)

See Mexican Federal Highway 15DFredddie 16:42, 12 February 2024 (EST)
I would support, though my ultimate preference is to do away with the field entirely. --Rschen7754 20:00, 12 February 2024 (EST)


I wanted to dig into this a little more. Currently, federal highways are named Mexican Federal Highway 1, but it's the only highway system where we've used the place's demonym in the title (this includes the before times on enwiki). Shouldn't it be Mexico Federal Highway 1 to be "least astonishing"? –Fredddie 16:41, 20 February 2024 (EST)

  • I think this is a good idea to use the official place name rather than the demonyn in the article title, unless official sources use “Mexican” rather than “Mexico”. Dough4872 17:45, 20 February 2024 (EST)
  • Sounds good, but then I assume that we are going to use this across the site when there is a number with no letter? --Rschen7754 20:26, 20 February 2024 (EST)
    Can you be more specific? –Fredddie 21:19, 20 February 2024 (EST)
    Chile Route 203, for example. --Rschen7754 21:20, 20 February 2024 (EST)
    Oh yeah, that's consistent. –Fredddie 21:26, 20 February 2024 (EST)

Saskatchewan Highway 16

There are some unnecessary quotations in this article that are on the verge of violating copyright. We don't have a copyright handling system, but if anyone had time to remove the unnecessary quotes and write (not closely paraphrase) in replacement text, it would be a great help. --Rschen7754 02:31, 23 February 2024 (EST)