Wikipedia:Featured list candidates/List of census-designated places in West Virginia/archive1
- The following is an archived discussion of a featured list nomination. Please do not modify it. Subsequent comments should be made on the article's talk page or in Wikipedia talk:Featured list candidates. No further edits should be made to this page.
The list was not promoted by PresN 20:29, 27 July 2015 (UTC) [1].[reply]
List of census-designated places in West Virginia (edit | talk | history | protect | delete | links | watch | logs | views)
Toolbox |
---|
- Nominator(s): Seattle (talk) 00:05, 28 May 2015 (UTC)[reply]
A list of census designated places (CDPs) in West Virginia; some CDPs show past prosperity, but current economic emaciation. Seattle (talk) 00:05, 28 May 2015 (UTC)[reply]
- Comment Lead needs a good copy edit as there are lots of passive sentences in a row. For example the first sentence could be written more actively as follows: "The United States Census Bureau separates places by incorporation for statistical purposes during its decennial census". It's also a bit strange that the lead starts with something that this list is not about. Specifically talking about incorporation instead of the definition of a census designated place. Mattximus (talk) 02:42, 28 May 2015 (UTC)[reply]
- @Mattximus: I've mixed a few active sentences into the lead. CDPs themselves don't have much of a definition, after a non-incorporated place. I've defined incorporation and the requirements specific to West Virginia to give a more complete definition of CDPs by way of contrast so that, if municipalities can do the defined articles listed under the Municipal Code of West Virginia, the implication is CDPs cannot. I followed the same for rules for incorporation. Seattle (talk) 01:26, 29 May 2015 (UTC)[reply]
- The lead really needs a copyedit, but I like this list, so maybe I can take a look. Revert any edits you do not like. One thing that stands out is that almost all the lead is dedicated to talking about what makes an incorporated place, but the list is about unincorporated places. It's great information if this list was about incorporated places, but I don't understand why it's in this article.
- Also the caption beside the lead photo is great and useful, but also not related to the page in question. The list of CPDs should not have a detailed history of a particular building. That summary belongs on the page specific to that building, and this page can link to that one. Mattximus (talk)
- @Mattximus: I've mixed a few active sentences into the lead. CDPs themselves don't have much of a definition, after a non-incorporated place. I've defined incorporation and the requirements specific to West Virginia to give a more complete definition of CDPs by way of contrast so that, if municipalities can do the defined articles listed under the Municipal Code of West Virginia, the implication is CDPs cannot. I followed the same for rules for incorporation. Seattle (talk) 01:26, 29 May 2015 (UTC)[reply]
- Comments by Imzadi1979:
- The photos in the same section as the list table are creating a formatting issue. Right under the header, the photos appear on the right opposite a large blank space. Because the table is wider than the space left over by the photos, it appears under them. (The same behavior happens if I print the page to a PDF file.) I suggest converting the photos into a gallery under the table or removing them.
- That doesn't happen on my viewing platform, but I've seen that happen before. Moved to a gallery. Seattle (talk) 00:40, 17 June 2015 (UTC)[reply]
- As for the photos, there is some work needed related to the captions. I suggest piping the state name out of links in the captions. It should be obvious that any mentioned places are in West Virginia based on the title of the page, but if they were retained, someone needs to audit them to make sure a comma always appears after the state name. Since all of the mentioned places are linked in the table, they need not be linked again in the captions. Someone should also audit if linked phrases are common enough to go unlinked.
- I've removed the state names from the captions. I don't have a problem with convenience links in the captions so that readers won't have to scroll back to the table for more information on the town pictured. If you have a specific phrase that needs to be unlinked, let me know. Seattle (talk) 00:40, 17 June 2015 (UTC)[reply]
- In the table itself, the population column should be right-aligned for legibility. If this was done, ones place, the tens place, the hundred place and the thousands place (with the comma) would line up. Then it would be more apparent at a quick glance which values are larger than others.
- They look fairly well aligned now; if the community's population is larger, an extra digit will appear from the previous entry, or they will be the same. For sortability purposes, the list appears aligned. Seattle (talk) 00:40, 17 June 2015 (UTC)[reply]
- I would recommend that you use separate columns for area using
|disp=table
in {{convert}} since that would right-align the numbers for the same legibility concerns. It would have the added benefit that the unit value (sq mi or km2) would not need to be repeated in every row. You don't repeat "County" after every county name, so why do you need to repeat "sq mi" after every area? The implicit "people" unit for population isn't displayed in each row.
- I would recommend that you use separate columns for area using
- I've added a line break in the column to align the conversions, and removed the labels. Seattle (talk) 00:40, 17 June 2015 (UTC)[reply]
- In the references, you've used "United States Census Bureau" as the name of a published work, putting it in italics. Since it's the name of the agency that published those sources, it should not be in italics. Now if you wish to include the relationship of the United States Census Bureau to the United States Department of Commerce, you could use the former as the author and the latter as the publisher, you could list both as the publisher. You could drop the department and just use the bureau as the publisher, but as it stands, it should not be the name of a published work.
- Ultimately the United States Department of Commerce publishes the data collected by the United States Census Bureau, the work. The United States Census Bureau operates within the United States Department of Commerce. I've formatted references to the National Register of Historic Places, published by the National Park Service, in a similar fashion. Seattle (talk) 00:40, 17 June 2015 (UTC)[reply]
- The West Virginia Code is the name of a published work, in this case a collection of the state's statutes. It should appear in italics to be consistent with the rest of the footnotes. Legal citations, in Bluebook format may italicize the title of an article in a journal or newspaper and then run the title of the word in roman ("plain") text, but you're not using Bluebook here, so you should conform those citations to the formatting style that is in use. The same goes for "Miss. Code Ann." (Mississippi Code Annotated) and "Fla. Stat." (Florida Statutes). At the very least, just as we advise with journal titles, we should not be abbreviating these. Since we are designed for a general audience, we should not presume that our readers know what "Miss. Code Ann." means.
- I don't yet have experience with Bluebook citations, but I tried to follow the abbreviations listed here. I expanded the legal citations' details, and included dates for publication. Seattle (talk) 00:40, 17 June 2015 (UTC)[reply]
- The publisher for the newspaper in n20 is superfluous and can be removed. With newspapers, the name of the paper alone (supplemented by the location of publication if not included in the paper's name) along with the date of publication is sufficient to identify the source of the article being cited. Since this is online, you should supply the access date, just as you did with other online sources.
- I don't see a problem with including the publisher for a newspaper. MOS:REF#Links and ID numbers implies access dates are optional for web sources with published dates, as does Wikipedia:Citing sources#Web pages. For web pages without published dates, I've included access dates. Seattle (talk) 00:40, 17 June 2015 (UTC)[reply]
- If possible, it would be good to get publication dates for all of the sources that lack them. For the legal code sections, an enactment or effective date for the law (or its last amendment date) is sufficient.
- I've added dates where possible. Seattle (talk) 00:40, 17 June 2015 (UTC)[reply]
- I won't state an opinion as to support or opposition at this time. Imzadi 1979 → 04:03, 16 June 2015 (UTC)[reply]
- The numbers in the table are not aligned, which is not the same as sortability. When you have different orders of magnitude, as you do here, right-aligned numbers would be better. Looking at some values from the table, 9 is an order of magnitude smaller than 95, which is still an order of magnitude smaller than 961, and there's another order of magnitude higher with 9,995. Spreadsheets, and the paper ledgers before them, use right-aligned numerical values, or decimal-aligned numbers so that these orders of magnitude line up: the ones place is on the right edge in every row, the tens place is immediately to the left of it in every row, etc. However, when you left align these numbers, the 9s all appear first, even though they represent values within their larger numbers of 9, 90, 900 and 9000. Last comment on this point: when you add an additional digit while counting up in numbers to indicate the next order of magnitude, such as when your car's odometer rolls over form 99,999 miles to 100,000, you add it to the left, not the right. When you left-align a set of numbers of mixed magnitudes, you're effectively adding that extra digit to the right.
- I never conflated sortability with alignment– if I sort the values, they left align. I've aligned population and areas to the right. Seattle (talk) 07:53, 17 June 2015 (UTC)[reply]
- Area column suffers from these same concerns of alignment, which again isn't the same as sortability. Additionally, by putting the metric values underneath, the visual scanning breaks down. I scan down the table, and read areas of 3.27, 8.5, 10.26, 26.6... At a quick glance, I don't parse that as 3.27 mi2, 8.5 km2, 10.26 mi2, 26.6 km2, but the numbers run together as the same base unit because no base unit is specified. Also, the decimal places aren't consistent so it's a bit jarring to scan the column and see the precision flip back and forth. Also, the parentheses are problematic because that is one of the ways used in accounting to note negative values, along with the minus sign or red ink/print. In any case, it forces the reader to pause to discern what is being displayed instead of parsing it more naturally.
Now, this format might be necessary where space is limited, but it is not so limited here. Readers can figure out what the numbers mean, but not as easily as if they were in separate columns. You could use a header that placed the words "Total surface area" on one line that spanned both columns with "Square miles" and "Square kilometers" on a second line, or if that were too wide, you could use "mi2" and "km2" for the column labels on the second line. Then the values should be right aligned.
- Area column suffers from these same concerns of alignment, which again isn't the same as sortability. Additionally, by putting the metric values underneath, the visual scanning breaks down. I scan down the table, and read areas of 3.27, 8.5, 10.26, 26.6... At a quick glance, I don't parse that as 3.27 mi2, 8.5 km2, 10.26 mi2, 26.6 km2, but the numbers run together as the same base unit because no base unit is specified. Also, the decimal places aren't consistent so it's a bit jarring to scan the column and see the precision flip back and forth. Also, the parentheses are problematic because that is one of the ways used in accounting to note negative values, along with the minus sign or red ink/print. In any case, it forces the reader to pause to discern what is being displayed instead of parsing it more naturally.
- I've re-added the miles and km markers, because in no other column are two values present, and right-aligned values. And I credit our readers with enough good sense to realize that there can't be a negative value for a straight conversion of area. Seattle (talk) 07:53, 17 June 2015 (UTC)[reply]
- The National Register of Historic Places is a published listing, and therefore a work; someplace is a printed copy of the register itself maintained by the National Park Service, and it alone isn't the name of an agency or office within the NPS. The "United States Census Bureau" itself is the name of a government agency, not the name of a book or a periodical like a magazine or journal. There may be a published work that begins with the name of the agency, a United States Census Bureau Journal, for instance, but that doesn't make the bare "United States Census Bureau" itself a published work that should appear in italics. It is either an author, a publisher, or both.
- Template:Cite web#TemplateData states that the "work" title represents the "title of the website". The work of census.gov is the United States Census Bureau. Seattle (talk) 07:53, 17 June 2015 (UTC)[reply]
- I'm glad you expanded the legal code names. For a generalist audience, those abbreviations can be quite cryptic, but lawyers who deal with them on a daily basis would not have such concerns. The page you referenced is for those in the legal profession, not a generalist audience.
- I don't care how you feel. Seattle (talk) 07:53, 17 June 2015 (UTC)[reply]
- To comment on something in Harrias' review below, "census-defined place" is actually the more correct punctuation. Together "census" and "defined" jointly modify "place". There is no such thing, that I know of, as a "defined place" that would make sense modified by "census". No, instead it is a place that is "census defined", and when that compound adjective appears in front to modify the word "place", it should be hyphenated under basic English grammar rules. If the Census Bureau doesn't punctuate it that way though, well, that's a debate for another day. Imzadi 1979 → 05:08, 17 June 2015 (UTC)[reply]
- That's a discussion you can hold at census designated place, not here. Seattle (talk) 07:53, 17 June 2015 (UTC)[reply]
- Actually the website title at http://www.census.gov is "census.gov", if it has a title at all. (Not all websites do.) In turn, that website is published by the United States Census Bureau, a division of the United States Department of Commerce. The bureau is not the name of a published work no matter now you try to parse it.
- No, actually I'm "parsing" it directly from Template:Cite web; the "title" of the webpage is "United States Census Bureau", for which Census.gov represents. Seattle (talk) 11:07, 17 June 2015 (UTC)[reply]
- This version clearly shows how to compactly format the table with separate columns.
- As I noted above, you've dropped the word "County" from the name of each county in that column, because the column heading implies that. You've omitted the unit of "people" from the population column, because the column heading implies that. Properly done, there's no need to repeat the unit in each row of the table because the heading will imply the proper units. However, dropping the units and leaving the conversions in the same column is an open invitation for readers to mis-parse the data while scanning the table; seeing raw numbers in parentheses in a table can be mis-interpretted as negative numbers or notation of measure uncertainty.
- Tell me what criterion of the featured list criteria the list fails, in its current state, and I'll be happy to address it. Seattle (talk) 11:04, 17 June 2015 (UTC)[reply]
- You seem to believe that splitting the columns is bad for some reason, yet that's what
|disp=table
is for in {{convert}}.
- You seem to believe that splitting the columns is bad for some reason, yet that's what
- I don't know why it's there; you'd have to ask whoever added the parameter to {{convert}} his or her reasoning behind adding it to the template. As I noted above, I re-added the parameters because "in no other column are two values present". Seattle (talk) 11:04, 17 June 2015 (UTC)[reply]
- Done this way, the two columns actually take up less horizontal space.
- The second column under "Total area" is superfluous to the first; "parse" it any way you want, but there's no reason that couldn't be one column.
- The table takes up less vertical space because the only rows that need to occupy two lines are those for places in two counties. So except for those rows, everything lines up across vertically as a reader scans each row horizontally as well. For those two-county rows, you could separate the two values by a simple comma instead of a line break, which wouldn't widen the column much, if at all. On narrower displays, the cells will still line-wrap at the comma if necessary to reduce the width of the overall column.
- Again, a smaller vertical width seems like a personal preference. Tell me what criterion of the featured list criteria the list fails, in its current state. Seattle (talk) 11:04, 17 June 2015 (UTC)[reply]
- Finally, the panoramic photo should be reinserted into the gallery, moved elsewhere (like the bottom of the lead), or removed. It is jarring to have this nicely formatted gallery with a photograph of a totally different formatting scheme directly underneath. The inconsistency gives an unpolished look.
- No, the photo, at that size, renders it too small for any productive use. Readers can see details of the community in its current form. Seattle (talk) 11:04, 17 June 2015 (UTC)[reply]
Imzadi 1979 → 09:00, 17 June 2015 (UTC)[reply]
- Oppose—fails several criteria. Until this point, I had not reviewed the prose, but now that I have, I feel the lead section fails criterion 1 in addition to the WP:V policy. There is a direct quotation that lacks a citation for the source of the quotation, contrary to policy. From WP:V, "All quotations ... must include an inline citation that directly supports the material." Professional writing standards, and typical Wikipedian practice, is to immediately follow quoted text with a source. I might assume that the footnote at the end of the subsequent sentence is the source of the quotation, but that assumption would be no substitute for appropriate practices, even if that means consecutive sentence bear the same footnote.
- Moved. Seattle (talk) 03:02, 18 June 2015 (UTC)[reply]
The entire second paragraph is off-topic, but would be appropriate in a list of incorporated places in West Virginia. If this paragraph were recast a bit, it could be on-topic for CDPs/unincorporated places, but much of the information as presented does not apply to the topic at hand.
- Disagree. This paragraph actually describes CDPs by describing what they are not– they haven't met the requirements for incorporation, which I specify in paragraph two, or they have chosen not to incorporate. Seattle (talk) 03:02, 18 June 2015 (UTC)[reply]
Moving on to criterion 4, the second paragraph of the lead should be its own section once reworked as it would form a natural area of the topic of CDPs in the state, a description of what a CDP in the state is. The last paragraph of the lead, as it appears, is a good summary of some the details in the table, so it should remain in the lead to satisfy criterion 2.
- I'm not sure what your objection is here. Seattle (talk) 03:02, 18 June 2015 (UTC)[reply]
In addition the length of some of the captions in the gallery cannot be classified as "succinct", failing criterion 5b. If the author wants to expound on various places, he or she can add a "Description" column to the table.
- If you have a specific objection, be sure to let me know. Seattle (talk) 03:02, 18 June 2015 (UTC)[reply]
Criterion 5a is failed related to the layout of the table regarding the area columns. The placement of a panoramic photograph immediately after a gallery, resulting in the juxtaposition of two styles of photographic elements also fails criterion 5a. Splitting the unit systems for the area would enhance the legibility or the ability of readers to parse the numerical data and improve the visual appeal of the table. Harmonizing the juxtaposition of photo layout styles, even just by moving the one photo up into the prose sections preceding the table would also improve the visual appeal.
- I'll disagree and point you to a consensus at Wikipedia:Featured list candidates/List of municipalities in Rio Grande do Norte/archive1 against segregating units. Now, if you want to try and change that consensus through a RFC, that would be your best route– it currently appears that both are accepted. I disagree that the wide photo of Corrine is "jarring" after the gallery– it's a nice way to end the list, actually, with a detailed panorama of a West Virginian CDP. Seattle (talk) 03:02, 18 June 2015 (UTC)[reply]
For these reasons, I now oppose at this time. Imzadi 1979 → 11:33, 17 June 2015 (UTC)[reply]
- List of cities and towns in Arizona (promoted in 2009), List of cities and towns in California (2012), and List of cities and towns in the San Francisco Bay Area (2012) use separate columns for each measurement system when displaying converted measurements, although they have the same issue I originally experienced with this list regarding blank space and photographs. The also include the population density, which is completely missing from this list. That tells me we're not satisfying criterion 3a related the "annotations that provide useful and appropriate information about the items". Similar lists for Canada and other countries lack converted values, specifying areas and population densities only in terms of square kilometers, so one could argue they're failing MOS:CONVERSIONS. However, they're at least putting the unit in the heading and not repeating it in every row of the table, something that currently has to be done here to keep the customary and metric straight. Imzadi 1979 → 12:14, 17 June 2015 (UTC)[reply]
- I'll disagree and point you to a consensus at Wikipedia:Featured list candidates/List of municipalities in Rio Grande do Norte/archive1 against segregating units. Now, if you want to try and change that consensus through a RFC, that would be your best route– it currently appears that both are accepted at FLC. I'll consider adding a "population density" column. Seattle (talk) 03:02, 18 June 2015 (UTC)[reply]
- Actually, all three FLs to which you pointed me do not have a "population density" column. Pinging featured list director @Giants2008: and delegates @Crisco 1492:, @SchroCat:, and @PresN: for official comment. Seattle (talk) 19:24, 17 July 2015 (UTC)[reply]
- The Arizona list has the population density, but it is the oldest list of the three and some of the table features show its age. I don't know that much about what is expected of similar lists, but it's not something I would personally mandate. Giants2008 (Talk) 18:06, 18 July 2015 (UTC)[reply]
- Why is it a "List of census-designated places in West Virginia" with a hyphen, when it defines a "census designated place" with no hyphen? Unless there is a reason I am missing, this should be made consistent, and probably follow our article, and have no hyphen.
- Moved. Seattle (talk) 00:40, 17 June 2015 (UTC)[reply]
- I'm a little confused about the second paragraph. As far as I can tell from the first paragraph, a CDP lacks "elected municipal officers and boundaries with legal status", while the second paragraphs discusses "municipal corporations": are "municipal corporations" a subset of CDPs?
- Clarified. Seattle (talk) 00:40, 17 June 2015 (UTC)[reply]
- The last paragraph seem a bit repetitive, given that Bowden is the smallest and least populated, those facts could do with being merged into one sentence.
- Merged. Seattle (talk) 00:40, 17 June 2015 (UTC)[reply]
- Everything in the table looks hunky dory, and the images display fine next to it for me, but I do have a wide screen. Harrias talk 13:54, 16 June 2015 (UTC)[reply]
- We cannot assume all readers have wide screens. I have one as well, but I keep my window width constrained to approximate a sheet of paper held in the portrait (upright) orientation, not a sheet of paper in landscape (wide screen) orientation. Before the page was changes, I had the same issue viewing the desktop version of the article on my iPad in the portrait orientation, and when I rotated the device to landscape mode. Viewing the mobile version of the page, pre-change, gave me the same formatting issues in portrait mode, but not in landscape. And just to be complete, I viewed the page on my phone. My phone gave me the same results as my tablet for the desktop view. In mobile view, the table appeared under the photos no matter which way I held my phone.
In short, we have a lot of variables to account for in laying out the elements of a page, and assuming that a reader has a wide screen and won't have issues with a format is a bad idea. The change to a gallery under the table is a great improvement. Imzadi 1979 → 23:48, 16 June 2015 (UTC)[reply]
- We cannot assume all readers have wide screens. I have one as well, but I keep my window width constrained to approximate a sheet of paper held in the portrait (upright) orientation, not a sheet of paper in landscape (wide screen) orientation. Before the page was changes, I had the same issue viewing the desktop version of the article on my iPad in the portrait orientation, and when I rotated the device to landscape mode. Viewing the mobile version of the page, pre-change, gave me the same formatting issues in portrait mode, but not in landscape. And just to be complete, I viewed the page on my phone. My phone gave me the same results as my tablet for the desktop view. In mobile view, the table appeared under the photos no matter which way I held my phone.
- Moved images; I didn't see a break, but I've seen them before. Seattle (talk) 00:40, 17 June 2015 (UTC)[reply]
- The above discussion is preserved as an archive. Please do not modify it. No further edits should be made to this page.