Wikipedia:Peer review/U.S. Route 5 in Vermont/archive1

U.S. Route 5 in Vermont
This peer review discussion has been closed. I've listed this article for peer review because I want to get some editor feedback before listing it as a good article nominee.

Thanks,  Theking 17825  16:46, 5 April 2012 (UTC)
 * Comments:
 * 1) It would be helpful if the infobox listed major intersections along the route.
 * 2) ". The highway serves the major cities of Brattleboro, Hartford, and St. Johnsbury.", I don't think those are major cities.
 * 3) The route description needs references. I would suggest using an official highway map along with a Google Maps overview of the route to show the physical surroundings.
 * 4) Try not to use "US 5" in every sentence of the route description.
 * 5) "North of Putney, it crosses over the interstate to serve the towns of Westminster, Bellows Falls, and Rockingham." indicate this is I-91.
 * 6) The route description could use more details about the physical surroundings.
 * 7) Do not use "then" in describing progression of route.
 * 8) The history section needs references.
 * 9) The history section could use more details. Have there been any changes to the route since 1933?
 * 10) The major intersections table should have a row for the MA border and the Canadian border.
 * 11) You can use VTint to generate the major intersections table.  Dough  48  72  23:57, 5 April 2012 (UTC)

I can appreciate the enthusiasm, but this article would likely be quick-failed if it was nominated for GA in its present state. As Dough commented above, the entire article is under-referenced, which is one of the core components of the good article criteria. Other issues I see:
 * 1) Hyphens are used in several places where an en dash should be used. See MOS:DASH.
 * 2) The two photos have fixed image sizes. This is discouraged unless there is a legitimate reason to set the size, and in this case there isn't. See WP:IMGSIZE.
 * 3) This article uses a mix of abbreviations (VT #) and full names (Vermont Route #). It is recommended to only use the full name at the first instance of said name, place the abbreviation in parentheses after it, then use only the abbreviation in the rest of the article. In the current revision at the time of this posting, that means the VT 103 link in the first paragraph would become ("... Vermont Route 103 (VT 103) ...") and all other instances of "Vermont Route #" would be replaced with "VT #". The same thing applies to Interstate Highways ("Interstate #/I-#").
 * 4) On that note, there should be non-breaking spaces between the route numbers and the abbreviation or word that accompanies them (thus, "US 5" would be entered as   ).
 * 5) Although it is allowed under the road junction list Manual of Style, the rest of Vermont's articles do not use the "stacked" junction list method (the method used to display the routes at MP 9.105).
 * 6) And on that note, the rest of Vermont's articles denote the endpoints of intersecting routes with a note in the notes column that reads " terminus of ". Simply appending a direction onto a route doesn't imply a terminus at all - it could easily be interpreted to mean a junction where only one direction of the intersecting route is accessible. Lastly, the rest of Vermont's articles add the "continuing" direction for routes that overlap. See Vermont Route 11.
 * 7) Not all images need to be placed in a thumbnail box, and the Route 2 marker in the history section is one that doesn't unless a caption is added to it.

This article is off to a good start, but it needs more work before it can be considered for good article status. Thanks for asking for others' input - it's refreshing to see an editor seek a second opinion when they're not sure about something, as that's a practice that has fallen by the wayside in recent years, unfortunately. –  T M F 01:46, 6 April 2012 (UTC)


 * Thanks so much for both of your comments! I should have probably rephrased my request, I know this isn't ready for GA status but I was just looking for some input to get it going along the road to hopefully becoming a GA soon. I'll get to work using your comments! Thanks.  Theking 17825  03:10, 6 April 2012 (UTC)

Specifically dealing with the references, some of which might be regarded as personal preferences:
 * Comments by Imzadi1979
 * 1) It's probably a good idea to spell out "Vermont Agency of Transportation" instead of VTrans in the citations.
 * 2) If a source is online, an access date is needed. Most of the footnotes have them, but some are missing.
 * 3) If a source is a PDF, it's a good idea to indicate that using the  coding in the template. Not all readers have graphics turned on, so you can't assume that the PDF icon will be present. Also, not all URLs to PDFs end in ".pdf". If you pre-emptively archive links to combat WP:LINKROT using http://www.webcitation.org/archive.php, the links it generates lack a file type suffix.
 * 4) You've used cite map to generate the one citation, but there is the specific google maps that exists to simplify the formatting. However you've used cite web for other maps. I'd recommend switching them to cite map for consistency, and using the Google-specific template.
 * 5) As a better practice, you should re-generate the Google Maps search you used, and then get the specific link. There's a chain icon on the page that will give you the URL. As it stands now, you're directing readers to the main page. They can't replicate your work to verify it.
 * 6) Most Americans don't use a leading zero in a date, so while it isn't wrong to use "April 01, 2012", it's non-standard. According to WP:DATEFORMAT: "Dates: Wikipedia does not use ordinal suffixes, articles, or leading zeros", so they need to be changed to conform to our Manual of Style.
 * 7) I recommend trying to add an author for all non-press citations. On corporately authored works (documents generated by VTrans without an explicit author named), this would something like the specific office/bureau/division/department that generated the document. As a default, I use "Staff" as the author. Either way, it helps indicate that the same entity is both the author and the publisher. (The side benefit is that you always get a citation that looks like  (). . .) For the route log, the author would be "Planning, Outreach and Community Affairs Division Traffic Research Unit".
 * 8) Make sure that if a source is multi-page, and it is paginated (i.e. the pages have numbers printed on them), you need to include the page numbers. To minimize confusion, don't use the page number from the PDF file, but what is printed on the page. That way if a reader is looking at a copy of the document printed on paper, they won't look for "page 3" which might be "page ii" on the printout.

Other comments: I hope these suggestions are helpful. Some of what I mentioned is picky on the level expected of FAs, but I've found that it's easier to get the references in shape early than try to whip them together later during a review when an editor has given you a laundry list of minor details to fix.  Imzadi 1979  →   08:04, 7 April 2012 (UTC)
 * 1) TMF above suggested that you un-stack junctions and merge them together in the junction list. The problem I have with that is now you're implying that the two highways at the junction are concurrent with each other. If they are, you're ok, but if they are not, they should be separated.
 * 2) I would reinsert the directions in addition to the termini/overlap notes. My practice is that if a driver along the subject highway (in this case, US 5) is at the intersection, what direction(s) are accessible on the intersecting highway. If there is only one direction available (I-91 north, for instance) to leave the subject roadway, then I list that direction in the destinations column. If both directions (I-91 north and I-91 south) are available, then the directions aren't needed.
 * 3) I highly recommend switching over to the junction list templates. That way if MOS:RJL changes in the future, and we update the templates to accommodate those future changes, the article will update itself.
 * 4) The jcttop template generates coding for the header row of the table that complies with MOS:DTT in terms of accessibility.
 * 5) The templates for the rows of the table (VTint as Dough noted above) also right-align the milepost column which roughly aligns the numbers by the decimal point, making them easier to read in a longer table. Right-alignment is an item that has been suggested that MOS:RJL should require, and the templates already format things that way.
 * 6) Where is the zero milepost for the highway? Where is the terminal milepost for the highway? (According to the infobox, they are at the state line and the international border, but the junction list lacks them.) The reason I ask is that a reader looking at that table could naturally assume that the first MP is 7.932 miles and the last is 188.388 miles and deduce that the length is therefore 180.456 miles, not the 192.316 miles stated elsewhere in the article. (Not all roads start at a MP 0; the motorways that radiate away from London are measured from a point downtown but most start out near the beltway.)
 * 7) Another personal thing I'd recommend is to give the exit number of the interchanges from the other highway. For instance, for the I-91 interchanges, rather than just say "Interchange" as the notes, say "Exit X on I-91". You'll need a non-breaking space between "exit" and the number.
 * 8) In the lead, you have "Numbered Highway System" mentioned on its own; I think you meant the US Highway System or the United States Numbered Highway System. Later you have "Highway System" by itself in capital letters, but in that context, that's not a proper noun. (It's also confusing if you're referring to the US Highway System or the New England system.) Just watch the capital letters on words that are common nouns.
 * 9) I found a few cases where lengths are used in the prose without metric conversions. You can use convert to generate the needed conversions for you. For even numbers under ten, which really should be spelled out, there's also convert/spell which will generate something like 2 mi or 5 mi for you.
 * I disagree about your point about implying a concurrency. If that really was an issue, the practice of having separate lines for each intersecting route would be codified into MOS:RJL. On the contrary, I can think of at least three states that put all routes on a single line, whether they're concurrent or not (PA, NY, and VT), and a cursory glance of other states shows that they do as well. –  T M F 07:31, 8 April 2012 (UTC)
 * And after some more glancing, it looks like that the only state that follows the practice you suggest is Michigan.
 * The purpose of the column is simply to list what routes are present at a particular intersection, and no more. Making formatting exceptions for intersecting non-concurrent routes is a bit overkill in my book. –  T M F 07:44, 8 April 2012 (UTC)
 * MOS:SLASH states: "Generally avoid joining two words by a slash, also known as a forward slash or solidus ( / ). It suggests that the two are related, but does not specify how." The two (or three) items are related if a highway is concurrent, which is the implication from the formatting in reliable sources. In talking about an interchange or intersection between two roads, the correct punctuation would be an en dash as that section continues with: "In circumstances involving a distinction or disjunction, the en dash (see above) is usually preferable to the slash: the digital–analog distinction." Highway articles only get away with usual slashes because MOS:SLASH says that "[a]n unspaced slash may be used ... where a slash occurs in a phrase widely used outside Wikipedia, and a different construction would be inaccurate, unfamiliar, or ambiguous." Highway concurrencies are typically denoted with slashes, thus allowing the exception. If states other than Michigan are doing this wrong, that's a problem to be fixed in articles. If our articles are falsely implying concurrencies between two highways at an intersection or interchange, then that falsehood needs to be corrected.  Imzadi 1979  →   09:26, 8 April 2012 (UTC)
 * Good luck getting anyone else on board... –  T M F 09:55, 8 April 2012 (UTC)