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)
  • I know this discussion is old, but maybe the Annex for the specifics? OrdinaryGiraffe (talk) 00:24, 12 June 2024 (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)


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)


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)
Autovía should have the accent.
Eyeballing the proposals, the biggest differences I see:
  • (Andalusia) versus (Andalusia, Spain) (also, AA:NC has a different spelling)
  • Using the named motorway (in addition to? in place of?) the number. I would be opposed to in place of, as we strongly tend towards using numbers whenever possible. (Not sure what we will do with Australia where we might not have a choice). In addition to - it's not unprecedented (see China on enwiki), though it makes maintenance a bit more tricky and requires redirect creation right away. --Rschen7754 21:09, 9 May 2024 (EDT)
Andalusia is the English spelling so we should go with that. I don't think it's necessary to use ", Spain" in disambiguators more than necessary. I have two problems with naming articles by their denominación. One, AA:TITLES says we should name the article by the route number and create any pertinent redirects. Remember, we've moved some Florida articles back from their road names to their route numbers. That all being said, I don't see anything wrong with Autovía A-1 starting with "The Autovía del Norte (Spanish for 'Northern Motorway'), numbered A-1, is...". And two, even if we did use the route names, not all of the roads have them, so that would create the inconsistency we don't want. –Fredddie 03:29, 10 May 2024 (EDT)
Yeah, honestly what you're saying makes sense, it'll be easier to have the name of the motorway or road at the top of the article. Though I don't understand the distinction of using the accent in "autovía". If one word can retain its accent and original spelling, why cannot area names, doubtlessly more relevant, also bear their actual accents and spellings?
Also, something I just realized going off of the structure of the other listed article titles, shouldn't the structure be more like "Spain A-X Autovía", "Cantabria CA-X road", "Guadalajara GU-X road (Spain)"?
(I reckon I should've realized this before writing all of that stuff in the AA:NC page, oops-)
And also something else, the main reason for writing (region, Spain) as opposed to (region) is duplicate names, for example Guadalajara Spain versus Guadalajara México. One could mistake a highway for being in one region instead of the other if they were only going off of the article's title. Shedingtonian (talk) 12:49, 10 May 2024 (CEST)
Looking at M-x (Michigan) and K-x (Kansas) as the already decided alphanumeric article title formats (which is very different to the numeric titles' <type in words> <number> format), with reference made to global ones in the decision making, presumably the consistent format is <route number> (<jurisdiction>)? Therefore Spain would be
  • AP-nn (Spain) / A-nn (Spain) / N-nn (Spain) / <city-prefix>-x (Spain) for national roads
  • <relevant prefix)-nn (autonomous community) for autonomous community roads
This pre-existing convention also means a lot of other European countries already have their naming convention sorted, not just Spain.
'European route Enn' would need changing to 'Enn (Europe)', but given that officially the network is called the 'international E-road network' (AGR Article 1) with the routes called 'E-roads' (AGR article 4.2) and the only use of the term 'European' in the AGR is referring to the title of the Agreement "European Agreement on Main International Traffic Arteries (AGR)", keeping the wikipedia made up term 'European route' ought to go anyway! Si404 (talk) 07:34, 10 May 2024 (EDT)
Just using a couple routes in Castilla–La Mancha for example, it would be "A-40 (Spain)" and "TO-21 (Castilla–La Mancha)", right? I'm OK with that. I'm also OK with E-roads going to "E-nn (Europe)". –Fredddie 11:02, 10 May 2024 (EDT)
It would be "A-40 (Spain)", "TO-21 (Spain)" as a city-prefixed route that's part of the national network (it's listed here with the AP-n and the A-n and the N-n roads), "CM-40 (Castilla–La Mancha)". Si404 (talk) 13:10, 10 May 2024 (EDT)
PS: we only add states to 3dis if they aren't unique - cf Interstate 787 (whose 2di needs a state disambiguation). Due to being uniquely numbered in the country, routes like TO-21, B-20, M-40, SE-30, etc should have their page titles formatted in the same way as intercity routes like A-1, N-III, AP-8, N-634, etc. It's just a different way of doing spur/loop routes. Si404 (talk) 13:20, 10 May 2024 (EDT)
I do think the E-roads should be changed per the above.
The reason we went with the numeric titles (see /Archive 1) that we did was mostly inertia; however either way we went, something was going to be inconsistent. We had concerns about New York, where the official name is "New York State Route", which would be inconsistent with "State Route x (California)".
We should probably figure out how much we translate to English and how much we don't. To preview some of the weeks ahead, we have A2 autostrada (Poland), Voivodeship road 119, Otoyol 7. I think that will answer some of the questions above.
Also, I think we should be consistent with disambiguation, and would lean more towards using the region (we don't call it M-25 (United States)), but Guadalajara is famous enough even though it is just a city, and probably will be confusing. --Rschen7754 11:05, 10 May 2024 (EDT)
Would it be "A2 autostrada (Poland)" or just "A2 (Poland)"? Do we need to have the system description given it's in the alpha bit of the alphanumeric thing? They only exist because Wikipedia covers more than roads. Voivodeship road 119 / Bundesautobahn 100 are all numeric-only with the shield design telling you the network, and the "<system> <number>" format would be per the existing principle created for US/Canadian roads (leaving aside the stuff that arises from Voivodeship being semi-translated, road being definitely translated, but the German terms are not translated). "Otoyol 7" would be O.7 (Turkey) as alphanumeric on signs.
The Guadalajara routes memtioned are way down the pecking order - below 4-digit Autonomous Community roads - I can't imagine we'd have anything more than a listicle (and it's the province, not the city, and OSM shows no GU-roads near the city itself). Si404 (talk) 13:10, 10 May 2024 (EDT)
So on one hand, I lean more towards using the English name for place names, for ease of use (and linking back to enwiki place name articles). But then, we aren't translating out road system names consistently either. We could omit them entirely when the name isn't official, but then for some countries there are article title distinctions between motorway and highway and road. And Voivodeship Road 119 is probably not sufficient for a title either. --Rschen7754 14:25, 10 May 2024 (EDT)
Yes, for me, it's less an issue of whether we translate or not, but consistency in doing so. Si404 (talk) 14:57, 10 May 2024 (EDT)
Do we need to have the system description given it's in the alpha bit of the alphanumeric thing? Probably not in the particular case cited, and maybe where it makes sense it should be cut out. A- can mean both autovía and autopista in Spain though, so we still have that problem.
Some other thoughts about translating versus not: the countries are place names too, and I don't want to disambiguate with N-nn (España). It gets even worse for non-Latin languages. But then we have to be concerned about transliteration. --Rschen7754 20:09, 10 May 2024 (EDT)
Autopista and Autovia, while not interchangable terms, are indivisible terms. Not only does English Wikipedia put both together, inseperately, but Spanish Wikipedia does too. 'that problem' is only a problem if we go out of our way to make it one. Si404 (talk) 17:51, 15 May 2024 (EDT)
As an update, I still anticipate importing Spain this weekend while we're still hammering out the naming conventions - we can always move them later (as I suspect will happen with the E-roads pretty soon). --Rschen7754 14:21, 10 May 2024 (EDT)

Poll: naming conventions

It seems that these questions will come up with just about every country, so we might as well attempt to address them now. Ideally this would be additional Guidance under AARoads:Content policy#Article titles. There could be other proposals added. --Rschen7754 20:05, 11 May 2024 (EDT)

Didn't realize this poll was intended to be global in nature, since it's under the "Spain" section. Makes sense to do it systematically though. – Minh Nguyễn 💬 21:31, 19 May 2024 (EDT)
This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

The proposal passes. --Rschen7754 12:47, 27 May 2024 (EDT)

For route numbers with alphabetic prefixes, words that are entirely redundant to the meaning of the alphabetic portion of the route, or are generic ("road", "highway") should generally be omitted.

Example: E23 (Europe), N1 (France)

  • Support. --Rschen7754 20:06, 11 May 2024 (EDT)
  • Support—since we're a roads wiki, the extra words would be generally assumed. That's why we moved "M-1 (Michigan highway)" to just "M-1 (Michigan)" after all. Imzadi 1979  20:19, 11 May 2024 (EDT)
  • Support - I think this naming convention works well for routes with alphabetic prefixes. Dough4872 22:06, 11 May 2024 (EDT)
  • Support - reasons already given by others. Si404 (talk) 08:52, 12 May 2024 (EDT)
This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

The proposal passes, with the note that the common English name should be used rather than overtranslating names that are commonly used. --Rschen7754 02:35, 5 June 2024 (EDT)

Place names used to disambiguate (as a suffix or a prefix) should be translated to English.

Possible addendum: Where there is doubt, the title used by English Wikipedia for the locality should prevail.

  • Support. Because if we don't, we run into a whole host of problems (non-Latin alphabets, multiple languages spoken in a locality, using non-English country names, etc.) --Rschen7754 20:06, 11 May 2024 (EDT)
  • Support—our working language here is English. Imzadi 1979  20:19, 11 May 2024 (EDT)
  • Support - Since this wiki is in English we should translate place names to English. Dough4872 22:06, 11 May 2024 (EDT)
  • Support, with caveats - the standard English name should be used (eg Spain rather than España), but names shouldn't be translated if they aren't in common English usage (so Lower Saxony rather than Niedersachsen, but Alpes-Maritimes rather than 'Maritime Alps' for the French department). I believe this is what is being proposed anyway, but the phrasing is a little off - "Use English language place names for disambiguation" rather than "translate names into English" - the latter suggests that road in Beijing should be disambiguated with 'North Capital'! Si404 (talk) 08:52, 12 May 2024 (EDT)
    • That is my intention (and it would be covered by the addendum if we decided to go that route). --Rschen7754 19:34, 12 May 2024 (EDT)
  • Support – Minh Nguyễn 💬 21:31, 19 May 2024 (EDT)
This discussion has been closed and is preserved as an archive of the decision of the community. Please do not modify it!

Where practical, system names should be translated to English, using an agreed-upon title. Exceptions can be made for system names that are used relatively commonplace by English speakers or where there is no direct translation. --Rschen7754 02:10, 8 June 2024 (EDT)

System names should be translated to English, using an agreed-upon title.
  • Support—our working language here is English, as I noted above. We should give the names in articles in their native form, but our primary usage will be in English. Imzadi 1979  20:19, 11 May 2024 (EDT)
  • Support, with caveats I think that generally this is the principle that should be used. We should mitigate this as much as possible by omitting it when it is unnecessary, such as the Turkey example given above. Not sure what this would mean for Bundesautobahn 27 - it could just be A27 (Germany), but I am not sure what that means for the Interstate system, which is another system that has an official abbreviation that does not appear on the signs. I am not entirely sure about the autopista/autovia question above; in cases where there is not a 1:1 translation or where the foreign word is used even in English-language media, we should consider exceptions. --Rschen7754 20:35, 11 May 2024 (EDT)
  • Support - We should translate system names to English unless there is no direct translation. Dough4872 22:06, 11 May 2024 (EDT)
  • Support, with caveats While it is pretty obvious to translate 'Routes Nationales', 'Državne Ceste', 'Estradas Nacionais', 'Rutas Nacionales', 'Εθνικές Οδοί', 'Nationalstroossen', 'Drogi Krajowa', etc to 'National Roads', subdivisions get a big shaky - 'Drogi Wojewódzka' - would have a direct translation of 'Dutchy road' but we would probably go with Voivodeship road, which is not a full translation into English. Again my issue is more with the 'translate' wording than the principle. Rschen's point about where we use the foreign word in English (cf my similar point about place names) is also true - we do say 'autobahn', 'autoroute', etc in English. We'd even say 'Route Nationale' in conversational English (eg I didn't want to pay the autoroute toll, so I took the route nationale instead'). The same happens with railways - we tend to use local terms (no one says 'I went on the London Subway', 'I went on the Paris Underground', 'I went on the New York Metro', etc) if they are going to be understandable. Si404 (talk) 08:52, 12 May 2024 (EDT)
  • Support, with caveats - I think the guiding principle here should be the accessibility of the title to a user who only speaks English. This means something like 'Državne Ceste' absolutely needs to be translated but local language terms that are easy on the native English speaker's tongue like 'Autoroute', 'Autostrada', etc. are best left alone. Duke87 (talk) 21:14, 19 May 2024 (EDT)
  • Support with caveats. Sometimes English accepts loan words (with little rhyme or reason), which we can be pragmatic about. Additionally, translations from some languages can be imprecise or create their own ambiguities. The article text should provide the native name at the earliest possible opportunity (i.e., in the lede sentence and any infobox). Attested translations are preferable to ad hoc translations. In case of doubt, a more specific poll can resolve the question by country or system. – Minh Nguyễn 💬 21:31, 19 May 2024 (EDT)

Resuming the Spain discussion

@Fredddie, Leudmin, Shedingtonian, and Si404: So coming back to this once the above discussions have been closed. It seems that Autopista and Autovia are not in the proposed naming conventions [2], so there is that. It seems that we have decided to drop the words "motorway" and "road", so we will need to drop those from the proposal. Also, I have a significant issue with using official text names for what appear to be less major routes; that violates our norms on using the number instead. (There is of course the Australia question; however, here we're talking at the level of provincial highways, and provinces are a level down from territories in Spain). --Rschen7754 02:20, 8 June 2024 (EDT)

@Leudimin: (correct name this time) --Rschen7754 02:22, 8 June 2024 (EDT)

South America

We had decided to postpone South America due to lack of interest; however, there is now an interested editor. Should we go ahead and import South America? I would suggest delaying Brazil (the lists are a mess and there are a few hundred stubs, plus the language is Portuguese and thus requires different language skills) and French Guiana (as part of wanting to import dependencies with the main country). That comes out to less than 150 articles - which is still less than just the E-roads in the last import.

This is a bit of a change of direction, but I think to maximize growth we should not delay requests to import too much longer. Spain is still the next country to import. Following South America, I think we should fulfill the remaining requests (Georgia, South Africa, one potential in Malta) before continuing on with Europe.

There will need to be some discussions for most countries about what gets imported and what does not. Suriname and Guyana don't have numbered systems and just a few primary highways, so those seem pretty obvious. Also, we will need to figure out task forces; I think there could easily be ones for all of them except maybe Suriname and Guyana, but leaving them separate wouldn't be a big deal. --Rschen7754 17:57, 11 May 2024 (EDT)

I think we should import South America (minus Brazil and the dependencies) next since there is an editor interested working on articles there. I also agree we should get the rest of the requests imported before moving on with the rest of Europe so we don’t keep editors waiting. As for the rest of South America, we can import the dependencies with their parent country and hold Brazil to a later date since it’s a mess and we should prioritize better content from other countries. As for task forces, I think we can lump most countries into one task force for South America and split out where needed for countries with more resources. Dough4872 22:13, 11 May 2024 (EDT)
If someone is interested, lets import Spanish South America (and thus complete the Spanish-speaking countries, save Equatorial Guinea). Si404 (talk) 17:33, 15 May 2024 (EDT)
Going through my notes:
To prevent a separate discussion for each country, I propose that we import national and provincial/departmental routes for the Spanish-speaking countries (plus Suriname/Guyana as above), and any lists/system description pages as appropriate. Other deviations:
  • Venezuela will need some fixing to use numbered routes instead of named routes
  • [3] is a trade corridor. Still import?
  • [4][5] are not numbered but still notable as a freeway.
  • [6] is a 1950s road, still import?
  • Chile has some scenic/tourist routes, [7] and [8]
  • No idea what the hell this is [9].
  • [10] seems interesting enough to import.
  • The following systems would not be considered notable enough at least for their own articles (if at all): Colombia tertiary highways, Ecuador local highways, Peru rural roads, Venezuela ramal routes. --Rschen7754 20:56, 15 May 2024 (EDT)
Thank you very much for informing me about this
  • Venezuela uses a "troncales" system, it can be a bit tricky because the country has a federal system, but it is not as difficult as other big countries like Peru or Argentina)
  • Regarding the Interoceanic Route, we can simply add information to the routes of Madre de Dios and other Peruvian departments, most of the route covers parts of Acre and Rondonia so it would be a bit more complicated to collect information.
  • Costa Verde in Peru receives the code "Ruta departamental CL-100" for Callao and Lima while "Autopista Rosario-Córdoba" is a single section of Ruta Nacional 9, so both roads receive official codes, I don't know why English Wikipedia doesn't have them but the Spanish one does.
  • It would be better not to import it, the infrastructure in Argentina has changed a lot and it would be a mess to try to add historic roads.
  • With respect to the scenic routes in Chile it is better to avoid them since they are largely used by tourist organizations and do not really work as normal roads.
  • MERCOSUR is practically a small European Union in South America, vehicles from the south of Brazil can circulate freely through Uruguay and some areas of Argentina, basically that article stipulates which roads are used for commercial routes in those countries. So it is better not to import it.
  • I agree, we should not import rural roads because they are mostly unremarkable roads.--DigitalSeb01 (talk) 22:03, 15 May 2024 (EDT)
  • Will begin importing soon. Just as a note, Camino de las Altas Cumbres is linked to [11], so I will go ahead and import. --Rschen7754 21:01, 22 May 2024 (EDT)

WikiConference North America 2024

Hi, I know many of you have also edited on Wikipedia & other Wikimedia projects. I would like to invite anyone who edits here & who plan to attend this year's WikiConference North America (WCNA), (4-6 October 2024) to consider submitting a proposal for a session there. It would be great to have a session on AARoads!

Appropriately, the theme for WCNA 2024 is Crossroads, inspired by this year's location in Indianapolis.

You can find session types described here & program tracks described here. You can create a submission from here.

I hope to see you there! Peaceray (talk) 01:27, 20 May 2024 (EDT)


This is a formal request to install mw:Extension:CheckUser. The last few days have shown me that the tools would be useful. –Fredddie 21:06, 24 May 2024 (EDT)

So I think the big thing that we need to discuss is expectations around use. CheckUsering (CUing) spambots is one thing, but CUing real people is another. Plus, we don't want to run afoul of California or the EU, which both have specific privacy regulations.
The current status quo of having to look at server logs (which Scott, Alex, and I can do since we have server access) is not sustainable and provides no filter (in other words, everyone's addresses can be seen). Unfortunately we can't get away from that entirely as CU does not work for the misbehaving web crawlers that impact server performance. But having the tool would help.
But we should work out the following:
  1. who should have access (all admins? all crats? or require a separate discussion?)
  2. when can it be used
    1. anti-spam
    2. to determine abuse of multiple accounts (what level of proof would be required?)
  3. what can be done with the information
    1. I assume we do not want to allow explicit statements about real user = IP onwiki.
    2. Do we have to worry about the same admin blocking the IP right after the named account, implying a connection?
    3. Can the information be given to AARoads Forum admins in certain cases?
  4. do admins who are not CUs have the ability to overturn blocks made by a CU, using CU information? (and maybe the admin policy needs to be further developed)
All big questions that should be addressed. --Rschen7754 21:18, 24 May 2024 (EDT)
Can bureaucrats place a block that administrators cannot undo? –Fredddie 21:31, 24 May 2024 (EDT)
I think the issue on enwiki has been that non-admin CUs don't have the ability to review the technical CU information, and with over 1000 admins the chances of one of them making a poor decision were pretty high. Maybe we don't need a formal prohibition as a smaller wiki. --Rschen7754 21:36, 24 May 2024 (EDT)
I get that, but that wasn't the question I asked. I meant it from a technical aspect, similar to the ability to lock a page by permissions level. –Fredddie 21:38, 24 May 2024 (EDT)
Not without a code change, no. --Rschen7754 21:38, 24 May 2024 (EDT)
I support the installation of the extension. As an initial grant, I'd add CU to the 'crat rights, but also make it a user right that could be granted to others to fill out a corp of CUs.
CU should be used for anti-spam and socking situations. I wouldn't not support on-wiki disclosure of CU details. I'd say that we could share details between AARW and AARF as needed if there were specific situations that warranted it. Imzadi 1979  22:12, 27 May 2024 (EDT)
For full transparency: Scott and I as the active server admins do have the full access to the server logs, which includes IP information (not user agents). Are we doing anything with the information, except for that one investigation, and dealing with read-only web crawlers, no. We're struggling to keep the server in a performant state as it is. We are the only bureaucrats (besides Alex). Will crats be granted full access to the server? It depends on skillset really.
Would I support giving it to all admins? I hesitate a bit because there are a few that are mostly inactive, and because CU does require a certain level of technical expertise. There is also a higher bar of trust, plus the legal issues given below. But I don't know that as a community we are large enough to support another round of rights discussions. --Rschen7754 22:40, 27 May 2024 (EDT)
All the more reason to enlist some aid where needed and appropriate. Imzadi 1979  23:38, 27 May 2024 (EDT)
We also should address how to handle removal of the tools. If adminship is removed for any reason, then CU should be removed; also, there should be a voting process if the community loses trust. --Rschen7754 14:10, 28 May 2024 (EDT)
Also, for legal reasons I believe we should ask candidates to affirm they are over 18 and over the age of majority in country of residence, and ask that they disclose their country of residence (there are significant issues with giving CU access in places like Iran or even China). --Rschen7754 02:07, 27 May 2024 (EDT)


To fulfill the remaining Europe requests, I propose that we import the country of Georgia. There are only ~15 articles [12], most of them S articles (that should be renamed to be S-X (Georgia), removing "highway").

As for the future, I would consider the S and Sh (secondary) articles to be notable, but the A (local/municipal roads) might not be. --Rschen7754 12:46, 27 May 2024 (EDT)

@Labrang: --Rschen7754 12:46, 27 May 2024 (EDT)
I think importing Georgia is logical since there is interest and it won’t be too many articles to import. Dough4872 23:35, 27 May 2024 (EDT)
read - and yes, i am available to guide this from the content part. Note on notability: A-roads are not notable indeed. These are all local roads that are administered and governed through the municipal bodies - henceforth every municipality distributes numbers (ie there are 50+ A-XX roads - and it runs into the hundreds depending the municipality). Also most Sh-roads are not notable. There are up to a few dozen out of the 209 that have a certain degree of notability, ie a few long distance interregional roads or access roads to (remote) mountain valleys that are well known - such as to Svaneti (Mestia), Shatili or Tusheti. Labrang (talk) 04:54, 30 May 2024 (EDT)
There are other options as well for intermediate cases, such as what are called listicles (AA:RCS). --Rschen7754 14:43, 30 May 2024 (EDT)
That could be an option for a selection of Sh-roads. Not a first priority, but further "down the road", so to speak. Labrang (talk) 02:59, 31 May 2024 (EDT)
@Labrang: Could you verify that I have AA:NC right for Georgia? I didn't use a hyphen when I renamed just now. I also see the infobox on S1 (Georgia) has A 1 listed, which seems confusing given that there are other A roads. --Rschen7754 22:05, 5 June 2024 (EDT)
well noted - somehow I missed that in the infobox. That should be S1. In official documents the hyphen is used, but on corresponding road signs and other communications the hyphen is absent. I am not sure what should be the practice in that case here. Labrang (talk) 03:19, 6 June 2024 (EDT)
My personal opinion is that we should go with the hyphen then (similar to Michigan which is in a similar boat), however others might disagree so I want to give room for comment. --Rschen7754 20:05, 6 June 2024 (EDT)
Please correct me if I have it wrong: official documentation uses the scheme S-<route number>, while informal documents and signs use the scheme S<route number>. I ask, which is more likely to change? Based on my experience in the US, informal documents are never consistent, and change frequently. Signs can change over time as well, however the pace is usually a slow change. However the official documents tend to be constant and consistent. For that reason I would support the official practice S-<route number>. However, I don't have strong feelings either way, and if someone can make an argument that the situation is different here and the S<route number> is more likely to be stable and last for the long term, I could be convinced to change my opinion.Dave (talk) 22:37, 7 June 2024 (EDT)
In response to your question on "likely to change": the dash has been used in the early 2000s on road signs (see this 2004 photo in Commons). However, before 2010 they have already been phased out, replaced by the indication without a dash. None of the new road signs (be it replaced or in newly opened road sections) have a dash. To my recollection, having driven thousands of miles across the country spanning many years. But that is still a more or less anecdotal observation - which can be corroborated by the dozens of photos in Commons. However, the latest officially updated road list of 2022 (the list is confirmed by government/parliament every 5 years) maintains the dash. I don't have a strong preference. There's something to say for the officially documented format/convention, while at the same time the practice on the ground also has a value. We can stick to the official format, and then make a short remark on it - either at the individual road or at the general (Georgian road) system page Labrang (talk) 06:47, 8 June 2024 (EDT)
I will go ahead and move to use the dash. --Rschen7754 13:01, 15 June 2024 (EDT)

Assessment and Preliminary WikiWork

Thanks to @Fredddie:, we have initial assessments applied to our articles based on their Wikipedia assessments, as translated to our assessment scale. Articles on Wikipedia that were Featured Articles or A-Class are A-Class (blue) here. Good Articles there are B-Class (dark green) here. B- or C-Class there are C-Class (yellow-green) here. Start-Class there is D-Class (orange) here, and Stub-Class there is E-Class (red) here. Each class has a color assignment as previously noted, and article titles will appear in that color with the assessment spelled out in the tagline below it.

On Wikipedia, USRD pioneered the use of a statistic called WikiWork. Now that initial article assessments have been added, we have some initial stats, we can start computing WW values for the project. Once we enable regional tagging in the assessments, we can break out the stats by regions.

As of May 27, 2024:

Class Count ω ω Factor
A 115 0 0
B 1,306 1,306 1
C 5,490 10,980 2
D 4,953 14,859 3
E 3,285 13,140 4
Total 15,149 40,285 N/A

The Ω, or average WikiWork is 2.659, meaning our average article is currently between a C- and a D-Class in terms of quality.

In the future, Lists will be assessed on a similar scale and can be factored into WW stats. Featured Lists (FL-Class) on Wikipedia are AL-Class, aka A-Class lists. There are BL-, CL-, DL- and EL-Classes in the scheme, and List-Class will eventually be retired as lists are assessed into the appropriate classes. Accounting for the AL- and List-Class counts of 11 and 1,091, and putting List-Class as equal to EL-Class, we get an overall total ω of 44,649 and a Ω of 2.747. Imzadi 1979  14:35, 27 May 2024 (EDT)

Community/city/destination lists in lists

I've been converting various Canada provincial highway lists to use Template:Routelist row. Nova Scotia does have a destinations list in some of the tables, but our template does support it so I went ahead and converted it to not lose data: List of Nova Scotia provincial highways.

But then we have List of Prince Edward Island provincial highways, which has both a local names column and a destinations column, and our templates do not support adding both. Should we add support for another column? Or in order to standardize with other lists in the US, should one or both of those columns be removed entirely? I will note that International E-road network also has a destinations column. --Rschen7754 23:58, 2 June 2024 (EDT)

I think we can add support for another column since the table needs in different countries and subnational units of the world will vary. For some places, it might be more useful to list destinations served than in other places. Dough4872 00:17, 3 June 2024 (EDT)
A few more cases in point:

United States and Canada task forces

Originally the state and provinces were created as separate task forces. However, this will conflict with the country of Georgia. Also, most countries are just getting one task force, if that. Should the task force pages for the US and Canada be moved to subpages? Example: AARoads:United States/California. --Rschen7754 01:26, 3 June 2024 (EDT)

I had originally tossed out the idea of such a scheme, but instead of using the military-derived terminology, we'd have Departments for each country, and Bureaus for major subdivisions. So yes, the states should be moved to that scheme and placed under the US, provinces should be placed under Canada, etc. Imzadi 1979  01:43, 3 June 2024 (EDT)
Surely a simple disambiguation in the names of the taskforces (and a note pointing people to the other one?) would deal with the Georgia 'problem'? Si404 (talk) 05:14, 3 June 2024 (EDT)
I am okay with moving the state/provincial task forces in the US and Canada to “AARoads:United States/Statename” and “AARoads:Canada/Provincename”. However, I am also okay with also leaving the current titles while moving the state of Georgia task force to AARoads:Georgia (U.S. state) and having the country of Georgia at AARoads:Georgia (country). Dough4872 09:33, 3 June 2024 (EDT)
Considering, the equivalent on WP is w:WP:WikiProject U.S. Roads/Georgia, I think we're safe to do the same here now that we're branching out. Imzadi 1979  22:02, 3 June 2024 (EDT)
As just a note, I will create the task force at AARoads:Georgia (country) just so we can get started, but the page can be moved. --Rschen7754 23:08, 3 June 2024 (EDT)

Manual on Uniform Road Articles

The first edition of the Manual on Uniform Road Articles (MURA) is now out. It still needs a section added on style guidelines for media formatting, but all of the basics for structuring and formatting a road article are in MURA. Imzadi 1979  23:58, 6 June 2024 (EDT)

Thank you for your work on this. One thing that will probably need to be addressed soon is the regional variants of English - while I think for the Americas American/Canadian English is fine, that is probably not okay for Europe. --Rschen7754 00:05, 7 June 2024 (EDT)

A-Class and B-Class criteria

I've created the first drafts of AARoads:Assessment/A-Class criteria and AARoads:Assessment/B-Class criteria. These are to be the standards by which we judge if an article merits either of those grades. The B-Class criteria borrows heavily from Wikipedia's GA criteria, but it's been modified a bit for our circumstances. The A-Class criteria uses the same 6-item list concept, but uses the more stringent concepts from Wikipedia's FA criteria. A few criteria are the same on each list. Imzadi 1979  21:16, 7 June 2024 (EDT)

One thing that could be clarified is what "high-quality" is. Does that exclude self-published roadgeek sources?
Also, or line if the content is not in prose will that cause problems with RJL? --Rschen7754 21:36, 7 June 2024 (EDT)

South Africa

I propose that we fulfill the remaining outstanding request and import South Africa. It is about 500 articles. South Africa has been an AFD target over the last several months as well.

That would be:

  • N - national route
  • R - provincial route - 2 digit
  • R - regional route - 3 digit
  • (theoretically there could be D - district roads, but no articles)
  • M - metro routes - by city. They are on the borderline of what enwiki would tolerate - some are freeways, but as they were city routes they were not automatically notable. This is probably something that merits discussion here.

The existing naming follows the new standard of Axx (disambiguator) so I suppose we just leave it as is.

There are various other ring roads and other roads; nothing stuck out to me as being entirely out of scope. --Rschen7754 20:41, 9 June 2024 (EDT)

I agree on importing South Africa next because there is an interested editor and the articles were recently targeted on Wikipedia. I think we can look into making RCS lists for the metro routes as some of them may not be notable enough for individual articles, as evidenced by the merges and deletion discussions involving them on Wikipedia. Dough4872 21:13, 9 June 2024 (EDT)
I think Metropolitan Routes deserve only list articles at the moment, kind-of-like the article currently named List of Metropolitan Routes in South Africa on Wikipedia. Only for a few of them do I endorse having articles, like M1 (Johannesburg), M2 (Johannesburg), M3 (Cape Town), M4 (Durban), M4 (Pretoria), M5 (Cape Town) & M13 (Durban), as they are important freeway routes in the municipalities that they serve. So, yeah, I suggest we mainly focus on the articles that are part of the National Routes, Provincial Routes & Regional Routes categories. Chils Kemptonian (talk) 14:44, 11 June 2024 (EDT)
I will import, but I am holding off a day or two to let the dust settle with the assessment first (to reduce server load). --Rschen7754 02:05, 16 June 2024 (EDT)
While I'm still waiting for the dust to settle down for the main import, I did create AARoads:South Africa just now. --Rschen7754 22:28, 17 June 2024 (EDT)


I'd like to formally introduce article assessments to the AARoads Wiki. I went back and forth on how we should do a project banner and I think this is the most efficient way for us. Those of us who were or still are Wikipedians will recognize the system used as Template:WPBS. For any topic that we want to assess, there needs to be a small banner template that uses {{#invoke:WikiProject banner|main}}. Then, these small banners are placed within the first unnamed parameter |1= of {{Talk header}}. For instance, a state highway in Iowa falls under AA:US, AA:Iowa, and AA:US/SH, so we place three banners {{Banner/USA}}, {{Banner/Iowa}}, and {{Banner/USSH}}, respectively, within the talk header like so:

{{talk header|class=C|

Talk:Iowa Highway 1 demonstrates how it looks. If you notice, the class parameter in the talk header is inherited by the banners automatically. Slick! Any article flags, such as |needs-map= or |attention-rjl=, are placed in the talk header {{talk header|class=C|needs-map=yes|.... The Talk header doc page has more information on all of the article flags.

Category:Project banners with quality assessment has the list of all available banners for use, which is all of the countries in North America, South America, and Europe. All of them are in the format Template:Banner/<place name>. I've only created a handful of road type banners, so I would request them at AARoads:Cleanup#Requested templates so all requests are in one place.

I should note that there are a couple cosmetic things that I need to fix yet, but those are minor and won't get in the way of tagging articles.

What do you think? –Fredddie 16:33, 14 June 2024 (EDT)