Wikipedia talk:WikiProject National Register of Historic Places/Archive 26

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is a notice to let you know about Article alerts, a fully-automated subscription-based news delivery system designed to notify WikiProjects and Taskforces when articles are entering Articles for deletion, Requests for comment, Peer review and other workflows (full list). The reports are updated on a daily basis, and provide brief summaries of what happened, with relevant links to discussion or results when possible. A certain degree of customization is available; WikiProjects and Taskforces can choose which workflows to include, have individual reports generated for each workflow, have deletion discussion transcluded on the reports, and so on. An example of a customized report can be found here.

If you are already subscribed to Article Alerts, it is now easier to report bugs and request new features. We are also in the process of implementing a "news system", which would let projects know about ongoing discussions on a wikipedia-wide level, and other things of interest. The developers also note that some subscribing WikiProjects and Taskforces use the display=none parameter, but forget to give a link to their alert page. Your alert page should be located at "Wikipedia:PROJECT-OR-TASKFORCE-HOMEPAGE/Article alerts". Questions and feedback should be left at Wikipedia talk:Article alerts.

Message sent by User:Addbot to all active wiki projects per request, Comments on the message and bot are welcome here.

Thanks. — Headbomb {ταλκκοντριβς – WP Physics} 09:27, 15 March, 2009 (UTC)

Hope you guys don't mind that I sat these up for here. §hepTalk 01:07, 22 March 2009 (UTC)
Great! It doesn't happen often anymore, but where would i get to see if a NRHP disambiguation page was up for AfD? I missed this recent AfD (outcome, happily: J. C. Penney Building survived). (That one wasn't tagged for NRHP. Please, everyone tag dab talk pages with {{WikiProject NRHP|class=dab}}! ) doncram (talk) 03:47, 22 March 2009 (UTC)
A reminder that you should give a link to the alert page when you are using the display=none setting.Headbomb {ταλκκοντριβς – WP Physics} 16:55, 25 March 2009 (UTC)

Restored section-edit links: [edit]

In the topic "New Template" (far above), I have fixed the unclosed double-braces "{{" that disabled section-edit links "[edit]" for all subsequent talk-page topics. A short trick for displaying "{{" is to put an empty font-tag between the 2 braces, such as: "{<font/>{" but don't forget the ending slash in "font/" or else the font size just gets bigger. Apparently, putting an unclosed "{{" on a talk-page freaks out the wiki-parser that determines section storage/editing for each "==" page-section: the separate sections still appear on the page but cannot be edit-retrieved. All this is so complicated, I wonder if wikis could be made simpler somehow, such as forcing "{" closure at the next talk-page section "==". There are hundreds of bizarre issues in the MediaWiki markup language: it is far, far more complex than most people realize. Meanwhile, the developers must spend most of their time modifying code to support twisted or split character/word handling for complex typesetting of the 200+ wiki languages. That means the developers are learning those 200 languages, to some extent, and so who has time to design wiki-features, such as better talk-pages, partial protection of page sections, or hidden-hyphenation of words, etc. -Wikid77 (talk) 08:32, 28 March 2009 (UTC)

  • Thanks for fixing that dm (talk) 23:16, 28 March 2009 (UTC)

Oregon state list vs. NRIS reconciliation results: .03% NRIS omission rate

I just completed a detailed reconciliation between an Oregon state-provided NRHP list, vs. the NRIS tables-approach, with help of Aboutmovies, Ipoellet, and Katr67. The Oregon wikipedia list now shows 1,896 NRHP listings, which is our best information currently, before review with Oregon and National Register contacts. The NRIS system omits 5 out of those 1,896, and also one secondary listing for one that should be listed in more than one county. Several were omitted by NRIS data entry error, simply not entering several Oregon and other states' new listings off of one new weekly listings report. The Oregon state list is better in accurately identifying county locations for several, now corrected in wikipedia and put into wp:NRIS info issues to report to the National Register. But the Oregon state list omits 10 entirely and 4 secondary listings needed to show multi-county ones in each county consistently (it does show one historic district properly in 3 counties). The Oregon state list includes 8 that appear to be erroneous listings, by our current classification. Some of those may turn out to be NRIS omission errors. If just the 6/1896=3/1000 omission error rate applies nationwide, then NRIS is missing 240 legitimate NRHP listings.... I think that no one knows how many NRHP listings exist! doncram (talk) 05:04, 30 March 2009 (UTC)

New National Register database loaded

I've loaded the new National Register Information System database update onto the www2.elkman.net/nrhp server. So, you should be able to get the new data from the following queries:

And, of course, any links I forgot. If you see any errors or omissions, let me know. I did a quick peek into the areas listed in our NRIS information issues list, but it looks like they haven't fixed many mistakes, if any at all. --Elkman (Elkspeak) 03:45, 30 March 2009 (UTC)

Great news, Elkman! This should speed up the creation of accurate and up to date county lists. As always, thanks for your efforts. Does the disambiguation page creator on your page also access the new data? --sanfranman59 (talk) 04:03, 30 March 2009 (UTC)
Yes, it'll use the new data. Every one of the queries will use the new data, even if I forgot to put them in the list above. --Elkman (Elkspeak) 04:15, 30 March 2009 (UTC)
This data will be current through new listings through 3/13/09. Hey, at first i thought the query-by-county here was not coming out in the numbered, wikipedia list-table format that we have been using. But, i see that it is there as the County list generator above. Thanks! I also use the
ones a lot too, glad to know those will work off the new database, too. Thanks! doncram (talk) 04:19, 30 March 2009 (UTC)
It appears that the NPS hasn't gotten around to adding geocode coordinates for the sites that have been added since the last April's database update. At least that's true of the two sites added in Durham County, NC. Alas and alack ... (hope you don't mind that I indented the lines in your note, doncram) --sanfranman59 (talk) 05:15, 30 March 2009 (UTC)
Actually, the geocode coordinates are in a different database download from the National Register site. That's a file named "spatial.mdb", so I'd have to convert and load that separately. --Elkman (Elkspeak) 13:01, 30 March 2009 (UTC)
The database coordinator at the National Register indeed said, "Fresh coordinates for unrestricted properties are also available in the spatial.mdb database". So there is fresh data available, corresponding to the new other data. Also, I'm not sure if this new coordinates data reflects a recent coordinates cleanup drive on their part, a specific project that i was told is reflected in Google Earth layers' data. It cleaned up the coordinates for all NRHP entries having street addresses, using standard geo-coding methods for that, getting past the pre- vs. post 1985 datum issue. So, anyhow, the spatial.mdb database should have new good info, and it would be great, Elkman, if you could implement it. doncram (talk) 09:27, 6 April 2009 (UTC)

Though it can still be expanded more, I'm thinking the portal may be ready for Featured Portal consideration. Could folks take a look, and perhaps post comments on the portal talk page? Thanks! :) --Ebyabe (talk) 02:04, 2 April 2009 (UTC)

Nice job on expanding the portal! Having a selected picture, a featured picture, and a panorama seems a little overkill, though. I do like the featured pics (didn't know there were any that were featured). Maybe only going with a featured and panorama sections would suffice. If more DYKs are needed, there are still a bunch of DYK archives I haven't gone through yet. --​​​​D.B.talkcontribs 02:27, 2 April 2009 (UTC)

Gov. Thomas Hutchinson's Ha-ha

Gov. Thomas Hutchinson's Ha-ha: is this a joke or what?

I noticed it as i finished out Hutchinson House, the 500th disambiguation page added to Category:Disambig-Class National Register of Historic Places articles. doncram (talk) 17:24, 8 April 2009 (UTC)

Well, it's better than his hoo-ha. A ha-ha is a widely used device in Britain, occasionally seen in the US; presumably Gov. Hutchinson possessed one. Acroterion (talk) 17:30, 8 April 2009 (UTC)

Flickr NC NRHP photos tip

Noticed this set at Flickr, mostly by Jim Harris, Illinois & vicinity NRHP's. He licenses CC-NC-ND, but if you asked nicely, he might do an acceptable CC license. Here's a nice tutorial. Out of my area. Good luck! --Pete Tillman (talk) 05:49, 11 April 2009 (UTC)

Oakdene

I noticed that this is on your blue link check. Please note that it is a disambig page, and the articles linked from there may not be the article your project covers. Mjroots (talk) 06:57, 10 April 2009 (UTC)

Not sure what Mjroots is referring to exactly, perhaps some link was since changed. The Oakdene article is only linked from one user page, currently. There is in fact an NRHP project page of disambiguation-related bluelinks to check, which I think Ebyabe and Katr67 worked on in 2007. It's linked now from wp:NRHPdab, a project page covering many other disambiguation issues, also Ebyabe-started. I've been plugging away at its list of disambiguation pages needed, recently. Please clarify if you're watching here, Mj, and thanks for trying to point out a problem.
For the Oakdene article, I just now added {{WikiProject NRHP|class=dab}} {{DisambigProject}} to the Talk page. Adding any disambiguation pages that have any NRHP entries to the Wikiproject NRHP this way seems to be helpful. By the way, the number of articles in the dab-class has grown >5 % since i mentioned it hit 500 in another discussion above. At this rate, it will double every 6 weeks and in 7.94372 years it will outnumber all other types of wikipedia articles. doncram (talk) 19:59, 11 April 2009 (UTC)

Poll: autoformatting and date linking

This is to let people know that there is only a day or so left on a poll. The poll is an attempt to end years of argument about autoformatting which has also led to a dispute about date linking. Your votes are welcome at: Wikipedia:Date formatting and linking poll. Regards Lightmouse (talk) 09:32, 11 April 2009 (UTC)

Use of NRHPdts

List of National Historic Landmarks in Alabama was recently edited by User:Wikid77 to replace the Template:dts template used throughout the nhl list articles to a new template he wrote Template:NRHPdts I note that the effect of this change turns January 14, 2001 into 14 Jan 2001, which I find questionable for US based articles. Without turning this into a mosnum nightmare discussion, what are peoples thoughts on this? Wikid77 appears to be preparing to turn all of the nhl lists into german wikipedia translations, perhaps through automated links to the same template. I'm not sure why we should use a NRHP specific date template though. dm (talk) 22:06, 27 March 2009 (UTC)

I am curious too. Wikid77 has some interesting stuff going on...check out Template:Location map polarx. Perhaps Wikid77 is working on some mass-translation project. Where would the discussion be for that? I don't see it at wikipedia talk:WikiProject Echo. I don't know where wiki-transfer discussions would be centered. I'm all for Germans and others translating the wp:NRHP list-articles. There are nice German versions of some already. But i also don't want to get much involved in date format issues and to have ours all out of whack with policy. doncram (talk) 22:44, 27 March 2009 (UTC)
  • Yes, the German users have been content to use the same sequence of column-contents as in the English-Wikipedia NHL-list articles. However, perhaps the day-first format ("14 Jan 2001") is more for Canadian-style dates, rather than U.S. fashion. The abbreviated date can be redone for U.S. styles, perhaps as "Jan. 14, 2001". The 3-letter abbreviations help to offset the typically-longer German words in the description-column. (German words tend to be 30%? longer than English equivalents, so table columns must be wider to achieve similar typesetting for text-wrapping.) As in English Wikipedia, the German Wikipedia does not auto-hyphenate, although naturally, hyphenation has been used in German writing for over 150 years (using "=" as in "Beetho= ven"), so without hyphenation, the text-wrapping of long words is helped by keeping the date-column narrow with "Jan" & "Feb" etc.
The German template named "dts" (de:Vorlage:dts) is not portable with the English version: it treats the first parameter as day-number, so German "{{dts|2001|1|14}}" generated "2001. Jan 14" where the trailing-dot "." in German means "2001st of Jan year 14". The new Template:NRHPdts is intended to keep the date-numbers the same, but display different month names ("May" in German is "Mai" & "October" is "Oktober") and similar for French, etc. The German users, so far, do not like "Template:Coord" and they replace as "de:Vorlage:Coordinate" with radically different latitude/longitude formats, such as "NS=45/12/30/N" & "EW=87/59/10/W". However, all of this requires give & take, working with the English users and working with the German users. Once more commonality has been established, then quickly on to French, Spanish, Italian, etc. reusing the table data-columns for "every" language, but translating mostly the Description column. Note, once the NHL-List articles appear in German, their interest seems to quickly grow to several pageviews every day, perhaps 25% of the similar interest in English versions, indicating that there is a ready-audience for German-version NHL lists. -Wikid77 (talk) 00:05, 28 March 2009 (UTC)
The NPS uses "month day, year" in all its lists -NHLs, updates, etc. The dates should be in US convention.

That said, if the goings-on are for a translation, I give a tentative OK - if afterwards it's possible to revert the dates back to US style Einbierbitte (talk) 00:14, 28 March 2009 (UTC)

OK, I've changed "NRHPdts" as format "Jan. 4, 2001". -Wikid77
  • I like the idea of multi-wikipedia templates, but I'm not sure why we should have a NRHPdts template when there could be a "multi lingual dts" that can replace dts across the board. {{dts|2001|1|21|lang=en}} or something like that. dm (talk) 01:08, 28 March 2009 (UTC)
  • I am not informed about issues in translating across wikiprojects, but i don't get what is any advantage, actually, of changing the English language NRHP list-articles to use a non-general template named NRHPdts or anything else. In a translation to DE language, you would have to define a NRHPdts date template to handle the copied in page. Why not search and replace on dts in the pasted in text, to replace with some other German language date format, if the German language dts template is not compatible with the English one? Or is that enough advantage to change the U.S. usage of dts everywhere, which is just to avoid problems in German language, if they are copied over there? I think the incompatibility of English language dts template vs. German language dts template might better be addressed in some other way. Is there a translation discussion area and/or should this be taken up at Talk of the English and Deutsch dts template Talk pages? I don't mind helping, but the date treatment issue seems bigger than just for NRHP articles (surely there are other list-articles with dates in them, like for sports records) and this also seems not really part of the English language NRHP project, strictly speaking. I don't mind continuing to discuss here, for lack of knowledge of a better forum. doncram (talk) 19:21, 28 March 2009 (UTC)
(See subtopic below: #Managing other-language templates. -Wikid77).

Managing other-language templates

12-April-2009: (subtopic) There are several long-term issues to consider, when planning to use the other-language templates (such as the German Vorlage:SortDate). These issues concern a wide-range of possibilities in the other-language Wikipedias:

  • The broad goal is translation to many languages, not just German.
  • An other-language culture might have NO pre-existing templates that handle data in the English-Wikipedia format, such as sort-generating dates as YYYY-MM-DD.
  • Using a common name, such as "dts" which is a different template in German WP, provides no indication for specialized functionality, whereas using a more-rare name, such as the "NRHPdts" template, avoids the "name collision" frustration of using some not-the-same "dts" in an other-language Wikipedia; furthermore, once "dts" is discovered to be different in some other-language Wikipedia, then another name must be "invented" as the equivalent template, whereas "NRHPdts" already provides the new invented name in the case where "dts" is not the same, or will be changed to work differently in the future.
  • Translation of a specialized template, such as Template:NRHPdts, is a simple approach that can work for many languages, where "NRHPdts" is unlikely to exist as some other template.
  • Use of other, pre-exising templates would require that those templates would not change or get broken, or else every translated article would need to be updated to accommodate the functionality whims of other-language templates.
  • Universal use of a specialized template, such as Template:NRHPdts, already defines the known functionality, rather than becoming a mystery when an English-WP user edits some other-language translated page, and sees yet another template name, such as "Vorlage:SortDate" with unknown future changes, being used.
  • In general, in semi-managed chaos, a limited-use template is easier to control than a wide-use template with unknown user pressures planning to alter the template functionality.
  • The attitude that articles should avoid customized, or specialized, templates, in favor of some wide-use templates, is an unusual viewpoint, because, in reality, keeping customized variations allows for more flexible adaptation to future changes.
  • The attitude that articles should avoid customized, or specialized, anything, is actually an unrealistic idea, since in reality, the exact opposite is the preference; in fact, whole corporations exist to provide customization for particular customers, because there is such a great demand for customization.
  • Beware prior wiki-concepts, because they are often developed by volunteers and might not be proven otherwise; for example, the concept that non-existant articles should not highlight as yellow-brown but rather as red (which in America, typically means "fatal error") is a troublesome technique when considering the range of cultural norms.
  • As of April 2009, for Wikipedia, always design for semi-managed chaos: the changes being made to Wikipedia, for years now, have been wild, massive and rampant, such as changing the rendering of GIF images to become blurred wiki-huhs, when a gigantic organization like Google has maintained use of GIF images to be solidly, dependably reliable for over 10 entire years; Wikipedia is continually in a state of flux, unpredicatable in every aspect.

Those are some of the many issues involved, when considering all aspects of the other-language Wikipedias. -Wikid77 (talk) 12:36, 12 April 2009 (UTC)

That's a shotgun blast full of explanations, but you haven't addressed my specific point, which is why are you not proposing a template called "Multilingual DTS" or "mldts" which eventually when it's obvious claim to superiority and success become better known will merge into dts? You are going to invent this thing for NRHP only, when its a general problem with nothing particularly germane to Historic sites? It would be different if you were talking about creating a multilingual infobox for example, where it would make sense to develop them separately. Also, I know you have a character counting bias, but I'd prefer on option which does not abbreviate the month names. dm (talk) 15:14, 12 April 2009 (UTC)

Fort Ticonderoga FA candidacy is open

I've nominated Fort Ticonderoga (NHL and NHRP entry) for FA. Feel free to comment, support, or object, on the candidacy page. Magic♪piano 17:56, 15 April 2009 (UTC)

Punctuation question

In naming NRHP articles (and therefore the links in our table lists), what is the proper punctuation for sites with names like "John Peace Jr. House"? Should there be a comma both before and after "Jr."? No commas at all? Just one comma before "Jr."? What about a name like "Hamilton C. Jones III House"? Any commas there? For some reason, I've taken to using two commas with Jr. or Sr. but no commas with III, but I'm not sure that I've always been consistent. Any punctuation gurus out there? I just did a search of the NY Times website for the string "Jr. House" and it appears that they use no commas in situations like this. I also found this (see Rule 7). Is this the way we should go? --sanfranman59 (talk) 02:45, 10 April 2009 (UTC)

The NPS convention is comma before Jr. and Sr. and no comma after ordinals: "John Smith, Sr. House", "Richard Roe III Mansion", "John Doe, Jr. Building". There are no commas before house, building, barn or the sundry other things they name. Einbierbitte (talk) 18:45, 11 April 2009 (UTC)
There are a huge number of apparent errors in NRIS data for these ones, in which apparently the last name field or other entry within various NRIS fields is messed up. Maybe their system simply does not accomodate the Jr. and Sr. or III explicitly, so each data entry person has to try to make it fit somehow, perhaps as a two word last name, and perhaps other ways. Also the punctuation given in the NRHP application forms that the data entry people are working from varies, and whether they should make "corrections" to one way, or whether they should accept varying treatment on the forms, is not clear. The effect is that NRIS database entries for these are haphazard.
In many cases, anyhow, the Elkman-table-generator tables show something like: "John Doe, Jr." or "Doe, John, Jr.", with the "Building" or "House" part of the name omitted. In prcessing these, I generally accept without further checking an "old list" version of place such as "John Doe, Jr. House", which I assume is following the NRHP.COM presentation of the NRIS name. (That may be incorrect to assume: the NRHP.COM version might also lack clarity and "House" could have been added by a wikipedia editor.)
And, I usually correct it to have commas both before and after the Jr. or Sr. These cases are so numerous that I don't list the apparent errors at wp:NRIS info issues. If the NPS convention described by Einbierbitte is deliberate, it perhaps should be challenged/discussed with the NPS for a specific cleanup campaign there and a corresponding cleanup campaign using AWB or other tools here to address articles, list-articles, and disambiguation pages. It's a bit of a mess.
For the time being, I "vote" to enter them with commas before and after Jr. and Sr., no commas for III. doncram (talk) 19:45, 11 April 2009 (UTC)
It can get complicated: Levi F. Warren Jr. High School, which both my brothers attended but from which I was spared by our move to Florida, is listed by NPS as Warren, Levi, Jr., High School). This assumes that it is a high school name for Levi F. Warren, Jr., but in reality it was a junior high school name for Levi F. Warren, The F by the way was always used in the school's name. clariosophic (talk) 20:55, 11 April 2009 (UTC)
If there is NPS style documentation somewhere that addresses this topic, I vote that we follow it. Einbierbitte, did you find something on their web site or somewhere else that states the convention in your message? I looked around a bit on the NPS website and also tried Googling their site, but didn't find anything specific to this issue. There's certainly no consistency in the way the listings are punctuated in the NRIS. If there is no documented NPS convention, I think we should follow some well-established (and documented) convention. I found reference to the Associated Press convention here and to the Strunk and White and Chicago Manual of Style conventions here. The AP uses no commas with Jr./Sr. or with III. The CMOS revised their guideline in 1993 and suggests not using commas at all, but if a comma is used before Jr./Sr., there should also be one after. Strunk and White (1918) say to use commas before and after Jr./Sr., but they're pretty dated now. --sanfranman59 (talk) 17:45, 12 April 2009 (UTC)
Sorry, I mucked it all up. The NPS guidelines state that the name of a famous person should be written as they appear in the Dictionary of American Biography [1]. Otherwise names are written last name (comma) first name (comma) type of building. Since the humanities uses CMOS I suggest we do the same. Meekly yours, Einbierbitte (talk) 19:57, 14 April 2009 (UTC)
Well I'm not sure that 4 editors can be called a consensus, but absent any objections to using the CMOS convention of no commas in these situations, I'm going with it. --sanfranman59 (talk) 06:19, 18 April 2009 (UTC)

Four NHLs likely to close

On 4 March 2009, the Pennsylvania Historical and Museum Commission (PHMC) released a study of its 22 museums and historic sites, here: "Planning Our Future: Sustainability Committee Final Report". It recommended discontinuing operations at six of its sites, four of which are National Historic Landmarks. Proposed cuts to the PHMC budget mean these sites could close as early as July 1, 2009:

Contact information for the Governor and Director of the PHMC are here for anyone interested in commenting on the proposal. Ruhrfisch ><>°° 04:11, 12 April 2009 (UTC)

The Joseph Priestley House article is right now the featured article on Wikipedia's main page. Mention of closure possibility appears in the part exerpted there. The revisions to the article and arranging for featuring, and mentioning here, seem like good steps for calling appropriate attention to the closure threat. I've drafted a letter to send, myself, and will post some part of it as an example later at User:Doncram/PAclosuresLetters. doncram (talk) 18:27, 18 April 2009 (UTC)

National Register on Flickr

The National Register people now have their own Flickr account, and are putting up many photos of sites across the nation. http://www.flickr.com/photos/nationalregister/ --Marcbela (talk) 19:03, 17 April 2009 (UTC)

Can we use these photos here? My eyes glaze over when I try to understand the WP rules in this regard. --sanfranman59 (talk) 06:22, 18 April 2009 (UTC)
Yesterday I added an external link to a Flickr photo of this contributing property, Chapel of the Good Shepherd (Chautauqua, New York), and was promptly reverted with a terse, No blogs here. I questioned the revert on that editor's talk page, but have had no reply. To say that we can't even link to Flickr seems ridiculous IMHO. clariosophic (talk) 22:54, 18 April 2009 (UTC)
Hmm, bizarre about the National Register account on flickr, posting photos with "All rights reserved". To participate in recent wp:Wikipedia Loves Art event, lots of wikipedians including me had to learn how to post in Flickr with broader licenses than that! doncram (talk) 23:07, 18 April 2009 (UTC)
They (NR/Flickr) have posted the following disclaimer on their Flickr profile page: Photographs posted by this account are from the official National Register and National Historic Landmarks archives - courtesy of the respective State Historic Preservation Offices (SHPO). Some of our photographs were taken by NR/NHL staff members. We have posted photography in order to increase knowledge of our listings and the history behind their significance. We ask that you take a look at our Copyright Statement before using the pictures. Our second reason for joining was to increase dialogue with you. We encourage Flickr users to post feedback and ask us questions. We may contact you for permission to feature your photography on our website. My question the, which photographs were taken by NR.NHL staff? Shouldn't these be "public domain", if taken by Federal employees? Perhaps I should send some "feedback". --Marcbela (talk) 00:43, 19 April 2009 (UTC)
As a side note - the Library of Congress also has a Flickr account, and all of their photos are "no known copyright restrictions", which is great in my book. --Marcbela (talk) 00:51, 19 April 2009 (UTC)

Another RR Station merger

Found another potential merger of articles on a historic and a commuter railroad station, this time on the MARC Brunswick line. Gaithersburg (MARC station) with Gaithersburg B & O Railroad Station and Freight Shed. Evidently at least one of the two buildings in the historic former B&O station and freight shed is operated by MARC. I've already addressed the issue on the proposed mergers page, as well as WikiProject Trains. ----DanTD (talk) 19:52, 17 March 2009 (UTC)

Hey DanTD --- thanks for merging the Gaithersburg (MARC station) with Gaithersburg B & O Railroad Station and Freight Shed. Looks great. Would you also agree that Laurel (MARC station) be merged with Laurel Railroad Station (Laurel, Maryland)?--Pubdog (talk) 11:26, 22 March 2009 (UTC)
If they happen to be one in the same, sure. You've got plenty of incidents where railroad companies have replaced old buildings with new ones, while old ones get used as museums like Huntington Railroad Museum or listed on the NRHP, like Rockville Railroad Station, or Chicago and Northwestern Depot (Wilmette, Illinois), and I suspect Hialeah Seaboard Air Line Railway Station. ----DanTD (talk) 12:34, 22 March 2009 (UTC)
Oops! Looks like this image confirms that they are. One more merger coming up. ----DanTD (talk) 14:08, 22 March 2009 (UTC)
Thanks! I went ahead and tidied up redirects. Best wishes--Pubdog (talk) 17:25, 22 March 2009 (UTC)

Yet another

Guess what I just found out after checking your redirects, Pubdog. The Bowie Railroad Buildings also happens to be the Huntington Railroad Museum. So how should these be merged, if they should be merged in the first place? ----DanTD (talk) 02:46, 23 March 2009 (UTC)

That's a tough one ... let me take a look at it.--Pubdog (talk) 12:55, 4 April 2009 (UTC)
I went ahead and completed the merge--Pubdog (talk) 10:12, 19 April 2009 (UTC)

And another ...

DanTD, please take a look at Charleston, West Virginia (Amtrak station) and let me know what you think.--Pubdog (talk) 12:55, 4 April 2009 (UTC)

Fourth of July, 2009, goals?

I thought last year's Fourth of July or Bust drive, which focussed on NHL articles, was a big success; a couple people commented that participating in it was among their most fun wikipedia experiences to date. The 4th of July date seemed like a good end-point. While i wouldn't want to have to match last year's big effort, I wonder about our doing a new drive this year. Perhaps we could focus on finishing out the table-izing of the NRHP list-articles, and adding WikiProject NRHP to all of the list and individual NRHP articles? By the way, about 39 states are fully table-ized now, and while our wikiproject claims 18,982 articles there seem to be a lot of list-articles and individual NRHP articles lacking wp:NRHP identification. doncram (talk) 10:32, 1 April 2009 (UTC)

Oh, by the way, the Brits are jealous of our nice NRHP lists, as evidenced in this discussion. :) doncram (talk) 10:37, 1 April 2009 (UTC)
I'm happy to be part of whatever drive happens, last year was fun. I think we need some sort of "here's what need to be done, claim a chunk" list to start from. I'm not sure of all the steps that happen in the table-izing. As far as adding the wikiproject, would you just need to go through one by one and check each article to see if it was there? Lvklock (talk) 04:46, 5 April 2009 (UTC)
Well, the coordinates can be double checked to make sure that the tables and the articles match with each other and with maping programs like Terraserver or Google or whatever (does doing your own GPS count as OR?) Einbierbitte (talk) 19:44, 5 April 2009 (UTC)
Hmm. The NRHP list table-izing is actually pretty nearly done now, and it has gotten rather complicated with all the steps that Sanfranman59 and Nyttend and I and some others have worked out to do for each one. It will indeed be a pretty major milestone, when the NRHP lists all get table-ized, but table-izing does not lend itself well to involving a lot of people. About coordinates, I wouldn't know how to do that. There apparently are more accurate National Register-provided coordinates in some Google Earth "layer", more accurate than the NRIS provided ones; it is too complicated for me to understand. Maybe it would be good to just reprise last year's NHL focussed drive: revisit all the NHL articles and further fix them up a bit, and perhaps this time also create short descriptions in the state NHL list-articles? That would allow many people to contribute, and can be divvied out by state and claimed, etc. Note, we didn't actually accomplish everything hoped for last year, like getting NHL webpage links into every NHL article, in part because the NPS's NHL webpage system was inconveniently out of order near the end there. How about that, a refocus on NHL articles + list-articles? doncram (talk) 09:08, 6 April 2009 (UTC)
I guess there's not interest, or not sufficient interest, to doing a drive on the NHLs again. And actually there are a lot of tasks which can be separated out, in bringing the NRHP lists to pretty good condition. Einbierbitte, could you give more specifics on what to do with respect to coordinates? Also, there is some possibility of coordinating with the National Register to get a better set of coordinates. I'll list out some other stuff now. doncram (talk) 21:05, 9 April 2009 (UTC)
I'm home from work, relaxing with Wiki....I'm not doing the prioritizing and figuring out what needs to be done....you can figure it out and assign me a task.  :) I was fine with NHL stuff, I'm also fine with NRHP list stuff. I'm pretty good at descriptions. I don't mind working through lists checking things methodically. I'd probably be willing to learn AWB. Lemme know what you want me to do. Lvklock (talk) 00:20, 10 April 2009 (UTC)
Headed to Charleston, West Virginia next week for an archives conference. Have completed stubs for NRHP in Charleston, WV and should get some good pics.--Pubdog (talk) 00:36, 10 April 2009 (UTC)
Did what I could in Charleston ... enjoy the pics.--Pubdog (talk) 10:14, 19 April 2009 (UTC)

possible 4th of July 2009 NRHP drive tasks

  • Table-izing
    • Finish table-izing last 10 states: List of RHPs in GA, SC, AR, NC, OK, TN, SD, IN, MO, MS. (Doncram, Sanfranman59, Nyttend, KudzuVine, perhaps others working on some of these)
    • In table-izing, check all bluelinks to disambiguate names of places, identify new dab pages needed and start them or note them at wp:NRHPdab.
    • For List of RHPs in DC move rows now identified as to location, to separate NW, SW, SE, NE list-articles. Renumber all component lists, and report a D.C.-wide total.
  • Table-ize Puerto Rico and other non-states. If Elkman would assist, that would help greatly. The current county-table-generator tool does not work for these ones.
  • For table-ized states, fix up coordinates, per Einbierbitte's suggestion
  • Need several more people up to speed in being able to use Auto-Wiki Browser wp:AWB
  • Use AWB to create/visit all Talk pages in NRHP category for a given state, and add wp:NRHP template + state, local geo wikiproject templates
  • Visit NRHP list-articles in a given state. Check that Google/Live Search map works. Check categories, similar.
  • Visit NRHP articles in a given state. For Georgia ones, fix map display to show state rather than country of Georgia. Identify and address other state- or local-specific issues.
  • Contact state, local geo wikiprojects at their Talk pages, to identify local issues, also to enlist photographers, writers
  • Visit state, county articles to add links to the NRHP lists. Add NRHP lists to state-wide lists of lists.
  • Some of this could possibly be done by bot request instead, but other stuff not.
  • Finish stubbing out List of RHPs in MA, so will have 3 states (with FL, MD) all with stubs. (Swampyank may be doing)
  • Finish cleaning up several large cities to be presentable. List of RHPs in NYC, List of RHPs in Los Angeles, List of RHPs in Chicago, List of RHPs in Baltimore, List of RHPs in Seattle, List of RHPs in Portland, List of RHPs in Philly, List of RHPs in Pittsburgh, List of RHPs in Detroit, List of RHPs in San Francisco, List of RHPs in Denver are some that have been worked on. Some in good shape, others not. List of RHPs in Boston in progress (Marcbela, perhaps others fixing up). Could we address, say, the top 5 U.S. cities out of the List of United States cities by population, and selected others?
  • Disambiguation
  • (Add more)

The Wrong Georgia

I got a chuckle seeing the inset map for the article on Thomas County Courthouse (Georgia). The map is for the country of the same name. I wonder if other listings in the State of Georgia have the same issue.--Marcbela (talk) 15:09, 20 April 2009 (UTC)

Photo requests

Hi, all. I'm the operator of PhotoCatBot, a bot that maintains and categorizes image requests performed via the {{reqphoto}} template.

I recently noticed that a lot of articles tagged as needing a photo already have photos or images on the main page that seem to satisfy the request, so I implemented a new feature to identify articles which may have "stale" photo requests. You may have already noticed this, but in case you haven't: the bot checks all articles that use {{reqphoto}} on the talk page, and if the main page already appears to use a JPG or PNG image, it adds the article to Category:Articles which may no longer need images.

I have been having discussions with doncram, who is unhappy with the use of {{reqphoto}} templates on NRHP articles in general and PhotoCatBot in particular. He can speak for himself, of course, but my understanding from our conversation is that the bot is generating a level of edit traffic on NRHP articles that adds a lot to the maintenance cost and time, and does not usefully improve the articles themselves. He has asked if I would exclude all NRHP articles from those which the bot addresses, and suggested that editors here may have opinions on the subject.

If the operations the bot is performing are genuinely unuseful to NRHP articles, I'll be happy to exclude them, but I would like to check first to see if there is something else that we should do to improve image coverage for NRHP articles on Wikipedia.

My goal is to make the {{reqphoto}} template as useful and accurate as possible and to encourage other editors to use it as a guide for taking new photographs for articles. I would like to think that the NRHP articles could benefit from that as much as anyone else. What can we do to best improve photo coverage for the NRHP? Please let me know. Tim Pierce (talk) 20:59, 20 April 2009 (UTC)

Is it possible to have the bot check the {{Infobox nrhp}} template and see if there's an image specified there? For example, Montpelier Historic District (Montpelier, Mississippi) (edit | talk | history | protect | delete | links | watch | logs | views) has no image listed in the infobox, so the reqphoto request is valid. 131 Charles Street (edit | talk | history | protect | delete | links | watch | logs | views) has a photo, but not in the infobox, so it no longer needs the reqphoto request. On the other hand, Fort Campbell (edit | talk | history | protect | delete | links | watch | logs | views) (which isn't on the National Register) has images, but just insignia and no pictures of the actual fort. Thus, it probably still needs {{reqphoto}}. I'm having trouble finding NRHP articles that have a reqphoto request and actually say something in the "image=" line. I suspect that's why the bot puts those articles into a category saying, "Articles that probably have a picture but still contain the request" -- to make sure a human being actually reviews the article for an appropriate picture.
As far as my general feelings about photo requests are concerned: My feeling is that whenever possible, any article about a property on the National Register should contain a relevant photo. If a building, structure, or other site is on the National Register, that means there's a story to be told about it, and we should enlighten the reader and provide some interesting context. That's one of the reasons why I (and other editors) went out to take photos of everything in National Register of Historic Places listings in Hennepin County, Minnesota -- to make the list, and the corresponding articles, as good as possible. That's also the reason why I don't write two-sentence stubs. That's also the reason I coded the {{reqphoto}} request in the default talk page output of the NRHP infobox generator. --Elkman (Elkspeak) 22:23, 20 April 2009 (UTC)
You've raised a good point. At present, the bot won't recognize that the 'image' parameter to {{Infobox nrhp}} is an image, because it's not formatted as one; if it were written as image = [[Image:Historic Place.jpg]] then it would understand that was an image. I can write an additional rule for {{Infobox nrhp}} so that it will understand the image parameter there. (I think that will not answer Don's objection, which is that the bot already updates too many articles and that the updates are not helpful, but maybe I have misunderstood him.)
I agree with you about the importance of finding suitable images for NRHP articles, and I suspect that just about every editor here agrees, in principle. The question is really whether this is a productive way to go about that goal, and if not, what we should do to make it work better. Tim Pierce (talk) 00:41, 21 April 2009 (UTC)
Well, I'd say we all believe good images are important to the articles, and I don't think anyone has a problem with the reqphoto request. My understanding of the issue is that the bot tags articles that may no longer need the reqphoto tag. One example I saw was a list article that had many, but not all photos filled in. It was still in need of images, but the bot supposed that maybe it wasn't. I generally try to remember to take the reqphoto out if I've put pics in, but I also see no harm to the request remaining there if it's left as an oversight. Someone else could take a better or different picture that could make the article better. I don't see the point of a bot that requires the checking of many articles to see if, indeed, the reqphoto tag should be removed. Am I missing something? Lvklock (talk) 01:49, 21 April 2009 (UTC)
In fact, I think it is a bad thing if a reqphoto template gets left behind after the requested photo has been added. It's sort of like tagging every article in the encyclopedia "needs work" -- of course every article could use work, but if you mark every article that way, how will editors tell which ones are most in need of work? Or, as a manager of mine once remarked, "If everything is 'top priority,' then nothing is really top priority."
Speaking as an (amateur) photographer, I'm interested in taking pictures that will improve Wikipedia wherever possible. The easiest way to do that is to look in Category:Wikipedia requested photographs (and its subcategories) for subjects that I have pictures of or can take pictures of. But if many of those articles still have unnecessary reqphoto templates on them, it makes my work more difficult.
So from my perspective, the 60,000 or so articles that use {{reqphoto}} have to be checked anyway. What the bot does is to help narrow that down to a more manageable number. Tim Pierce (talk) 02:18, 21 April 2009 (UTC)
I can see your point. However, in my experience, quite often just because the article has AN image wouldn't mean I wouldn't like to see more. If the article has only an historic picture of a place, I'd like it to also have a contemporary picture, for example. I guess personally, for my watch list it's not too big a deal, because I keep my watchlist pretty small. For someone with a huge watchlist, the bot entries would probably be annoying, and not result in any good attention anyway, as they'd just ignore them. I'm not too invested, either way. Just voicing my opinion. Lvklock (talk) 02:27, 21 April 2009 (UTC)
To be clear, I have no objection at all to adding {{reqphoto}} to an article that has photos but which still needs more, or which has only a poor-quality photo that should be replaced. I would ask only that if an article already has images, editors should be precise about what else they'd like to see, preferably by adding an "of=" parameter to the reqphoto template. It may not be obvious to the next editor who comes along. Tim Pierce (talk) 02:31, 21 April 2009 (UTC)

(unindent) Tim Pierce, thanks for taking my comments positively and posting here. Several comments:

  • What I started noticing was the bot adding a "check me" type category to list-articles, like List of NHLs in MT. We have more than 1,000 list-articles in Category:List-Class National Register of Historic Places articles. Of those, we already know that we have twelve that are fully illustrated, see Wikipedia:WikiProject National Register of Historic Places#List of fully illustrated lists. It is not helpful for a bot to tell us that there is one or more pics already, in however many of them. They all (besides those 12) need pics, even tho they mostly have some pics already. So, perhaps your bot could at a minimum exclude any in that list-article category. There are some list-articles that do not have the List-type category, as for example the MT NHL list which is rated "Start" instead, but those are relatively few.
  • About the bot making suggestions at regular NRHP articles, I have not noticed that much yet. Some particular examples would be helpful in informing this discussion. If your bot credited images that are included in the NRHP infobox image field, which it has so far been missing I gather, then it would start making a lot more edits on our watchlists. I do notice at your own Talk page and/or the PhotoBot's Talk page that there are comments from several persons, including i thot Nyttend (who is a wp:NRHP member) that your bot was malfunctioning, returning immediately to remark articles after someone responded and removed a false positive marking. Also there is comment that your bot should give more indication, of use of some refinement of reqphoto to specify that although an image is present, more or other images are still wanted. Personally, I think that more images are always wanted, and questioning whether a template that nicely asks for photos should be removed, is not a help. I don't know of any cases where we are receiving too many photos and we need to turn off an incoming stream of them.
  • Bottomline, and of major importance to understand, is that this Wikiproject is different. I was involved in some discussions a year or two ago about the reqphoto system, and I understand that it basically doesn't work. My impression is that it has a lot of overhead, with very little gain: very few cases where any wikipedians have gone out to take pictures based on finding there were pictures needed in their home state or county, in a category there. A big failing of the system for geographical places is that the system does not provide coordinates. I know it is a programming problem, beyond your and my hands. The current system just says photos are needed in a big area, not where the place is. What we have done in this wikiproject is invest, instead, in building list-articles that are indexed under List of RHPs. These NRHP list-articles ask implicitly, strongly, for photos and provide a place for people to upload them to. The coordinates with the Google/other map links provide coordinates, so that people can look up where are the places that photos might be needed. This has been proving to be a huge success. Users like User:Royalbroil in Wisconsin, User:Rosiestep in California, User:Hustvedt in Colorado, and others have been happily uploading, and this has been motivating me and others to finish out the list-article system (10 states to finish, plus Puerto Rico and other non-states). NRHP, within wikipedia, could well be gaining more "requested" photos that way than any other wikiproject, than any other area within Wikipedia. I am proud of that, i think we all should be.
  • And, this doesn't necessarily have to be concluded from the above, but I further think we might be best served by asking for a bot to rip out the reqphoto from all of NRHP articles. I think it is clear in our infoboxes and in our list-article tables that we want photos, and it is working. To whatever extent we get bogged down in the reqphoto system, which largely does not work, that is just taking away productive effort. We have a system that is working, and I sorta think we should jettison the system that is not working. Let others try to make the reqphoto system to work in areas where there are not list-tables with coordinates like ours. I generally don't want to be bothered by a bot.
  • Note, what the bot does is say: check, now, something. It is trying to force me to do something, and it adds no value (to be a bit harsh). I'd rather organize conscious cleanup campaigns on one state at a time, or one category of trains-related or other type of listings, in which many things would be addressed, not just simply whether it is justifiable to remove a reqphoto. The value the bot provides is only indirect, not for NRHP, in that it slightly supports the reqphoto system by ensuring it has fewer bad requests. I say, remove all such bad requests from NRHP articles by removing all reqphotos!
  • As a possible alternative/extension for the reqphoto system: how about helping us change over from the simple reqphoto in our list-articles, to some kind of multiplepicswanted template? One that would advertise/convey that these are great places for photographers to check out: they are list-articles, they have coordinates, etc., there are still some pics needed. I think all the separate, individual reqphotos in individual NRHP articles are not helpful for photographers, would only draw away attention from these supergreat places for potential photo-adders to consider. That's another reason to rip out reqphoto from individual nrhp articles, so as not to dilute attention to where photo-adding can be most productive and satisfying (and where there are links to all the individual Nrhp articles anyhow). doncram (talk) 02:48, 21 April 2009 (UTC)
Don, you raise an excellent point about list articles. I will modify the bot to ignore any "List of...." article in any category, since I think that probably applies across the board.
I understand your point that more images are almost always better. But please consider this: removing all photo requests from all NRHP articles is tantamount to saying that it's no more important to add photos to List of Masonic buildings (which has no images) than to National Register of Historic Places listings in Boston, Massachusetts (which has well over a hundred). I am not at all sure that helps achieve your goal.
I would still like to hear feedback from other editors about whether PhotoCatBot is sufficiently disruptive to WikiProject NRHP that it should avoid the project entirely. Tim Pierce (talk) 03:10, 21 April 2009 (UTC)
Okay, good about stopping it from touching the list-articles. Well, maybe you could clarify what PhotoCatBot is supposed to do. All i understood was that it was starting going through all the NRHP articles and adding a new "check-me" type category, to any articles that have a photo. It will do so with error, missing some that have photos, and misidentifying some that don't have photos (but rather have a map or a company logo or something else). Basically it calls for human attention, to answer the bot, and to remove a reqphoto tag if incorrect, or leave the reqphoto tag if it is correct. It doesn't give any help finding a photo. Please clarify what i am missing, but I don't see how that helps. Anyhow I am not getting what is the value of any disruption along these lines at all. Sure, others should comment too. doncram (talk) 04:19, 21 April 2009 (UTC)
That's basically correct. The bot flags articles that it thinks should be checked by a human. The point is to make the use of {{reqphoto}} templates more accurate and therefore more useful. You've made it clear that you think {{reqphoto}} is a gigantic waste of time, so I don't expect to convince you that this is helpful. I ask you only to take my word that it is a useful tool for photographers.
And, for what it's worth, {{reqphoto}} is how we doubled the number of photographs on National Register of Historic Places listings in Waltham, Massachusetts just this evening. :-) Tim Pierce (talk) 04:33, 21 April 2009 (UTC)
Hey, that's funny, when i go to see the list-article. :) It's indeed very nice that you added 4 pics to the Waltham list, which now has 8 pics towards covering the 108 NRHP places listed. And, it is a list-article that has no reqphoto template attached! :) To clarify, or perhaps to change my position somewhat, and in part to support your basic interest in improving the reqphoto system, I am not opposed to doing a cleanup drive on NRHP articles that would, among other things, review whether reqphoto templates should be added or dropped. I would help organize and participate in such a drive, perhaps starting with the Massachusetts NRHP listings. Before doing so, though, some more direction would be needed. Some questions: How is one to indicate for reqphoto that it is a list with many photos needed (a new feature needs to be added to reqphoto perhaps)? How is one to indicate to potential photographers that coordinates and addresses and other good info is present? How are we to indicate that a photo is present, but more photos are desired, or that better photos are desired? How is one to indicate, convincingly, to your bot, that, if we identify it is making a bad suggestion, that it should not return the next day to mark it again? I would prefer to engage in a conscious cleanup drive that would address other matters of importance in developing the NRHP articles, too, not just respond to the bot's focus. What do I or we have to promise, to get you to agree not to run the dreaded bot? :) doncram (talk) 21:40, 21 April 2009 (UTC)
If there's a photo on the article but the photo doesn't look all that great, then it's possible to use parameters to {{reqphoto}}. For example: {{reqphoto|in=Minnesota|of=the interior of a jail cell}} would come out as:
A bare {{reqphoto}} request, by itself or with a location, might confuse editors who see an article that already has a photo. If I saw a reqphoto request at Talk:Crow Wing County Courthouse and Jail and I noted that it already had photos, I'd just clear the request without realizing that someone wanted to see the interior of a cell. I wouldn't go to the trouble of taking a tour of the old jail and getting a photo of a cell. {{reqphoto}} has additional documentation parameters on it. --Elkman (Elkspeak) 22:09, 21 April 2009 (UTC)
(insert after ec) Thanks for providing a specific example to look at, for an article that the PhotoBot would probably raise a question. You seem to be observing that the current reqphoto template is not very clear in allowing for requests of additional photos. Are you suggesting that reqphoto is, in a sense, not ready for wide use? I don't want to twist your words, but your observation seems to suggest to me further reason for us to insist on improvements to the reqphoto system, or reason for us o drop our use of it. I notice in the template here a link to "Free Image Search Tool". For NRHP sites, it would be highly relevant to be able to indicate whether Historic American Buildings Survey photos or National Park Service photos taken by NPS employees are available for uploading. That Free Image Search Tool doesn't seem to address those. Could the reqphoto template be adjusted to allow us to indicate that HABS or NPS photos are available? I've noted HABS or NPS photo availability in many a talk page, and also in many list-articles at the point where a photo would be added, but it is often ripped out (or commented out) by others from the latter. Could the reqphoto template be adjusted to allow for HABS and NPS photo availability? doncram (talk) 22:52, 21 April 2009 (UTC)
The HABS and NPS photo sources, and many others, are listed on the {{US image sources}} template, which appears on Category:Wikipedia requested photographs in the United States and its subcategories. Tim Pierce (talk) 23:15, 21 April 2009 (UTC)
That's not my question. I and many others here are very well aware of HABS and NPS and perhaps other sources for photos. I am asking, instead: when i know there is a specific HABS or NPS page (and i could provide the URL even) which has a photo that could be uploaded and used in the article, could the reqphoto template receive that, and state nicely that photo(s) are available to be uploaded. Or, not knowing for sure that such a photo is available, could I ask that HABS and NPS be checked? This is the same question, more specifically posed, as is outstanding as an unanswered question at Wikipedia talk:WikiProject Photography#Photo requests. doncram (talk) 23:31, 21 April 2009 (UTC)

(unindent) Elkman is exactly right. Using {{reqphoto|of=...}} should be sufficient to communicate "more photos are needed than the ones already on the page." That is useful not just because it keeps the bot away but because it makes your intent clearer to other editors. I have also made the change, as suggested above, to ignore any article titled "National Register of Historic Places listing..." Between those changes, and the six-month span between article updates, I think the bot's behavior will be much less objectionable to you.

Don, I think you have great ideas about expressing geolocation coordinates of requested photographs, and I encourage you to bring those ideas to Template talk:Reqphoto or to WikiProject Photography. I have been thinking some things along the same lines, but it's not really relevant to NRHP specifically.

I will be delighted to take part in more discussion about how to improve photo coverage for NRHP articles, if there's interest in that, but I hope that we can put this particular discussion about PhotoCatBot to rest. Tim Pierce (talk) 22:48, 21 April 2009 (UTC)

Hey, wait, Elkman said just the opposite! I interpret Elkman to be saying that the "of" parameter does not actually work (the template is not adequately clear). And, you are not clarifying how use of the "of" parameter is supposed to allow for us to ask for better or more pictures, rather than for a picture of a specific feature of a site. Please also see my discussion contributions from about a year ago in Template talk:Reqphoto#Geographic coordinates parameter for Reqphoto, Template talk:Reqphoto#reqphoto is broken, links to "Wikipedians in..." not to "category: photos requested in..." where i participated previously. The former links, using my name, to discussion i was involved in at WikiProject Photography. Revisiting those just clarifies for me that reqphoto is not ready for wide use. For example, there is what I perceive to be a very unuseful link to wikipedians in a given area, which a) doesn't contact them, b) seems to blame them for lack of a photo, c) seems to show an unthinking design for the template. I tried to support the reqphoto system. I think that review of past discussion of Elkman's tools would show it was my use of reqphoto that Elkman then adopted into the basic NRHP infobox tool. But, it has been a long time, and the reqphoto system doesn't work, and if anything this discussion just clarifies for me that reqphoto should be ripped out of the NRHP articles. I don't want some bot telling me to check to see if the bot was right in asking me to check on it, with no gain for the articles. doncram (talk) 23:22, 21 April 2009 (UTC)
But, no one else is seconding about removing reqphotos, which would be a bit extreme. Twp, you should go ahead and run the photobot. Thanks for pausing and discussing, and thanks for agreeing to refine it somewhat.doncram (talk) 04:30, 22 April 2009 (UTC)
Nice to see this matter has been pretty much talked out without me. What does not seem covered yet is, shouldn't the bot put a mb in the watchlist so those who are bothered by this traffic, useful yet not directly of interest, don't have to see it?
Oof, tired out from an afternoon of bicycling around Jamaica Bay snapping pictures. When planning a photo expedition I never use the reqphoto categories because they're too big, at least around NYC. Were all the requests broken down by township or at least by county (and less important, the flag taken down where the pix are satisfactory), that would make those cats more useful. Then I'd have to get a printer to print out a Google map of a territory. As it was I spent 20 minutes hunting down the Russell Sage Memorial Presbyterian Church. Then it was a poor sun angle. I have also been visiting pages that are on my watchlist because I put my pix in them, and taking down the reqphoto flag. Except when it's just too poor a picture and I've got to hope someone will do better. Jim.henderson (talk) 03:39, 26 April 2009 (UTC)