In our last issue, part 1 of this story introduced you to the process of a featured article candidate review. This second part of the story gives some of the more important details. Details are important in the featured article candidate process.

Last issue, I gave some thoughts on the general process of a Featured article candidate review. Today I'm going to take a deeper dive into some specific problems which came up at FAC. This won't make a lot of sense if you haven't already read part 1 to get the context.

I'll start with a couple of things that got left out of part 1. One of the unusual bits of FAC culture is that it's totally acceptable to solicit reviews. You could ask on other users' talk pages, or a wikiproject talk page. Another thought is that when you think your article is ready for FA, walk away from it for a few weeks. Once you've read something 100 times, you're burned out and taking a long break will often let you see things you glossed over before.

I also strongly suggest you get your article to WP:GA first; every time you get somebody else to read your stuff and tell you which parts of it suck, the end result is a better article. Also, if you don't bag a GA on the way to FA, you won't be eligible for WP:FOUR.

I was shocked that people objected to my sources. Many of my sources were news reports in The New York Times from the late 1800s. Going into this, I thought that was a good thing. Several reviewers objected to relying too heavily on contemporary news reports. It's not that the Times isn't a reliable source (although there was some pushback that the modern NYT's reputation doesn't necessarily extend back to the 1800s); it's that it was contemporary. People wanted to see what modern writers had written about the topic retrospectively. Unfortunately, for the topic I was writing on, there wasn't much. There were lots of modern mentions of the race track, but most of the coverage was cursory, and many of them were just regurgitating the same stories.

During the review, some reviewers did locate better sources, which I took advantage of to improve the article, but it would have been better if I had found them earlier (see my comments in part 1 about ticking clocks). This is the kind of thing which would have come out at peer review.

Make sure you've satisfied FA criterion 1c: it is a thorough and representative survey of the relevant literature. As great as Google is, it's not enough. Search other databases and aggregators, many of which are available through TWL. Search JSTOR. For historical topics, newspapers.com is always worth checking. TWL federated search (the "Search the library" box at the top of the collections page) performs a search on many of the individual collections in parallel; this turned up things I failed to find through my other efforts. The Library of Congress is always worth trying.

I was totally unprepared for the FA source review. WP:FACR talks about consistently formatted inline citations but that doesn't come close to explaining to what level "consistent" is taken. I think most of it is silly, but it is what it is and if you want to get your FA star, you need to comply. In some places I cited New York Times, in other places, The New York Times. Sometimes I wikilinked the paper name, sometimes not. ISSN, access=subscription, via, publisher, location, ISBN, LCCN, OCLC; all of these were "inconsistent" and had to be fixed. There's not any "right" or "wrong" way to do these things, just pick a way and do it consistently.

This brought up some bitter personal memories. One of my first jobs out of college (in the early 1980s) was working at a scientific research institute doing IT stuff. Unix was the hot new thing back then, and something I knew from school. So, using a cast-off pdp-11, I set up a unix system and started teaching a bunch of microbiologists how to do word processing with troff and ed. That included a bibliographic preprocessor called (what else?) "bib". Every journal had their own reference style and I got sucked into an endless vortex of writing complicated macros to produce the proper format references for each. And debugging each one when some hitherto unexpected situation came up. It was all so pointless. It was also essential, because journals would reject manuscripts if the punctuation wasn't correct. Here we are, 40 years later, and I'm getting dinged because my page numbers have hyphens instead of en-dashes, or some such. Pardon me if I can't get excited about that stuff.

Anyway, install User:Lingzhi2/reviewsourcecheck-sb.js and just keep fixing things until it stops complaining. That should at least get you close. But then you might break Who Wrote That (see T348906).

This was a pain because I had a bunch of public domain (PD) images based on their being published 75 years ago. What I didn't anticipate is that being created 75 years ago isn't enough; it needs to have been published 75 years ago, and you need to be able to demonstrate this. As much of a pain as this is, I get it. Copyright is important and the problem isn't that our rules are twisted; it's that copyright law in general is twisted. If you're depending on PD images, make sure you understand the difference between "created" and "published". Don't trust the license tags from commons; FA is stricter than commons. In your PR request, specifically mention you want somebody to double-check the images you believe are PD. If a reviewer isn't happy with the licensing of one of your images, look around to see if there's another image you could use in its place which comes with a better provenance. Swapping out the image will probably be a straighter line to "looks good to me" (LGTM) than arguing with your reviewer.

I don't know if this is standard FA practice, but it was suggested to me that I make my images larger than normal, using the "upright" parameter, i.e [[File:whatever.jpg|upright=1.4]]and I agree that this produces a nicer display. Don't get too hung up on the exact layout; everybody with different screen sizes, different fonts, different browsers (not to mention mobile vs desktop) is going to see it slightly differently. But if you are going to make the images larger than the default, "upright" is the way to do it (as opposed to specifying width and height in pixels) because that will get you some degree of device independence.

It's not clear if it's an FA requirement to add alt texts to images, but that was also suggested. If it's not strictly a requirement, I think it should be. It provides a descriptive text which screen reader (i.e. text-to-speech) software can use to aid an unsighted person reading your article. Don't just put some minimal "picture of a person" description so you can check off the "images have alt texts" review box. Put some effort into writing a good description which gives the unsighted user as much as possible the same experience a sighted person would have looking at the image. You can download browser plugins which let you preview the alt texts as you view the article.

I should note that there is disagreement about what makes a good alt text. Many people would look at the ones I write, point to various official recommendations, and say that I'm being way too verbose. That's fair, and you can make up your own mind what style makes sense to you, but don't allow "there's no clear consensus on the best way to do it" to become your excuse to not do it at all.

For me, this was the absolute killer, mostly because my sources were a mess. This review is to verify that each referenced statement actually is backed up by what the cited source says. I thought I had been quite careful to only say things that were backed up by a WP:RS. The problem is that as the article developed, statements slowly got disconnected from the sources which backed them up. And once that starts to happen, getting it stitched back together properly is a colossal pain. The fact that the Visual Editor is totally brain-dead when it comes to reference numbering (the numbers change when you open the page for editing, although it appears that this has very recently been fixed) only makes this worse. I ended up having to have three windows open; the review page, the exact revision the reviewer was talking about, and the current revision which I was editing. If the reviewer said "ref n", I'd search in window 2 for "[n]", find some piece of text next to it, and then search in the third window for that piece of text. The user experience was beyond abysmal. At a minimum, if your reviewer is referring to references by number, ask them for a permalink so at least you're sure both of you are looking at the same revision.

The take-home lesson is to stay on top of this while you're editing. Try not to have multiple references in a cluster; that makes it harder to understand which statements are supported by which citations. As you rearrange text during the normal course of editing, be paranoid about making sure you move the associated citations, duplicating or combining them as required. It's a pain, but it's less of a pain to stay on top of it while you edit than to try to dig yourself out of a mess later.

Successive reviewers will give you conflicting feedback to the same issue. Unless it's something that you're really passionate about, don't sweat it. I had one sentence which got rewritten four times; twice to add a particular word, and twice to remove that same word. It's just not worth worrying about. And certainly not worth arguing about.

Somewhat related to this is repeat comments from multiple reviewers. Let's say one reviewer says they don't like X, but you push back on that and convince them it's OK the way it is now. Then another reviewer makes the same comment about X. This is the time to suck it up and deal with the problem.

I started Fleetwood Park Racetrack in December 2021, and submitted it to DYK at that time. In April 2022 I started another editing sprint and got it to GA in May of that year. I did minor tweaks for a while and submitted it to FAC in late August 2023. Keeping up with review comments and rewriting pretty much consumed all my wiki time for the next two months, and it finally passed FA at the end of October. There was one little chore left, nominating it for TFA; that was straight-forward and it ran on January 14th, a couple of days after part 1 of this story. By total coincidence, that turned out to be the same day as Wikipedia Day 2024, so I indulged myself with a 30-second, 2-slide lightning talk.

Was it worth it? Yes. I'll admit, there were times during the process when I would have said, "Hell, no!" At one point, I swore I would stubbornly see this to its conclusion and never do another FAC again, but I've already broken that promise. There's no doubt that my writing is better now than it was six months ago. It's also more FACR-compliant, but I'm not convinced those are the same thing. And while I now have a better handle on when to use a hyphen, en-dash, or em-dash (and when each one should or should not be surrounded by whitespace), I still think worrying about stuff like that is a pretty dumb way for a human to be investing their time.