User talk:Epicgenius/Archive/2019/Nov

DYK for Bronx International Exposition of Science, Arts and Industries
Gatoclass (talk) 00:02, 3 November 2019 (UTC)

DYK for Seneca Village
Gatoclass (talk) 00:02, 6 November 2019 (UTC)

Disambiguation link notification for November 11
An automated process has detected that when you recently edited Riverside Church, you added a link pointing to the disambiguation page Bloomfield Township, Michigan ([//dispenser.info.tm/~dispenser/cgi-bin/dablinks.py/Riverside_Church check to confirm] | [//dispenser.info.tm/~dispenser/cgi-bin/dab_solver.py/Riverside_Church?client=notify fix with Dab solver]).

(Opt-out instructions.) --DPL bot (talk) 08:19, 11 November 2019 (UTC)

Sorry
Hi ,

Since you already reverted my edit, and seeing your edit summary, I felt a personally-delivered apology and explanation was appropriate.

This user is sorry, had the best of intentions, and is reverting his good faith edits. See the discussion.

Cheers,

--Doug Mehus T · C  18:59, 11 November 2019 (UTC)

DYK for Beekman Tower
Gatoclass (talk) 00:01, 12 November 2019 (UTC)

Saturday Nov 16: Wikipedia Asian Month Edit-a-thon @ Metropolitan Museum of Art
(You can subscribe/unsubscribe from future notifications for NYC-area events by adding or removing your name from this list.)

Please comment on Wikipedia talk:WikiProject Islands
The feedback request service is asking for participation in this request for comment on Wikipedia talk:WikiProject Islands. Legobot (talk) 04:30, 15 November 2019 (UTC)

DYK for Staten Island Quarantine War
valereee (talk) 00:01, 15 November 2019 (UTC)


 * Please see Feeling feverish. Shenme (talk) 06:05, 15 November 2019 (UTC)

A heads-up
I started working on User:Geo_Swan/Simon_Baron_Development, and I thought I would let you know, because it is related to Anable Basin, an article we both worked on. I am of two minds whehter more work, to bring it to article space, would be worthwhile. Quality control volunteers are tougher on articles on corporations than they are for articles on many other topics.

Cheers! Geo Swan (talk) 13:24, 15 November 2019 (UTC)


 * Thanks for the heads up. epicgenius (talk) 13:30, 15 November 2019 (UTC)

Please reconsider...
In this edit you changed a list-defined reference to an in-line reference.

Isn't doing so a lapse from the long-standing principle of "if it is not broke, don't fix it..." I've encountered individuals who make this kind of change due to a good-faith misunderstanding of some of our wikidocuments, which warn against "changing citation styles without consensus".

Inline references that wrap a pair around a cite template, and list-defined references that that wrap a pair around a cite template, are both instance of our single most popular citation style.

For its first few years the WMF software we use did not support references, and no articles used them. I was a contributor in during the 2005-2006 period when support for references began. References were obviously far superior to the bare-urls all articles had used up to that point.

Several mutually incompatible citation styles were introduced. I first discovered a different, inferior style, and used it for months.

I know, from personal experience, how problematic the incompatibilities between these styles were. I know, from personal experience, why wikidocuments warn about recklessly mixing styles, or recklessly converting styles. I personally rewrote the references in dozens of articles that had used the older style, when I had been the primary author of those articles. I did so because the older style was a maintenance nightmare, when the pair citation style had become so overwhelmingly popular that most contributors didn't know they were screwing up older articles that used earlier styles.

When I find it necessary to add fields to, or otherwise amend, inline references, or references that stuff all the fields on a single line, I leave those references as-is, as much as necessary, so it comply with the long-standing principle of "if it is not broke, don't fix it..."

While it might be more esthetically pleasing, and more convenient, for me, if I rewrote those references, I know doing so strongly erodes the value of diffs.

When I get a google news alert emailed to me, on a topic I have worked on, in the past, that looks like it will require updating an article I have worked on months or years earlier. I try to do a diff between the last version I made and the current version, hoping it will show me whether someone else has already updated the content.

Sadly, what I usually find is that the diff shows so many changes it can't tell me whether the article's actual content has been amended.

To figure out whether the content has been updated I am forced to step through every single revision, one at a time. And, sadly, what I usually find is that all the intermediate edits were either trivial changes to spelling, or punctuation, or were changes to the articles metadata.

Unnecessarily moving references around, for purely esthetic reasons, is short-sighted, as it makes the maintenance of the article's actual content, what it tells our readers, much more difficult. Geo Swan (talk) 03:58, 14 November 2019 (UTC)


 * Thanks for your message. However, see WP:CITEVAR for why I moved the reference to the body. Specifically, the portion that says When an article is already consistent, avoid [...] changing where the references are defined. All of the references are already in the prose section of the article, so there's no reason to have that one list-defined reference.I concede it may have seemed like a violation of CITEVAR by moving that one reference to the body (I don't think it's a true contravention of the guideline, since i was placing the references in a consistent location). But by that reason, you definitely also violated that guideline by unnecessarily moving it back without any change in the prose, with the edit summary please don't unnecessarily rewrite references for purely esthetic reason. In any case, this is a guideline, not a set-in-stone policy, so I don't really care for where the references are defined, as long as they're all in the same place.Your message is appreciated, but you could've done without the long essay about why diffs cannot be examined properly when the references are all in the text. That's probably one of the lower priority things that even content creators worry about. Moreover, there are many tools to format/organize/fill out references, and it would be an uphill battle to ask every single editor to conform with a specific style. TL;DR there are bigger problems to worry about than where the reference is defined. epicgenius (talk) 04:14, 14 November 2019 (UTC)
 * (Sigh) I think you are misinterpreting CITEVAR.
 * {| class="wikitable"

! citevar || notes Not applicable, as the article uses what CITEVAR refers to as the Help:Footnotes style, and I merely introduced one more refence of that style.
 * + WP:CITEVAR says:
 * When an article is already consistent, avoid:
 * switching between major citation styles, e.g. parenthetical and tags, or replacing the preferred style of one academic discipline with another's;
 * what is a citation style? CITEVAR offers two examples.  WP:PAREN and Help:Footnotes.  Why shouldn't they be mixed, or recklessly switched?  Because different styles, like WP:PAREN and Help:Footnotes, are incompatible.
 * What are commonly called inline references and list-defined references are both instances of what CITEVAR refers to as the Help:Footnotes style. So, placing a brand new list-defined reference, in the reference section is NOT a switching of style.  I didn't monkey with existing, working references.  I introduced a brand new reference, of the same style as the other references in the article.  That is completely compliant with CITEVAR, and every other wikidocument.
 * adding citation templates to an article that already uses a consistent system without templates, or removing citation templates from an article that uses them consistently;
 * what is a citation style? CITEVAR offers two examples.  WP:PAREN and Help:Footnotes.  Why shouldn't they be mixed, or recklessly switched?  Because different styles, like WP:PAREN and Help:Footnotes, are incompatible.
 * What are commonly called inline references and list-defined references are both instances of what CITEVAR refers to as the Help:Footnotes style. So, placing a brand new list-defined reference, in the reference section is NOT a switching of style.  I didn't monkey with existing, working references.  I introduced a brand new reference, of the same style as the other references in the article.  That is completely compliant with CITEVAR, and every other wikidocument.
 * adding citation templates to an article that already uses a consistent system without templates, or removing citation templates from an article that uses them consistently;
 * adding citation templates to an article that already uses a consistent system without templates, or removing citation templates from an article that uses them consistently;
 * adding citation templates to an article that already uses a consistent system without templates, or removing citation templates from an article that uses them consistently;
 * adding citation templates to an article that already uses a consistent system without templates, or removing citation templates from an article that uses them consistently;
 * changing where the references are defined, e.g. moving reference definitions in the reflist to the prose, or moving reference definitions from the prose into the reflist.
 * I introduced a brand new reference. I did not move an existing inline reference to the reference section.
 * You, however, DID move a "reference definitions in the reflist to the prose". So, you did exactly what CITEVAR warns us not to do.
 * }
 * Did I "...definitely also violate[d] that guideline by unnecessarily moving it back without any change in the prose..." No, I restored it to its original location to restore the utility of our diff mechanism.
 * You introduced brand new references in this edit and this edit. You added them, you get what they look like.  You get to choose whether they should be inline or list-defined.  You get to choose whether they should combine all fields on a single line, or devote an entire line to each field.  Wikidocuments let contributors choose these things.  So this edit is, well, wasted effort, and a lapse from the long-standing principle of "if it ain't broke, don't fix it"
 * Everytime one of us lapses from the long-standing principle of "if it ain't broke, don't fix it" there is the possibility we will accidentally introduce new errors into something that didn't have any.
 * I wrote above "When I find it necessary to add fields to, or otherwise amend, inline references, or references that stuff all the fields on a single line, I leave those references as-is, as much as necessary, so it comply with the long-standing principle of 'if it is not broke, don't fix it...'"
 * Some contributors both change the location of where a reference is defined, or whether the fields are all on a single line, or each gets a line of its own, and add new fields, or make what they regard as corrections to those fields. Yeah, it is a serious problem.  Both moving where content or metadata, and changing it, means the diff engine's ability to show those corrections has been defeated.  We are both working on Firehouse,_Engine_Company_261_and_Ladder_Company_116.  And, if I thought one of your references needed an addition, or correction, I'd make it with a minimum of disruption to how you originally wrote it, in order to preserve the utility of the diff mechanism.
 * Oh, I shouldn't forget to say you added good content to that article. Good on you for that.  Geo Swan (talk) 06:58, 14 November 2019 (UTC)
 * I wrote above "When I find it necessary to add fields to, or otherwise amend, inline references, or references that stuff all the fields on a single line, I leave those references as-is, as much as necessary, so it comply with the long-standing principle of 'if it is not broke, don't fix it...'"
 * Some contributors both change the location of where a reference is defined, or whether the fields are all on a single line, or each gets a line of its own, and add new fields, or make what they regard as corrections to those fields. Yeah, it is a serious problem.  Both moving where content or metadata, and changing it, means the diff engine's ability to show those corrections has been defeated.  We are both working on Firehouse,_Engine_Company_261_and_Ladder_Company_116.  And, if I thought one of your references needed an addition, or correction, I'd make it with a minimum of disruption to how you originally wrote it, in order to preserve the utility of the diff mechanism.
 * Oh, I shouldn't forget to say you added good content to that article. Good on you for that.  Geo Swan (talk) 06:58, 14 November 2019 (UTC)


 * WRT to MOS:DATEFORMAT

WRT to MOS:DATEFORMAT, which you cited in two edit summaries, ... Well Manual_of_Style/Dates_and_numbers has two tables.

The table entitled "Acceptable date formats" has six entries. The fifth entry is the yyyy-mm-dd format. This table warns this is an acceptable format "Only where brevity is helpful (refs,[b] tables, infoboxes, etc.)"

The table entitled "Unacceptable date formats (except in external titles and quotes)" has 12 rows. The third row explicitly lists yyyy-mm-dd as an acceptable format.

So, did MOS:DATEFORMAT authorize you to change yyyy-mm-dd format dates, in references to other acceptable date formats that explicitly spell out the month names?

Confession. I don't remember reading MOS:DATEFORMAT closely before. It seems to be saying when I am the one introducing additional references to an article where the references aren't already using yyyy-mm-dd, I should follow the example of the earlier references. Yeah. I've never done that. But I will do so, from here on in. Geo Swan (talk) 07:13, 14 November 2019 (UTC)


 * Unfortunately, I don't have time to read all this (literally - I have class and then work), and I won't be able to spend the time to reply to every single one of your comments. I really don't think this is a big issue, especially not one warranting a 6,000-byte reply with a wikitable and all that. Please provide a summary of what your main point is.
 * The only other thing I'll say at this time is that I moved all of the references in the Firehouse, Engine Co. 261 and Roosevelt Island articles to the same location. This actually does comply with CITEVAR, but judging by what you wrote above, it would be a violation to ever move a reference from list-defined to prose, or vice versa.
 * Also, thanks for your work on the Firehouse, Engine Co. 261 article, it's really appreciated. I think the energy spent on this discussion would be better allocated to improving that article instead. epicgenius (talk) 13:56, 14 November 2019 (UTC)
 * I wrote an essay Every question, every disagreement, is a teachable moment. Our policies are baroque, and in a constant state of flux.  Our policies can be ambiguous, and, in many cases, contradict one another.  And, as DGG has pointed out, our de facto policies are our written policies, as interpreted through our long-standing conventions, which are also constantly evolving.  DGG pointed out that subsections of WP:Arguments to avoid, for instance, are so widely cited, it might as well be a policy, when it is not even a guideline, is only an essay.  While engaging in long discussions may seem like a waste of time, when we have important work to conduct, I think it is nevertheless necessary, because our policies are literally impossible to fully master, and even a very experienced well informed contributor could be making the same mistake, over and over again.  My failure to make sure I adapted the date formats I used in references would be an instance of my making the same mistake, for over a decade, in literally 10s of thousands of edits.
 * My main point? CITEVAR is routinely misinterpreted, and mis-cited, and used to justify wasted efforts that erode the value of our diff mechanism.
 * Do I consider it a policy violation to ever move references from inline to list-defined, or vice versa? Yeah, I try to be careful about stating someone else is violating policy.  I prefer to say "lapse" from policy, when I think the other party is acting in good faith, and the two of us have different good faith interpretations of policy.  There may be the occasional good reason to move references.  I don't think the pretty common misinterpretations of CITEVAR is one of them.
 * Under my interpretation of policy there was nothing wrong with you introducing new references that were inline references, in Firehouse,_Engine_Company_261_and_Ladder_Company_116, when all the earlier references were list-defined.   Policy is silent on where new references are placed, or whether fields were or weren't all stuffed onto a single line.
 * Cheers Geo Swan (talk) 16:26, 14 November 2019 (UTC)
 * OK, that's much more readable. However, I do have some points. (1) If the reference has already been moved, I think it would be quite unproductive to revert that, unless there's a good reason to not make them standardized. (2) MOS:DATEFORMAT is not really that big of a deal either. I use a script to change them all automatically, thus ensuring that all the dates are unified. (3) Not all editors are going to see your reasoning regarding references, or understand why one reference is in a different location from all the others, so this is really an uphill battle, and not worth worrying too much about. epicgenius (talk) 16:56, 14 November 2019 (UTC)
 * So far as I know there is no tool which will compare two versions of an article, analyze the references they use, and report which shared references, used in each version, are no longer functionally equivalent. Restoring a reference to its original location allows using the diff mechanism to check to see if fields have been updated.  Geo Swan (talk) 13:35, 15 November 2019 (UTC)

DYK for Calvert Vaux Park
Cas Liber (talk · contribs) 00:01, 18 November 2019 (UTC)

Growth team updates #11
Welcome to the eleventh newsletter from the Growth team!

The Growth team's objective is to work on software changes that help retain new contributors in mid-size Wikimedia projects.

General news

 * Expanding to more wikis: the team is preparing to deploy Growth features to Ukrainian and Hungarian Wikipedias. Wikis that already have the features are Czech, Korean, Arabic, Vietnamese, and Basque Wikipedias.  If your community is enthusiastic about welcoming newcomers, we encourage you to contact us so that we can verify together if your wiki is eligible. Then you can go through the checklist to start the process of configuring the features.
 * Mentor training: we tried out our first training for mentors with the Czech community, so that experienced users can build skills that help them retain newcomers.
 * The guide for mentors has been updated. Translations are welcomed!

Help panel results
The help panel was first deployed to newcomers in January 2019, and we have now finished analyzing data to determine its impact. A brief summary is below, and more in-depth information can be found here (in English).
 * In summary, although we have seen a good amount of usage of the help panel, the help panel has not shown an increase in activation (whether a user makes their first edit) or retention (whether a user returns to edit again).
 * This is a disappointing result, and our team has discussed potential reasons for the result and ideas for the future. Although we have many ideas for how to improve the help panel, we have decided to keep our attention on the newcomer homepage and newcomer tasks projects for the coming months.
 * We'll be using the help panel as part of the newcomer tasks project: using it to guide newcomers while they complete suggested edits.
 * We welcome questions and thoughts about this on the project's talk page.

Newcomer tasks deployment



 * The first version of the newcomer tasks workflow (V1.0) will be deployed in the next weeks on our 4 priority wikis. This version will suggest articles to edit based on maintenance templates.  In this first version, we expect many newcomers to initiate the workflow, but not many to select articles to edit or complete edits.  We expect future versions of the feature to increase those behaviors.
 * We're excited about this project because the majority of newcomers visit their newcomer homepage, and this will be the first element of the homepage that clearly asks the newcomer to start editing.
 * These are the next two versions of the feature, which are already being planned:
 * V1.1 (topic matching): will allow newcomers to choose topics of interest (such as Art, Music, Sports, or Technology) to personalize their suggestions. After evaluating several approaches, we have decided to use a new ORES model built by the WMF Scoring team.  The model will automatically identify the topic area of each article.  We expect this to increase how often newcomers select articles to edit.
 * V1.2 (guidance): once newcomers arrive on an article to edit, we will use the help panel to provide guidance about how to complete the editing task. We expect this to increase how many newcomers actually complete productive edits.
 * The project page includes links to the designs of the workflow, and we welcome questions and thoughts on the talk page.

'' Growth team's newsletter prepared by the Growth team and posted by bot • Give feedback • Subscribe or unsubscribe. '' 15:02, 18 November 2019 (UTC)

DYK for William Ulmer Brewery
valereee (talk) 00:02, 19 November 2019 (UTC)

Disambiguation link notification for November 19
An automated process has detected that when you recently edited Ellis Island Immigrant Hospital, you added a link pointing to the disambiguation page Fort Wood ([//dispenser.info.tm/~dispenser/cgi-bin/dablinks.py/Ellis_Island_Immigrant_Hospital check to confirm] | [//dispenser.info.tm/~dispenser/cgi-bin/dab_solver.py/Ellis_Island_Immigrant_Hospital?client=notify fix with Dab solver]).

(Opt-out instructions.) --DPL bot (talk) 07:39, 19 November 2019 (UTC)

Nov 20: WikiWednesday Salon NYC
(You can subscribe/unsubscribe from future notifications for NYC-area events by adding or removing your name from this list.)

DYK for 500 Fifth Avenue
Gatoclass (talk) 00:01, 20 November 2019 (UTC)

DYK for Isaac T. Hopper House
 Kees08  (Talk)   00:02, 22 November 2019 (UTC)

Google Code-In 2019 is coming - please mentor some documentation tasks!
Hello,

Google Code-In, Google-organized contest in which the Wikimedia Foundation participates, starts in a few weeks. This contest is about taking high school students into the world of opensource. I'm sending you this message because you recently edited a documentation page at the English Wikipedia.

I would like to ask you to take part in Google Code-In as a mentor. That would mean to prepare at least one task (it can be documentation related, or something else - the other categories are Code, Design, Quality Assurance and Outreach) for the participants, and help the student to complete it. Please sign up at the contest page and send us your Google account address to google-code-in-admins@lists.wikimedia.org, so we can invite you in!

From my own experience, Google Code-In can be fun, you can make several new friends, attract new people to your wiki and make them part of your community.

If you have any questions, please let us know at google-code-in-admins@lists.wikimedia.org.

Thank you!

--User:Martin Urbanec (talk) 21:58, 23 November 2019 (UTC)

Happy First Edit Day!
 Happy First Edit Day! Have a very happy first edit anniversary!

From the Birthday Committee, CAPTAIN RAJU (T) 10:25, 24 November 2019 (UTC)

Disambiguation link notification for November 26
An automated process has detected that when you recently edited Olmsted–Beil House, you added a link pointing to the disambiguation page Dutch ([//dispenser.info.tm/~dispenser/cgi-bin/dablinks.py/Olmsted%E2%80%93Beil_House check to confirm] | [//dispenser.info.tm/~dispenser/cgi-bin/dab_solver.py/Olmsted%E2%80%93Beil_House?client=notify fix with Dab solver]).

(Opt-out instructions.) --DPL bot (talk) 09:18, 26 November 2019 (UTC)

DYK nomination of Concert Grove
Hello! Your submission of Concert Grove at the Did You Know nominations page has been reviewed, and some issues with it may need to be clarified. Please review the comment(s) underneath your nomination's entry and respond there as soon as possible. Thank you for contributing to Did You Know! Yoninah (talk) 21:20, 27 November 2019 (UTC)

Macy's Thanksgiving Day Parade
So I guess that ~ it doesn't matter if it is is set up as an encyclopedic article or not ~ that you are going to take a short cut ~ and make a quick edit ~ and expect everyone to bow to your way that an article should be written ~ instead of making a separate section about the history of how the balloons came to the parade ~ lets just put it in all together and hope that the reader figures it out ~ by the way nice to meet you! ~ ~mitch~ (talk) 23:16, 28 November 2019 (UTC)


 * Your comment that I am trying to expect everyone to bow your way is acknowledged. No need to get too worked up over this, I just reverted your bold edit, per WP:BRD. I don't even understand the rest of your statement, so I'm going to leave my two cents.
 * Anyway. In the revision before your edits, the balloon history was in chronological order, being described in the "Early years" section. But after your edits, the history of the balloons is now somewhere else, after the more recent developments. If you're going to make it into a subsection of "History", at least do it in chronological order. I included a link to the "Balloon introductions" section within the "History" section, so I don't see why you have to hope that the reader figures it out, unless they literally can't see links.
 * But more importantly, this "balloon introduction" section includes subsections about balloon introductions, which don't fit as well in History. The reason being that "History" is about the history of the parade as a whole, and the other sections are about specific elements of the parade, such as performers, telecasts, and parade routes. Like "Performers and acts", these should be in their own top-level section. Anyway, why is this not in Talk:Macy's Thanksgiving Day Parade? I think other users may want to comment on this wholesale layout change. epicgenius (talk) 23:31, 28 November 2019 (UTC)

DYK for Eberhard Faber Pencil Factory
Cas Liber (talk · contribs) 00:01, 29 November 2019 (UTC)

Your GA nomination of Brooklyn Bridge Park
The article Brooklyn Bridge Park you nominated as a good article has been placed on hold. The article is close to meeting the good article criteria, but there are some minor changes or clarifications needing to be addressed. If these are fixed within 7 days, the article will pass; otherwise it may fail. See Talk:Brooklyn Bridge Park for issues which need to be addressed. Message delivered by Legobot, on behalf of Sportsfan77777 -- Sportsfan77777 (talk) 21:00, 29 November 2019 (UTC)

DYK for Eberhard Faber Pencil Factory
Cas Liber (talk · contribs) 00:02, 30 November 2019 (UTC)

Your GA nomination of Brooklyn Bridge Park
The article Brooklyn Bridge Park you nominated as a good article has passed ; see Talk:Brooklyn Bridge Park for comments about the article. Well done! If the article has not already been on the main page as an "In the news" or "Did you know" item, you can nominate it to appear in Did you know. Message delivered by Legobot, on behalf of Sportsfan77777 -- Sportsfan77777 (talk) 01:41, 30 November 2019 (UTC)