AARoads:The Interchange

Debates about Scope

Bridges/tunnels

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 ^{Reaction•Creation} 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 ^{Reaction•Creation} 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 ^{Reaction•Creation} 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)

Nevada

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

• With the obvious exception of CC-215, listicle. Moabdave (talk) 14:22, 21 June 2023 (EDT)
• My hesitation is stuff like List of county routes in Elko County, Nevada which I am not sure is very informative and was such a rehashing of the government source that I considered it plagiarism. --Rschen7754 14:04, 27 November 2023 (EST)

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)

I would vote for a capstone article for the state plus CC-215. –Fredddie™ 16:33, 13 March 2024 (EDT)

Interchanges

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)

Ah, that's a directional interchange. –Fredddie™ 16:02, 13 March 2024 (EDT)

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)

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. [1] 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)

Implementation

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)

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)

Europe: the big picture

It seems that there is interest in importing Europe. There are a lot of decisions that have to be made and I won't unpack every single one just yet. But we should probably start discussing. I firmly believe that the success of our international efforts will stand or fall on Europe.

• Is Europe what to do next? There is some interest on Discord. I don't think South America is a good candidate as we don't have much interest, and Brazil will be a significant mess to clean up. Oceania has been suggested but I am concerned about buy-in from the Australian road editors there.
• What are we considering Europe?
  • Are we including all the dependencies of each country, even those outside Europe? Obviously we want to finish importing the French Caribbean - however, France has territory in South America, Africa, and Oceania too.
  • The United Kingdom. It has been suggested that we defer or completely omit the UK entirely, because of SABRE. I am firmly against this. There is obviously a lengthy history of acrimony in between the US and the UK road editors on English Wikipedia. But omitting a country entirely sets a bad precedent that will lead to omitting more countries (Ireland being the obvious one, but Australia could fall into that category). Moreover, SABRE does not extend us the same courtesy [2], though their coverage of the US is not very good. I will also point out that because of the SABRE licensing terms, the UK road articles cannot be forked over to SABRE, so if they are deleted, that is that. I am also a firm believer in the strength of our leadership and our editing community and collaboration, and believe that is our competitive advantage.
    • That all being said. The UK road articles as they stand right now do have some major problems: 1) Over half of the articles are of minor city streets, road safety items, city squares, and all sorts of stuff that are out of our scope. That will have to be sorted out. 2) Unlike in the US, most of the UK road editors went along with the tightening of notability, and many minor and some major A roads got merged away, sometimes inconsistently. 3) The UK has long resisted the junction list standards that the rest of the world has followed. So on those grounds, I am okay with deferring importing of the UK until we have more European editors (and possibly some UK ones) and have the time to clean up the mess, rather than delaying importing other countries with higher quality content and more interest.
    • If we delay importing the UK, we need to determine what to do about the dependencies - Isle of Man, Jersey, Gibraltar. No other dependencies have articles.
  • How far east do we go?
    • Russia? It will be really annoying to only import part of a country.
    • Turkey? It is split between Europe and Asia.
    • Cyprus? It is close to the Middle East, but uses the euro and is Schengen.
    • Georgia/Armenia/Azerbaijan? They have E-roads, and Georgia has an outstanding request to import.
    • Turkmenistan/Kyrgyzstan/Kazakhstan/Uzbekistan/Tajikistan? They have E-roads.
• What gets imported first?
  • Do we do E-roads first? Are there scenarios (see "How far east" discussion) where we just import the E-roads and defer the rest of the country until later?
  • Do we fulfill requests first?
  • Do we prioritize certain groups ("Western Europe", Schengen, EU, Eurozone)? What about micro-states? France and Netherlands to round out North America?
• One task force or multiple? AARoads:Caribbean is getting pretty long.
• What classes of road - a question that will be deferred until some of the other ones are answered. --Rschen7754 23:29, 28 April 2024 (EDT)

I do think the E-roads should be imported first. After all, even they are not immune from AfD. LilianaUwU ^{(talk / contributions)} 23:33, 28 April 2024 (EDT)

I don't have many strong opinions on non-US imports (since I've unfortunately never left the US, I feel like I probably don't know what I'm talking about), but I would suggest not getting hung up on what counts as "Europe". If the plan is to eventually import the whole world at some point anyway, it really doesn't matter in the long term whether Russia and Türkiye get imported with Europe or with Asia. So I would say if it could be considered Europe, go ahead and import it. —Scott5114↗ [EXACT CHANGE ONLY] 23:40, 28 April 2024 (EDT)

I definitely think Europe should be the next continent we work on importing due to good content and editor interest. I think we can start with importing the E-roads first before we go to individual countries. In terms of what countries to do, I would be fine with doing certain groups like the EU countries first or else follow a geographical pattern through Europe (i.e. west to east). I think in terms of how far east we can go I think we can include Russia (most roads in European part of country) along with Georgia/Armenia/Azerbaijan and Cyprus, as they are small and also there is an editor request for Georgia who also wants adjacent countries imported. I think Turkey and Turkmenistan/Kyrgyzstan/Kazakhstan/Uzbekistan/Tajikistan can be held until Asia gets imported as they are mostly/entirely in Asia; however, we can import E-roads for those countries. Dependencies of European countries such as France and the Netherlands can be imported along with the main country as I imagine they would not constitute too many articles. I think it might be a good idea to hold importing the UK to either the end of Europe or else later on after other continents as the articles are a mess; however, they should eventually be imported for completeness sake. As for the task force, I think it would be a good idea to have a main Europe task force with countries with a lot of resources to list being split into their own task force. Dough4872 23:47, 28 April 2024 (EDT)

I agree that Europe should be next, and I'd suggest that we move slowly and prioritize countries that either have interested editors or are already in pretty good shape (and on the flip side, de-prioritize anything like the UK that will be a mess to sort out). I say that mostly because I want to make sure anything we import gets bluelinked and maybe some basic cleanup, and if we dump a ton of new stuff in the lap of an editor base that's mostly interested in North America, that might not happen. I'm fine with importing any of the "borderline Europe" countries as it makes sense to do so (e.g. we have a request for Georgia). TheCatalyst31 ^{Reaction•Creation} 00:03, 29 April 2024 (EDT)

As I was the one volunteering for Georgia - I am still up for that. I am not checking in here all the time, so ping me or write a message if things get imported. Labrang (talk) 06:43, 6 May 2024 (EDT)

Taskforces - I've made these fairly big and include both actual and potential article totals (using the data from the tables, which I'm not sure is totally accurate). I've used the UNECE members (minus US/Canada) as a definition of Europe.

• E Roads (and other Europe-wide stuff?) - 230(+10?) existing, 230(+10?) potential
• Western Europe (AND, BEL, ESP, FRA (inc overseas), LUX, MCO, NLD (inc overseas), PRT) 559 existing, 3061 potential
• Britain & Ireland (GBR (inc overseas), IRL) - 2861 existing, 2921 potential
• Northern Europe (DNK (inc overseas), EST, FIN, ISL, LVA, LTU, NOR, SWE) - 257 existing, 2733 potential
• Germany (DEU) - 275 existing, 6300 potential
• Central Europe (AUT, CZE, HUN, ITA, LIE, MLT, POL, SMR, CHE, VAT) - 370 existing, 3355 potential
• South Eastern Europe (ALB, BIH, BGR, HRV, GRC, KOS, MDA, MNE, MKD, ROU, SRB, SVN, UKR) - 593 existing, 1274 potential
• Far Eastern Europe (ARM, AZE, BLR, CYP, GEO, ISR, KAZ, KGZ, RUS, TJK, TKM, TUR, UZB) - 240 existing, 939 potential

I think they are perhaps too big. Perhaps separate countries would be the best approach (with some merged).

As for ordering. The E Road system is sensible to import (in full - it's more effort to leave out the eastern edges than to bring it all across!) first. Georgia and Spain have requests, so them next. Then I don't care either way - what there's demand for, I guess. Si404 (talk) 07:00, 29 April 2024 (EDT)

Regions of Europe according to the CIA World Factbook

Most of the Far Eastern Europe category falls neatly into Asia, so I'd say we can skip them for now. I kind of like how the CIA World Factbook divides Europe into regions. If nothing else, it's at least something. We can always adjust. –Fredddie™ 02:00, 2 May 2024 (EDT)

Does it fall neatly into Asia? Only the -stans and Israel aren't a division on your map. The border is blurry. Sure, the Far Eastern Europe is stuff that people might not see as European (even Belarus) but others might, hence why I split it off from elsewhere. I would personally not have any of it as a priority, except that someone has requested Georgia - so it's at least worth importing that early on.

Those CIA regions are nonsense for our purposes - some are very large (both in reality and potential), others are very small. I tried to make my regions roughly similar sized in terms of articles (though Western Europe is rather too large and ought to be split) as much as possible - with the exception of splitting the eastern stuff in two. Then there's it being a map made for outsiders for the purpose of geopolitics. While there does seem to have been some adjustments since the fundamental change in geopolitics in the 90s (Slovenia split from the rest of Yugoslavia, the Caucasus countries split from the USSR), it reeks of the 1970s and spy networks - Free-Europe with no worries in Blues, Facist Iberia in Dark Red, German-speaking countries and the more controlled occupied countries in yellow. The 'non-aligned' and semi-autonomous commie countries in brown, the USSR in light red, the free-but-flirts-with-hard-left-government countries in green. The Baltic states have more in common with the countries over the sea than they do with other ex-Soviet nations, Greece is firmly part of the Balkans rather than some outpost of Western Europe, etc. I'll continue this discussion below. Si404 (talk) 06:25, 2 May 2024 (EDT)

Going back to the question of why "Europe" matters so much. I mean, we could just go ahead and import ROW (rest of world) so that it doesn't matter so much who gets imported first. However, there is one non-Europe request outstanding (South Africa), and there is high quality content in Japan and Australia that I don't want to defer for too much longer. --Rschen7754 15:16, 3 May 2024 (EDT)

E-roads and "meta Europe"

I don't want to distract from the larger discussion above, but it seems the first step will be importing the E-roads and other articles relating to Europe as a whole. There are some ambiguous cases, however:

• List of highest paved roads in Europe - annex? There is also a by country list [3].
• Pan-European corridors? About 10 articles.
• Trans-European Motorways, Trans-European road network?
  • We do have stuff like Corridor Q and the Appalachian Development Highway System already. My hesitation is that some of those corridors come off as multi-modal i.e. including trains and other modes of transport that are out of scope. --Rschen7754 14:43, 30 April 2024 (EDT)

I think List of highest paved roads in Europe (along with the by country list) would fit well in the annex space along with other superlative lists. I think we can cover the Pan-European corridors and Trans-European road network as they do deal with roads despite also dealing with other modes of transport. This is similar to how we have DOT articles despite the fact that they also often deal with other modes of transport besides roads. However, we can make the focus of the Pan-European corridors and Trans-European road network articles more road-centric. Dough4872 21:02, 1 May 2024 (EDT)

Agreed that the highest paved roads list is annex-worthy. I also agree that the Pan- and Trans-European articles are similar to the ADHS, so I have no problem with including them. The intermodal stuff is worth a mention, but the details are best left out. Quite a few of the city DOT articles that we imported had a lot of information about local transit that was out of scope. We just removed it and moved on. That's what we can do here. –Fredddie™ 02:00, 2 May 2024 (EDT)

Yes, that first step looks like being basically anything EU or UNECE that's relevant. One road network (the E Roads of the Agreement) and some articles about priority corridors for improvement funding. The TEM is just roads, the Pan-European Corridors are all road, save the River Danube. The EU TEN-T corridors are multimodal but they all have roads as part of them (map). As Fredddie says, we just remove the stuff that's out of scope from those articles post-importation. Si404 (talk) 05:30, 2 May 2024 (EDT)

As just a note, I plan to go ahead and create AARoads:Europe soon, and just go ahead and import all the E-roads. One thing that will have to be addressed is that some E-roads redirect to the national road since they are a 1:1 relation, and at the moment I don't plan to import those in this batch. Individual cases can be sorted out at AARoads:Cleanup or can wait until the country in question is imported. --Rschen7754 14:44, 3 May 2024 (EDT)

The following E roads are AWOL: E88 w, E89 w, E91 w, E96 w, E98 w, E115 w, E119 w, E121 w, E125 w, E201 w (redirect), E234 w (redirect), E372 w, E373 w, E391 w, E401 w, E402 w, E422 w, E441 w, E471 w, E512 w, E531 w, E533 w, E552 w, E842 w, E013 w. Si404 (talk) 07:47, 8 May 2024 (EDT)

Thanks. They can be reported at AARoads:Cleanup (I'll open a request for this one). Usually this happens when the article wasn't tagged properly on enwiki. --Rschen7754 14:26, 8 May 2024 (EDT)

Taskforces / dividing Europe

My above list tried to group countries culturally while also trying to create areas with a similar number of articles (though splitting Iberia from France/Benelux would make that easier for existing stuff) Coherent units that aren't just one country (or one with a microstate) would be: Britain and Ireland, the Nordic countries, the Baltic countries, Benelux, Western Balkans, Iberia, the Visigrad 4, German-speaking countries, etc. Like with any groupings (what states are Mid-western, for instance?) there's not really hard boundaries. The problem with these coherent units is that some are rather small (eg the Baltic nations) in terms of articles, others a bit too large (eg the Allmanophonic nations) - so I grouped them together with a similar group or split them up a bit to try and equalise numbers. My personal preference is one big project like AARoads:United_States with sub-projects for certain systems, and for each country (some could be grouped). Si404 (talk) 06:25, 2 May 2024 (EDT)

As I mentioned above, I think we can have AARoads:Europe as the main resource page for Europe with countries with a lot of resources split into their own page. Meanwhile, countries with not a lot of resources along with resources for the whole continent (such as E-roads) can be listed at AARoads:Europe. I don’t think we need a resource page for every country and I don’t like the idea of regional resource pages as there are differing definitions of regions. Dough4872 08:27, 2 May 2024 (EDT)

That makes sense. I agree fully with that. Si404 (talk) 09:17, 2 May 2024 (EDT)

I think there was some confusion with me posting the CIA World Factbook map above. It was merely an idea to discuss. Yes there are political issues with lumping Russia (for instance) in with, well, any other country, but we are not beholden to anything. Don't forget this is a wiki, we can just change it later if it doesn't work. –Fredddie™ 11:54, 2 May 2024 (EDT)

On AARoads we are one team of editors. That was one of the mistakes of English Wikipedia, we started off as teams of individual US states, and then figured out that didn't work, and had to reorganize into a national team (and went through a lot of drama in that reorg). And the non-US/Canada editors were never really integrated into that, which is one of the causes of the problems alluded to earlier.

So it comes down to where to list the resources, as well as assessment (though I am hoping that individual countries can get a statistical breakdown). --Rschen7754 14:37, 2 May 2024 (EDT)

Of course I saw the CIA map as an idea to discuss - hence why I discussed it! Looking back at what you said about the map (perhaps a mistake as it made me more annoyed), you said "If nothing else, it's at least something." - that phrasing (especially the italicising) is rather rude - and you are keeping up this idea about the CIA map was proposed as some sort of discussion starter despite there already being something to discuss! Trash my earlier proposal, by all means - I don't agree with it, but provide reasons why rather than ignore it. In fact, I wouldn't even have minded if it was ignored - if it was in a tumbleweed sense rather than a 'we have nothing, here's something' sense. As Rschen says, we need the non-US/Canadian editors integrated. I don't think that gets done by ignoring proposals by such editors talking about their home turf, in favour of low effort copied proposals by a US organisation that are only tangentially related to the topic at hand. Si404 (talk) 12:43, 3 May 2024 (EDT)

Without stepping into specifics just yet, it does seem like grouping countries could have political overtones. But on the other hand, I don't want AARoads:Vatican City. (And I don't want to import part of Russia and not all of it). --Rschen7754 14:14, 3 May 2024 (EDT)

I lean more towards Si404/Dough's latest thoughts about splitting out certain countries, but then we have to be concerned about which countries get split out. As I said above - it's not meant to carry wiki political overtones or real world political overtones, unlike English Wikipedia. This is really just a place to store the resources, and (maybe) as the line item for assessment (but I am hoping that it can just be split by country regardless of size). But if it will carry hidden meanings and we can't avoid it, then we need to factor that into the decision making process. --Rschen7754 14:54, 3 May 2024 (EDT)

Ultimately, I don't care how we divvy up the countries. One idea that has popped up in my DMs is that if a larger country shares its road network with a much smaller neighbor (San Marino, Liechtenstein come to mind), maybe we don't need separate task forces. –Fredddie™ 01:44, 4 May 2024 (EDT)

Maybe that is what we do for Monaco, San Marino, Vatican City, Liechtenstein. Andorra is the next smallest country, but has ~50 potential articles. --Rschen7754 02:21, 4 May 2024 (EDT)

Spain

So it seems like there are interested editors for Spain. This is my understanding of Spain.

• E roads - import
• AP - motorway - autopista - import
• A - expressway - autovía - import
• R - radial motorway - import
• N - national road - import
• C - regional road - import
• Community/Provincial roads - some provinces have a higher level for expressways, a normal level, and/or a lower level (communities are collections of provinces) - are listed as tier 5 on TravelMapping. Do we import these? (This is the part I'm not 100% sure about - how the regions/provinces/autonomous communities all relate to road maintenance).
• Local roads - should not be imported.

Is this correct? Any further thoughts? --Rschen7754 18:20, 5 May 2024 (EDT)

Also - we should talk about names. We have "A-1 (autovía)", but then "Autovía A-2". Also - do we keep "Autovía" or just drop it and leave it as A-2? (But then we probably have to put something in for disambiguation so we might as well just leave it?) For the N roads we have "N-4 road (Spain)" - but there are a few M roads called "M-45 (Spain)". The E-roads have "European route E1 in Spain" which seems a little redundant. --Rschen7754 18:25, 5 May 2024 (EDT)

A-nn becomes a little murky in Andalusia, where A- is the prefix for that autonomous community. I think Autovía A-nn is enough to disambiguate, but for Andalusia A-nn (Andalusia) would be in order. Quite a few of the articles listed in w:Category:Transport in Andalusia are misnamed (they're not all autovías). –Fredddie™ 20:24, 5 May 2024 (EDT)

Expanding further, Spanish roads are sort-of color coded. I made a chart in the before times at WP:HWY/RM/R where I sort of explain it (tl;dr: blue, green, orange, and red should be included here). –Fredddie™ 20:31, 5 May 2024 (EDT)

To further complicate things, eswp uses names for motorways (I prefer to use this term for both AP and A, as there are practically no standard differences, the only one being if it is/was tolled). I'd go for "Autovía A-2" and so on. As for colors, I'd definitely add yellow as a few regions use it and it's also the standard for provincial roads. Leudimin (talk) 10:54, 7 May 2024 (CEST)

And the colour coding is more important than prefixes for what class the road is - the prefixes tell you where the road is/who looks after it, the colour is about standard/importance (though the maps my parents gave me from their recent holiday in Lanzarotte are terrible at showing the correct colours of the cartouches, which are all LZ-prefixed!)

Blue, Red, Orange (and Green E Roads) is what I included on TM. In many Autonomous Communities that's quite a decent network, but in others (eg Andulucia where it's mostly Autovia/future Autovia corridors) its pretty threadbare and the next layer down is quite important. Definitely at least listicles for Yellow, Green and Purple, but possibly full articles depending on how the AC does things. Si404 (talk) 13:07, 7 May 2024 (EDT)

1. The "regional roads" mentioned above as "C -" are extinct nowadays (not to be confused with Cataluña's road network). The list of regional roads can be imported from this Wikipedia page and, to my eyes, would work best as a separate page.

Additionally, if desired, the historic list of national roads can be taken from this blog page.

2. "AP" actually stands for Autopista de Peaje, Autopistas that were never tolled such as the A-49 bear just the letter A, which stands for both "autopista" and "autovía". These two should be imported into the same list page.

3. Autopistas and autovías owned by Spain bear names (such as A-7 being Autovía del Mediterraneo). I believe these names are relevant enough to motorways that their articles should be titled as this instead. This and my other thoughts on naming conventions, I will add in a moment to the AARoads:Naming conventions page. Shedingtonian (talk) 12:58, 7 May 2024 (CEST)

About importing from eswiki: we do have the technical capabilities to do that, though I do need to make some minor code changes. I would need a list of what is needed to be imported, though. Also, this would likely take place after everything from enwiki on Spain is imported. --Rschen7754 14:47, 7 May 2024 (EDT)

So would this work for naming conventions:

• Autopista AP-nn/A-nn
• Autovia A-nn
• A-nn (Andalusia) – for non-autovias
• pre-nn (region) – pre = regional prefix (R, B, C, M, Ma, etc.) and region = autonomous community or province
• N-nn (Spain) – national roads

I think every article should be disambiguated consistently. Enwiki would only disambiguate as necessary and it gets confusing which ones are or are not disambiguated. –Fredddie™ 16:08, 8 May 2024 (EDT)