Wikipedia:Did you know/2017 reform proposals

The DYK process has been slow to adapt to the popularity of the project and as a result is causing problems for editors and readers. This RfC seeks to find consensus for ways to reform DYK.

Previous discussions

• 2011 reform proposals
• RfC on splitting the nomination page

(P1) Keep nominations open until the hook appears on the main page

Currently, once an approved hook is added to a prep queue, the nomination page is closed and removed from the approved page. Those raising issues with a promoted hook do so on WT:DYK rather than reopening and re-transcluding the nomination page. This is not ideal because it fragments discussion of the hook and nomination. The DYK process should be changed so that nominations stay open and on the approved page until they appear on the main page.

Implementation

• Modify {{DYKsubpage}} so that when a hook is promoted, it is not closed
  • Have prep builders use {{DYK moved}} to indicate which hook was promoted/pulled and where to and from
• Have a bot close and remove a nomination once it has appeared on the main page
• Encourage editors to raise problems with a hook on its nomination page rather than WT:DYK

(P1) Discussion

Proposals are still being drafted, to discuss a particular proposal, please use the talk page

While this is certainly doable I'm not sure that anyone would actually comment on the approved hooks. Considering that we have hooks that sit as unapproved without even an initial review for weeks and sometimes months having a promoted hook stay on the approved page likely wouldn't garner that much more attention. In my experience once a hook makes a prep or queue then people start looking at in detail and bring any big issues to WT:DYK which while not always the best place makes sense as it is a central point of discussion people actually check. Mifter (talk) 04:17, 18 February 2017 (UTC)

This is a terrible idea. It is the only way a prep area builder knows a hook has been promoted. We will wind up with a host of hooks being moved twice. Hawkeye7 (talk) 05:52, 18 February 2017 (UTC)

Oppose': Per Hawkeye, how would we know if something has been promoted or not otherwise? The C of E God Save the Queen! (talk) 08:25, 18 February 2017 (UTC)

• I wonder if a modification of this idea would work:

1. When a hook is approved, bot moves it from t:tdyk to the new page, left open
2. When a hook is promoted, the nomination is left open but collapsed with a note saying it has been promoted
3. If it appears on the main page, bot closes the discussion and removes it when the hook is removed from the main page with the new set
4. If the hook is pulled from the queues or prep, prior nomination remains in a box but uncollapsed with the "promoted" note changed to a "removed from prep" / "removed from queue". The discussion continues below the box of the nomination up to its promotion. It can then be re-promoted when necessary.
5. If the hook is pulled from the main page, a similar procedure occurs but with a "removed from main page" notice. Bot can then make an entry in the sometimes-used list of pulled hooks. Any following discussion which is needed can be held, including (could be others):

   • returning to the main page because pull was not justified / minor problem addressed, etc – like the recent Presidential M&Ms
   • discussion of what went wrong to allow the project to address issues (likely such a discussion could be moved to WT:DYK)
   • closing the nomination as "pulled from main page and not returned / failed" as appropriate, for bot to remove

   Bot will not act on these until an action from an editor

6. Bot would also close and remove failed / withdrawn nominations from t:tdyk

In this way, editors can easily see where a nomination is up to (and the backgrounds could be colour-coded to help if needed).

On the t:tdyk page: waiting for review / new review needed, review in progress but unresolved (could be different colour background or with different coloured text (bold to emphasise black for waiting for review / new review needed) changed by the bot based on latest symbol and added parameters when promoting, etc), withdrawn / failed (perhaps allow 24 h for action before archiving?), or passed / ticked.

On the new page: passed / ticked (uncollopased and open), promoted (collapsed), returned from prep / queue (prior uncollapsed but closed, further discussion below), which could go to failed and awaiting archive, pulled from main page (prior uncollapsed but closed, further discussion below – hopefully rare) which becomes pulled from main page and not returned / failed / waiting for bot archive or returned to main page (like promoted, will be closed and archived by bot when set rotates off main page.

This would also remove the current problem of pulled hooks requiring a manual re-adding of the nomination, and get consistency on where such nominations are located, while also taking pressure off WT:DYK. Also, the bot could remain a list for us (in a collapsed box, if needed) on WT:DYK of nominations that have been pulled and inviting attention to them. I am not a bot programmer, so I am open to all comments on what is or is not practicable, and also (of course) on how to refine this idea, or to put forward better ideas, etc. Thanks. EdChem (talk) 10:56, 18 February 2017 (UTC)

• All the hooks on the approved page are eligible to be added to the next available prep area. When the hooks are in the prep areas, the discussions are no longer visible unless you actually select them. So any discussion there will be ignored. The current procedure is better. Hawkeye7 (talk) 12:10, 18 February 2017 (UTC)

• @Hawkeye7: I'm a little unclear, do you think the current procedure--closed nominations being removed from the nomination and approved pages--is better or the current procedure--closing nominations once a hook is promoted--is better? Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 18:20, 18 February 2017 (UTC)

I'm unclear about your question. What are the alternatives? Hawkeye7 (talk) 21:43, 18 February 2017 (UTC)

Since there's been some talk about how prep builders would know which hooks have been promoted, a month or so ago I wrote a template {{DYK moved}} as part of this idea. I've added it to the implementation section.

{{subst:DYK moved|alt=1|toPrep=3}} produces
ALT1 promoted to prep 3 – Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 18:37, 18 February 2017 (UTC)
{{subst:DYK moved|fromPrep=3}} produces
the nomination was pulled from prep 3 – Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 18:37, 18 February 2017 (UTC)
It has pretty intuitive syntax which I think means prep builders will remember to use it, and it could be modified to collapse or hide discussion once something's promoted so that the nomination isn't formally "closed" but still doesn't clutter the page with text. Thoughts? Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 18:37, 18 February 2017 (UTC)

(P2) Move project out of obscure template space

The project is inherently overly complex as it requires knowledge of templates, template transclusion and often loses nominators as nominations are moved from A to B to C. This reduces visibility of hooks as they progress to the main page, and reduces the likelihood of nominators being able to deal with late issues, or being able to track nominations to their conclusion.

Implementation

• It's a big change, it needs something like all other main page nomination-based areas to function, e.g. WP:ITNC, WP:TFL, WP:TFA etc, which are all very simple indeed. The Rambling Man (talk) 21:45, 17 February 2017 (UTC)
• I agree with TRM that DYK needs some form of nomination and holding area which by definition makes everything more complex (having template pages is at least better than how we used to do it with everything just manually stored on T:TDYK.) However, have we considered asking for a user script to be created to automate some of the transclusion? I know MusikAnimal and his User:MusikAnimal/Scripts have made my life at AIV and RFPP easier and looking at his script for WP:PERM (userRightsManager) which automates the approval, notification, and modification of userrights it wouldn't seem like too much of a stretch to have something make for DYK. AfD is complex if done manually too but their solution is to have pretty much everyone use Twinkle or some other script to do it. Mifter (talk) 04:24, 18 February 2017 (UTC)

(P2) Discussion

Proposals are still being drafted, to discuss a particular proposal, please use the talk page

(P3) Reduce the complexity and creepiness of the DYK instruction tome

This is obvious, already there are dozens and dozens of rules to DYK. Look at other main page contribution areas and you see no such thing. The one thing Trump seems to have right is that if you create one new piece of legislation, you remove two existing ones. This is a good example of how streamlining the project should work. Supplementary rules such as "the image should be relevant to the hook" really need to be struck off and salted. Main rules such as "The hook should be neutral." are routinely violated. There are many such examples. And when in doubt, just refer back to Wikipedia policies and guidelines.

Implementation

• Go through all the rules, one at a time, and determine its relevance, its veracity, its obsolescence. The Rambling Man (talk) 21:49, 17 February 2017 (UTC)
• The rules page should be protected so that changes can only be made with explicit consensus to prevent rule creep. Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 18:10, 18 February 2017 (UTC)

(P3) Discussion

Proposals are still being drafted, to discuss a particular proposal, please use the talk page

Usually rules come into being because something that had been understood initially by the participants is not known by newcomers. For example, you'd think that the image being relevant to the hook would be a no brainer, but I've seen some images lately that aren't relevant at all, or are a stretch. Who gets to decide what stays and what goes? Are we going to have an RfC for every item on the main and supplementary pages? BlueMoonset (talk) 04:55, 18 February 2017 (UTC)

Why not? The project is hamstrung in arcane rules and completely off-putting to one of its target audience, new editors. The Rambling Man (talk) 09:18, 18 February 2017 (UTC)

One of the problems here is that the meaning of the rules is unclear. Does "policy compliant" mean checking every image for licensing and its sourcing in a newly-promoted GA? Does it mean ensuring every fact in a BLP has an inline citation? What level of language and grammar is required to be passable for DYK? I'm sure we could all list areas where reviewing against the rules can be interpreted as permitting the passing of something embarrassing to WP, or become a mini-GA to mini-FA review. Clarifying into brief and simple rules leaves open space for endless debate. Take BlueMoonset's point about relevance of images to the hook... does the image have to relate to the fact in the hook, or is illustrating the bolded term sufficient? Suppose you were reviewing the hook "... that Person X fell 100 m from the Sydney Harbour Bridge during construction, and survived?"... what would be a relevant image? The bridge as it is today? The bridge during construction? Would a construction image need to be at around the stage when Person X fell? Would a picture of Person X be acceptable if the bolded article was "Construction of the Sydney Harbour Bridge" (say)? TRM, you are correct that the complexity, especially as it sprawls over multiple pages, is an issue... but equally, slash-and-burn "simplifying" can have lots of unintended consequences. After all, WP has a 12-word policy the application of which easily produces pages and pages of debate at times. EdChem (talk) 12:11, 18 February 2017 (UTC)

No-one mentioned slash and burn, or arbitrary removal. The rules need to be examined, if necessary one at a time; often as not the Wikipedia site policies and guidelines will already have them covered so they can be removed. If not, they can possibly stay, and even be simplified. The Rambling Man (talk) 12:35, 18 February 2017 (UTC)

TRM, many things are already covered in WP's arcane and hyper-complex web of rules, policies, guidelines, essays, opinions, and obscure hidey-holes. Removing material from the bloated but much more contained DYK rule set to rely on the ridiculously bloated network of WP pages is not necessarily a desirable change. It is true that you did not invoke arbitrary action or slash-and-burn, but the framing comment on Donald Trump's approach will, for many (including me), bring both those attributes to mind. EdChem (talk) 13:00, 18 February 2017 (UTC)

Regardless of the number we could remove/update, the exercise would be to determine whether each rule is needed, and if so, is it suitably (i.e. effectively and efficiently) worded. That's all there is to it. No-one talked of slash-and-burn (in fact, I just said if you created one new piece of legislation, two old one should go, that's hardly "slash and burn", it's good sense to a point). The Rambling Man (talk) 13:33, 18 February 2017 (UTC)

I am inclined to agree with a rules review. Inertia and other effects tend to cause rules creep which needs to be curtailed from time to time with a general review. Jo-Jo Eumerus (talk, contributions) 12:38, 18 February 2017 (UTC)

A review is appropriate, sure, and I am not going to argue that the present situation is ideal. Redundancy and inefficiency can be side effects of an evolutionary development of rules, and some planned and designed rationalisation can certainly lead to significant improvements. However, because something is shorter does not mean it is better. EdChem (talk) 13:00, 18 February 2017 (UTC)

• When all is sorted out and decided on, protect the rules as a template would be protected. As is WP:DYKR, WP:DYK and to a lesser degree WP:DYKSG have been rewritten at will, with or without consensus, with or without ever having discussed the rewording on the project talk page. There has been no control whatsoever. In one edit not noticed until last month, a mandatory rule was added in 2013 as a drive-by edit, that required every linked article in the hook to confirm to DYK criteria. Maybe we could streamline the rules onto one page, and semi-protect the page. We have enough admins who could respond to consensus changes to the rules page. — Maile (talk) 15:35, 18 February 2017 (UTC)

I've added protecting the page as a point of implementation. I didn't put a particular level though because I think that might be a useful discussion for the community. Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 18:10, 18 February 2017 (UTC)

OK. Thanks. — Maile (talk) 18:18, 18 February 2017 (UTC)

I don't agree that the rules are too complex - most of them have been added for very good reason, and in the vast majority of cases, users do not have to refer to anything but the basic ruleset in any case. I do agree that the presentation of the rules is chaotic and that some of the content is old and redundant, but that's not the same thing as saying the rules themselves need to be trimmed. I have been planning to do a rewrite of the rules for some time now, but just haven't gotten around to it yet for a variety of reasons.

With regard to the proposal to protect the rules pages, I'd have to see evidence that random changes by uninformed users is a problem and I can't say that I personnally have noticed any such problem. Gatoclass (talk) 10:22, 21 February 2017 (UTC)

(P4) Make prep-builders roles crystal clear

We have but one or two dedicated prep builders. They seem to spend a long time (e.g. around an hour) preparing a set, yet clear and obvious errors in each set means that perhaps the effort is misdirected.

Implementation

• Create a real checklist for prep-builders that actually takes into account the frequently reported errors (e.g. unsourced claims, orphaned articles, woeful English, linkrot, image abuse/misuse, inadequate leads, etc etc). We allegedly held the "Removed" page open so people could "learn" from it, but nothing happened, and it's now obsolete. The Rambling Man (talk) 21:52, 17 February 2017 (UTC)
• I agree with a checklist, that being said looking at your concern under P3 we need to make sure it isn't redundant or too long otherwise it'll become just like the main ruleset and be ignored or only cited on occasion. Mifter (talk) 04:28, 18 February 2017 (UTC)

(P4) Discussion

Proposals are still being drafted, to discuss a particular proposal, please use the talk page

• We want to minimise the work of the prep area builders. Make it clear that they are responsible only for assembling a prep area and are not to carry out checks on the articles, just the construction of the prep area itself. Hawkeye7 (talk) 05:56, 18 February 2017 (UTC)

  Then you need to add such basic and fundamental checks to the reviewer's job. The Rambling Man (talk) 09:19, 18 February 2017 (UTC)

  The problem here, in my view, starts from too many inadequate / incomplete reviews (which I have raised at P5, below). I also wonder if promoters, when seeing reviews that have issues, are not contradicting the tick with a new icon and quick note as to the problem, and then another promoter may promote without realising the issue? When we as a project are promoting errors, we need to be stopping a nomination's progress more readily when issues are noted. I believe we need to improve at catching and addressing issues before promotion, and also discouraging the mindset that those who monitor the preps / queues will catch errors. The review stage should be catching most problems and other stages are cross-checks, etc. When I review, I aim to pull up everything I see and won't give the tick until I am confident that it is ready for the main page, though I am glad that others do checks and will catch things I miss from time to time or make changes that are improvements; however, if something serious is caught that I missed, I will be re-evaluating whatever mistake I made. I have the impression that some other reviewers take an approach much closer to ticking the boxes for a minimal compliance for the QPQ credit expecting that others will find problems that exist so it doesn't matter if they don't. A system with multiple checks doesn't work well when the first check is a filter through which a small whale could swim, and it is unfair on the later checks. Promoters need to check that the hook is cited in the article to a reliable source, is neutral, is accurate, is well-crafted, and (if accompanied by an image) has a properly-licensed image. It is unreasonable to expect the promoter to re-do a complete review as that is far too time consuming. Equally, if the necessary checks from the promoter show that the article has serious issues, this should be noted and the hook sent back for further work / review. EdChem (talk) 11:49, 18 February 2017 (UTC)

• I've wondered if having some kind of script that can be used by preppers to move suitable hooks into the prep area and unsuitable ones into a "not prepped" list. And the script should display a list of problems that the prep builder should be checked for, such as TRM's list. Jo-Jo Eumerus (talk, contributions) 12:40, 18 February 2017 (UTC)

This proposal directly contradicts the previous one which advocated trimming the rules and relying on existing "Wikipedia policies and guidelines" for the rest. I haven't seen any consensus that "inadequate leads", "orphaned articles" etc. should be added to the DYK rules, but if there is such a consensus, I think it would make more sense to make these reviewer rather than prep assembler requirements as prep assemblers have more than enough to worry about already. Gatoclass (talk) 10:29, 21 February 2017 (UTC)

Not at all. The audiences are very different. I'd try to explain further, but I don't think it's worth it. The Rambling Man (talk) 11:01, 21 February 2017 (UTC)

What audiences? I thought we only had one audience - main page readers. Gatoclass (talk) 11:29, 21 February 2017 (UTC)

Perhaps you're confused. The audience for the ruleset is those creating DYK nominations. The audience for the prep-builder list would be .... prep builder. The audience for the promoted sets would be .... the readers. Better? The Rambling Man (talk) 11:35, 21 February 2017 (UTC)

Thanks for the clarification. As I've already said, I don't think we should be adding yet more requirements to the prep builders' list, they have enough to worry about already. That means these additional requirements would fall on the shoulders of either the nominators or reviewers, which are presumably the groups for whom you would like to see the rules simplified. Gatoclass (talk) 11:46, 21 February 2017 (UTC)

Rules for nominators should be simple. Those who wish to review/promote articles should be competent enough to cope with rules surrounding article quality. It's still not working well enough. The Rambling Man (talk) 11:50, 21 February 2017 (UTC)

Nominators and reviewers are essentially the same group, you can't simplify the rules for one group and make them more complicated for the other. And you can't expect promoters to be enforcing rules that do not pertain to nominators - in short, the rules have to be consistent across all groups. So I maintain that you cannot on the one hand argue that rules should be simplified and on the other want to add a bunch of new requirements. Gatoclass (talk) 12:03, 21 February 2017 (UTC)

Maintain to your heart's content. Nominators are not the same are reviewers, they have their five free credits in this absurd QPQ system to learn the ropes. The plethora of pointless rules actively dissuades genuinely new editors to the project. That's evident by the average edit count of the contributors to the game, many in the high 10s of 1000s. Plus set-builders/promoters need to be even more competent, looking out for all the obvious issues that the reviewers have missed. If they can't, or don't feel able to spend the time doing it, they shouldn't be promoters. It should not be left until hooks get to the queues (or worse, the main page) to spot issues that are overlooked because people aren't doing the job properly. The Rambling Man (talk) 12:23, 21 February 2017 (UTC)

(P5) QPQ credits disallowable

The point of QPQ reviewing was to force nominators to review other hooks to ensure sufficient reviewers. In theory, reviewers become more skilled with practice, and new nominators learn from the reviews of their articles. In practice, the quality of reviews for QPQ credits vary from excellent to inadequate and on to appalling. Reviews which do not address all the necessary criteria can be addressed by a diligent reviewer when the QPQ credit is used, but sometimes the other article has been promoted (and maybe then pulled). Sometimes reviewers miss things so obvious that they cannot have done a proper thorough review, at times this is caught in the preps, at times not until the article is on the main page. There has to be the possibility of QPQ credits being removed when reviews are just fundamentally flawed. Now, I would not want this automatic because a review can be thorough and miss something significant but subtle. I have criticised the adequacy of a QPQ credit during my review when it is used. I have seen an editor do an additional QPQ review without being asked, recognising that my criticism was warranted. I have pointed out that no copyvio check was done, done it myself and found no issue, and reported this and asked that they be more careful, to be met with the attitude that it showed no issue, so what does it matter. I have pointed out double-claiming of QPQ credits to be told that the editor has done many reviews, so I should just pick another review they've done to use. I have seen one-line reviews claimed even after another editor has raised a series of issues that were missed. The DYK project collectively has a problem here that we need to find a way to address. QPQ reviews are not a you-pass-my-inadequate-nomination-and-I'll-pass yours (which is why I hate the name, can we change it?), they are a reviewing requirement on the nominator as an integral part of making a nomination, and they need to be high quality. EdChem (talk) 11:30, 18 February 2017 (UTC)

Implementation

• I am not suggesting an implementation approach because I think that depends on (a) whether the general principle is agreed, and (b) who has the ability to disallow a QPQ credit. Can it be a unilateral decision of the reviewer(s) of the nomination in which it is used? Does it need a WT:DYK discussion / consensus? Do we create a section for dealing with this requiring (say) net 4 support to disallow? On what bases can a credit be disallowed? What do we do if a QPQ credit has been used for a hook which has been on the main page before its inadequacy is discovered? I think we need a broad discussion in search of consensus on what is reasonable before figuring out how to implement it.
• Please Please PLEASE can we keep this discussion about the general issue (with examples, if necessary) and not about individuals and personalities? In my experience, when a discussion on poor reviews goes into a particular editor's work, it deteriorates into blame, accusation, defense, and the broader issue gets lost. I don't want to discuss individuals, I want to discuss the systemic issue which we have that starts with inadequate / inaccurate reviews.

(P5) Discussion

Proposals are still being drafted, to discuss a particular proposal, please use the talk page

• Agree completely with this, but let's not leave it open to the requirement of a consensus each time. A consensus can be reached based on personalities, losing the intent of the process. Make this criteria simple, specific, and easy to understand at a quick glance. Put the criteria in a highly visible place, such as the DYK toolbox - don't leave it to chance that any reviewer has seen the criteria. We need to make this fair to participants whose first language is not English. Perhaps a small list of review checkpoints that have to be used to claim a QPQ. If the reviewer missed anything, and the nomination is still unpromoted, give them a reminder on the nomination template to add what is needed. Also, if a hook gets pulled for something not specifically mentioned in the at-a-glance criteria, the reviewer gets to keep the QPQ. If a hook gets pulled for bypassing something obvious, such as a check for copyvio, the QPQ is denied. One thing that should not be in that criteria is whether or not the hook is interesting, because "interesting" is really a POV and highly subjective. — Maile (talk) 13:14, 18 February 2017 (UTC)

• The basic criteria are right there above the edit box any time someone is editing a nomination, like a reviewer. If someone continues to miss checking for certain criteria, we disallow the review. If they don't link to a specific QPQ on the nomination page, don't pass the nomination. It's not much work for them to enter it—and no reason why we should go looking for it—so they should do it. Period. BlueMoonset (talk) 17:44, 18 February 2017 (UTC)
• As a moderately new reviewer, I have found it hard to not miss things. There are all these tools, some of which I found counterintuitive (like the QPQ check, which does not tell you if the person typed in has QPQ credits, just whether they have given them to others, gross, not net). The DYK checklist template, which I have just discovered, helps, but I had to experiment to find out what some of the fields did (I should have looked up the template documentation, but didn't). If a checklist could be added by default, it might reduce the number of unchecked things. Since so many of these tasks are semi-automated, it would be nice to have the automation interfaces better-integrated with the checklist, too, avoiding some "Did I do that yet?". While there are a lot of value judgments in a review, preventing complete automation, the faster a totally inexperienced editor can breeze through the process without looking anything up elsewhere or making mistakes, the better.

• Some explicit criteria built into the interface, with clear error/reminder messages, as described by Maile, would be welcome. I'm still not quite sure how I'm supposed to tell that someone, even myself, has already used their QPQ credit once. If there are clear criterea for allowing credit, with manual revocation except in cases where something fails for subtle reasons, as EdChem said, it would be nice to automate QPQ-citing. We could even give scores, +3 reviews, -1 reviews, and so on. HLHJ (talk) 02:48, 3 April 2018 (UTC)

(P6) DYK nominations can and should often be failed

Don't keep hammering away at DYK nominations ad infinitum. Many articles simply are not interesting to a broad audience. They cannot produce hooky hooks and so when attempts are made to do so, they should be politely declined.

Implementation

• Reviewer determines a hook is not good enough for main page inclusion using common sense and fails the nomination. The Rambling Man (talk) 13:35, 18 February 2017 (UTC)

(P6) Discussion

Proposals are still being drafted, to discuss a particular proposal, please use the talk page

(P7) Limit exposure of same old same old hooks

Frequently we have one hook per set of the same kind of obscure thing, e.g. Hawaiian or 1960s Indian politicians, common birds, dinosaur fossil eggs, etc, for many sets running. This is not interesting to our readers, as exemplified by the pageviews (some DYKs get fewer than 1000 hits....)

Implementation

• Keep a ready reckoner of "types of hook" (much like they've done informally at FAC) to ensure one type of hook isn't given too much exposure. The Rambling Man (talk) 13:39, 18 February 2017 (UTC)

(P7) Discussion

Proposals are still being drafted, to discuss a particular proposal, please use the talk page

• disagree, There is NO point to trying to say only x number of Y articles can be run in Z space of time. The amount of hits the main page gets each day means that outside of regular editors, very few people see articles on similar subjects repeatedly.--Kevmin § 15:57, 18 February 2017 (UTC)

  You'd rather we run one 1960s Indian politician every twelve hours? Or some obscure insects which get 700 hits? If there's "NO point" (sic) in it, why do FAC do it? The Rambling Man (talk) 17:29, 18 February 2017 (UTC)

  Like the TFA coordinators, the prep area builders deliberately vary the hooks so that there are not too many bios, not too many US hooks. The images are selected so we don't have two mushrooms in a row. Many editors use a model of article writing in which they write a series of articles on a topic one after another. Some do this exclusively. It's a very efficient mode of writing because you can reuse the same references. The effect is that we see many articles, but the readers do not. Hawkeye7 (talk) 22:58, 18 February 2017 (UTC)

  That's simply factually incorrect. We have runs of fossil eggs, runs of Indian politicians, we go barely one set without a minor irrelevant bird/insect. The Rambling Man (talk) 23:04, 18 February 2017 (UTC)

I think part of that is simply due to the fact that the English Wikipedia already has coverage on most things people would seek out and we are filling in more and more obscure facts. That being said I see no reason why we couldn't balance out some of the "duller" or more specialized hooks so we aren't always running some obscure politician or animal species for example (we are however limited by what new articles are actually being written and submitted.) If a type of hook is being run often enough to become a joke for being dull then it is clear we need to spread hooks of that type out more. Mifter (talk) 23:59, 18 February 2017 (UTC)

The thing is, its only considered a problem by a very small segment of regular editors that focus on main page work, no one else seems to have any problem with the subjects. Only one editor considers it a "joke".--Kevmin § 02:10, 19 February 2017 (UTC)

Who said "joke"? The "problem with the subjects" is adequately exemplified by the sheer disinterest of readers, i.e. pageviews are an adequate gauge. Obscure insects, minor birds, fossil eggs.... no-one really cares besides the editors pushing the pages to the main page and a handful of their colleagues. For the main page to get in excess of 20 million hits per day and yet fewer than 1,000 (0.05%) actually visit some of these "hooks". There's really not enough focus on interesting hooks and too much on obeying the Book of DYK Rules. The Rambling Man (talk) 20:58, 19 February 2017 (UTC)

WP is not censored and neither is the main page. ANY article may be presented on the main page if it meets the criteria of one of the projects that has main page space. There is no reason to institute censure on this project simply due to the nature of the articles nominated.--Kevmin § 21:07, 19 February 2017 (UTC)

That sounds a little Trumpist. This is nothing to do with "censorship" or "censuring". It has to do with "balance". If you can't see that, then we're talking at cross-purposes and there's little point in you and I continuing any form of "discussion". I'm not censuring any project, I'm making a proposal, that's the purpose of this page, right? For time immemorial with had to withstand endless dull hooks about creeks in Pennsylvania, or utterly disinteresting and extinct insects or incredibly common birds somewhere obscure. Page views tell the tale. Stop focusing on the Book of DYK Rules and think of our readers for a change. The Rambling Man (talk) 21:28, 19 February 2017 (UTC)

no Trumpist, just annoyed. the proposal does not seem to give balance though, from the point of view of the general public. It is trying to address that is only perceived by the small segment of people that look at the main page every day. This purpose is trying to correct a non-problem. "think of the children" is not an argument.--Kevmin § 04:06, 20 February 2017 (UTC)

Please keep the annoyance out of the discussion. The general public vote with their clicks, the sub-1000 club is ever-growing and a shambolic testimony to the repetitive and dull nature of many of the hooks promoted by the DYK project. This is a real problem, and no-one but you mentioned thinking about children. What a bizarre non sequitur. The Rambling Man (talk) 05:49, 20 February 2017 (UTC)

• Oppose, for basically the same reason as Kevmin. Wikipedia does not say, "Anybody can edit ... but only on this week's list of approved topics." We've been through this for years. At one point, it was a glut of horse articles. Were there too many articles about United States elections in the last year? Are there too many articles about food? (well...maybe...those food articles always make me want to eat too much) It could be any subject. But once we insert a license into the rules that say we can discard nominations based on subject matter, it's an open door to "Sorry...too many women's articles...too many articles about slavery...too many Jewish names in hooks...sorry, but too many soccer articles...too many athletic competitions...too many Christian (Muslim, Hindu, Buddhist) articles..." Once we allow this as a rule, it is an invitation to discrimination by subject matter, regardless of what the subject is. — Maile (talk) 14:56, 20 February 2017 (UTC)

  There's no "list of approved topics". Where did you see that? FAC do a great job of listing articles proportional to the content of the encyclopedia. I think you miss the point entirely that our audience doesn't actually give two hoots about obscure insect after obscure insect after obscure insect. Page views should tell you that. It's no "license to discard nominations" (who ever said that?!), it's just to limit the runs of dull hooks that no-one is reading. It's nothing to do with discrimination, it's to do with variety and interesting our readers. Of course, if you'd rather we just limit this to satisfying editors who nominate dozens of low-to-no interest hooks, that's a different matter. Is that what you mean? The Rambling Man (talk) 18:28, 20 February 2017 (UTC)

• Oppose Wikipedia is a broad church and DYK is a small part of it. There may be a very small number of regular contributors who focus on one area but it does seem fair to all those not involved in DYK to have a wide variety of subjects covered. For example, I normally focus on football, rugby and Christianity but I have also covered "niche" topics on DYK like a computer software programme and a tax avoidance scheme. The C of E God Save the Queen! (talk) 08:55, 23 February 2017 (UTC)

(P8) Simplify the DYK symbols

The current system of checks, question marks, slashes, and x's are confusing and not well documented as to what they mean (what's the practical difference between "DYK eligibility requires that an issue be addressed" and "DYK eligibility requires additional work"?). This leads to confusion for new reviewers as there are so many and they may fear getting in trouble for using the wrong one by accident. It makes life more difficult for nominators as it is unclear what anything other than a tick means.

Implementation

• The number of symbols used is reduced to five:
• The meaning/usage criteria for each is updated in {{DYKSymbols2}} as follows

Symbol	Code	DYK Ready?	Description
	{{subst:DYKtick}}	Yes	Satisfies the DYK criteria; ready for the main page
	{{subst:DYKtickAGF}}	Yes	Satisfies the DYK criteria with a foreign-language, offline hook reference, or reference behind a paywall accepted in good faith; ready for the main page
	{{subst:DYK?}}	Query	DYK eligibility requires that issues be addressed. Notify nominator with {{subst:DYKproblem|Article|header=yes|sig=yes}}
	{{subst:DYKno}}	No	Article is either completely ineligible, or issues would require an unreasonable amount of time to address before the article is fit for the main page. Notify nominator with {{subst:DYKproblem|Article|header=yes|sig=yes}}
	{{subst:DYK?again}}	New review	A new review is needed.

(P8) Discussion

Proposals are still being drafted

There may also be room to include the AGF tick or remove the new review tick. I can't come up with good reasons for either, but if anyone feels strongly, I'd like to hear your thoughts. Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 18:58, 18 February 2017 (UTC)

I agree with leaving the AGF tick. Its simple to explain (is the ref offline? behind a paywall? or not in a language you understand? then use the AGF approve tick) and while more and more things are online/verifable having a way to distinguish between fully verified and vetted hooks and those where a reviewer is making an AGF assumption is useful IMO especially if we want to cut down on the number of errors making it through. I agree with merging the ? and the / symbol as they are already used interchangeably. Mifter (talk) 23:47, 18 February 2017 (UTC)

I agree with Mifter, the AGF check is very important, and I for one do not use the two checks interchangeably.--Kevmin § 02:12, 19 February 2017 (UTC)

I, too, agree with Mifter, et al; I try to be selective when I use the Standard check and the AGF check. DarjeelingTea (talk) 20:00, 19 February 2017 (UTC)

Let's keep the "new review" icon as part of the set, as it has proven useful on a number of fronts. (It's the newest of the icons.) The AGF check is also useful, and is used by many reviewers, just not all who should. BlueMoonset (talk) 04:22, 20 February 2017 (UTC)

I also think that the proposed descriptions need work. The ? should not merely be an issue, but one or more issues, even a significant number, and the X should not merely be "considerable work", but an amount that makes it unlikely that it can be addressed with a week or two's work. BlueMoonset (talk) 04:28, 20 February 2017 (UTC)

I added the AGF symbol per the discussion. I've updated the descriptions, but they're still up for discussion and improvement. Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 07:20, 20 February 2017 (UTC)

• I have thought for a long time that either the DYK? or DYK?no icons are redundant, so have no objection to one or the other being removed. I think the others are needed. I think BlueMoonset has a point in saying the existing descriptions for the icons could use more clarification. Gatoclass (talk) 10:38, 21 February 2017 (UTC)
• The symbols themselves may be unclear and sometimes difficult to distinguish for some editors, as was discussed before as an WP:ACCESSIBILITY issue. Could we please have accompanying text? Something like:  Ready,  ReadyAGF,  Query,  Denied, and  Request new review or  Request new review. I tweaked some of the colours, but the text is more of an issue for me. Many other symbols can be found at Template:Done#See also and Wikipedia:List of discussion templates. – Reidgreg (talk) 12:37, 30 June 2018 (UTC)

(P9) Reject unapproved nominations after a period of time

A number of nominations are left open for months at a time after multiple problems are found. As the discussions lengthen, the number of reviewers willing to take on the wall of text diminishes and the nomination stagnates without a consensus for promotion. A time limit for nominations should be imposed (subject to WP:COMMONSENSE and WP:IAR) and those that are not approved within it be closed as unsuccessful.

Implementation

• Nominations unapproved after ___ (days/weeks/months/years) will be closed as unsuccessful
• Nominations without a QPQ review after 7 days will be closed as inactive
  • Nominators should be given a chance to respond prior to closure for inactivity (perhaps by bot?)

(P9) Discussion

Proposals are still being drafted

Fill in the gap! As a starting point I'd like to suggest 3 months? I think it will get the really old, unlikely to be successful ones without catching the nominations that are slow to get reviewed or have minor issues. Also, to head off some anticipated criticism, I think this will be good because it removes the subjectivity of failing a nomination, it's not me saying "I don't think this will ever pass, so I'm unilaterally closing it" but rather "this has been open too long and consensus says we should close it because it's taking up space and time". I think part of the reason we're loathe to reject noms is because we don't like being that person, so we just let the nominations languish. I think a time limit would be good for the project and everyone's egos (my on included). Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 19:14, 18 February 2017 (UTC)

Wugapodes Needs clarification. "the wall of text" indicates you might be referring to an ongoing review that never results in an approval. Because there are nominations that don't get looked at for long periods, for any variety of reasons, perhaps new nominators more than others. I'm going to stay neutral on the old "wall of text" types. But I would be opposed to penalizing an uncommented upon nomination. — Maile (talk) 21:12, 18 February 2017 (UTC)

It's odd. Most, if not all other parts of the main page decision-making processes accept that some nominations are just not going to make it. DYK seems to make a rod for its own back by insisting that pretty much every single nomination is passed, even if that takes months. The Rambling Man (talk) 21:24, 18 February 2017 (UTC)

The target is those with many comments that don't result in an approval. I do also think that it should apply to all nominations, even those not commented on. If after three months on the nomination page, with QPQ eyes and regulars crawling around for a nomination to review, it didn't get picked up then it's either because it's incredibly uninteresting (itself a reason to reject) or the article has so many problems no one wanted to take it on. The oldest nomination with no comment currently is from January 24, not even a month ago, so I doubt anything would make it to 3 months that's really truly worth saving, and, on the off chance one is, IAR. In fact, The oldest nomination on the page, which took 2 months to get reviewed, isn't covered by this rule. I think it may actually be worth considering a more stringent time period. Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 22:05, 18 February 2017 (UTC)

Looking at the current noms, only one would be eligible to be failed under this criterion. I am at a loss to explain why an article nominated in November didn't get reviewed until February. I suspect it got sandwiched between a couple of interminable reviews and was overlooked. The second has a merge tag on it, but unlike an AfD, that doesn't make it ineligible. It currently has no usable hook. The third, though, is of the type that we all loath. Endless discussion over several screens worth and no sign of a usable hook. The third is, on the fact of it, eligible to be moved to the approved area, but it has a query on it, and I cannot fathom why. Hawkeye7 (talk) 22:32, 18 February 2017 (UTC)

Three weeks would be more appropriate, that's the kind of timeframe after which all other main page (and GAN) nominations are simply axed. If there's not enough interest, things aren't going right, either from an article perspective or because reviewers are put off for one reason or another. Right now the infinite timeframe over which this process is "handled" allows all the shortcomings to be ignored. The Rambling Man (talk) 22:36, 18 February 2017 (UTC)

Three weeks may be too short for a blanket rejection. Unlike GAN and most other main page work we are specifically working with new articles. By definition that means more issues to resolve. While I don't advocate for "beating a dead horse" to get a hook I also don't believe that hooks should be summarily discarded due to age unless they have identified issues that the author/nom/anyone have not and are not addressing (e.g. a poorly written article's review is tagged as such and sits for weeks with zero progress). If people are working towards handling the issues then I see no reason to adopt a hard and fast timeline for them to handle the issues (subject to reason of course). Mifter (talk) 23:53, 18 February 2017 (UTC)

No, if these people are genuinely the audience the project is aiming to interest, three weeks should be ample time to get a single sentence and a barely-above-stub article up to scratch. We're rarely talking about more than an hour's work in total. Adopting a hard and fast timeline will focus the minds and stop the general malaise which is petrifying the place right now. The WE MUST PASS HOOK mantra. It doesn't happen anywhere else on Wikipedia, so why does it happen at DYK? Now, if DYK nominators had an average of 500 edits then I'd give it some credence, but each set averages well in excess of 10,000 edits, so all nominators know (a) exactly what they're doing (b) exactly what to expect so if they (c) can't be bothered to fix up issues quickly, (d) fail. The Rambling Man (talk) 21:02, 19 February 2017 (UTC)

New nominators—and we always have a few—do not know these things. Since you know that, it's hard to give your "all nominators" argument credence. You're also clearly not familiar with the actual workings of GAN if you say that their reviews are "simply axed" after three weeks. Right now, out of 96 reviews currently ongoing, 42 are over three weeks old, and 18 of those are over six weeks old. There is no time limit for GANs. BlueMoonset (talk) 04:39, 20 February 2017 (UTC)

BlueMoonset adding the FAC and FLC to what you are saying, both of which I have experience. Currently, the oldest at both is December 5, 11 weeks old. Two months is about the turn around norm on the oldest, but it can be older, even 3-4 months. The only factor I've seen at FAC that gets a nomination axed is when a reviewer has found issues, and a nominator does not respond; and even then, such a nomination is left out there a long time before being archived. Some of what can, and does, make those nominations move faster is that they happened to be part of a project that diligently works on nominated articles. Since most projects at Wikipedia aren't super-active, that limits it. Another factor is, all through Wikipedia, reviewers often work on product of editors they are familiar with. Reviewers go for the lowest-hanging fruit at times, which at DYK means scoping out the most current date for something to review. Not everybody wants to scroll through a list of nominations at FAC, FLC, GAC or DYK, to find something to review - that which is at immediate eye level gets first consideration. Nominations just get lost in the shuffle, the possibilities of why are limitless. But to say that the nomination is ignored because the article is flawed, the subject matter uninteresting, or any other factor, is simply a POV, a statement of one person's opinion. — Maile (talk) 13:56, 20 February 2017 (UTC)

• I'm not sure that nominations should be rejected "after a period of time" but I do think that any nomination that hasn't had a response from the nominator to the reviewer for a period of time, say, a week, could be rejected. Gatoclass (talk) 10:43, 21 February 2017 (UTC)
  • I agree with Gatoclass. Argento Surfer (talk) 21:01, 12 April 2017 (UTC)

(P10) Move the credits section after the hooks in the prep areas

At present, the prep area builder has to copy the hook and the DYK credits across to the Prep Area. This is unnecessarily complicated by the fact that the two sections are widely separated by a screenfull of "See how this template appears on both today's Main Page" templates that could be moved down below the credits section. Moving the Credits section immediately after the Hooks section will save the prep area builder from having to scroll up and down, thereby reducing the chance of the common error of missing out on one of the DYK credits. (Can the DYK footer be moved into its own template to save another four lines? It would be well worth it.)

Implementation

{{DYKbox}}
</noinclude>
<!--Hooks-->
<div class="dyk-img" style="float: right; margin-left: 0.5em;">
{{main page image|image=Illuminated human alphabet.jpg|caption=Ave Maria Gracia Ple[na]|width=120x133}}
<!--See [[Template:Main page image]] for other parameters-->
</div>
* ... that the [[book of hours]] '''''[[Heures de Charles d'Angoulême]]''''' contains a [[Miniature (illuminated manuscript)|miniature]] of the beginning of the ''[[Ave Maria]]'' in [[Historiated initial|historiated letters]] ''(pictured)''?
* ... that ...
* ... that ...
* ... that ...
* ... that [[Charlottesville, Virginia]]'s oldest radio station, '''[[WCHV (AM)|WCHV]]''', was founded more than {{convert|200|mi|km}} away on the campus of [[Emory and Henry College]]?
* ... that ...
* ... that ...
<!--HooksEnd-->
<!-- Moving this into a template to save another four lines would be worth it too -->
<div class="dyk-footer hlist noprint" style="margin-top: 0.5em; text-align: right;">
* '''[[Wikipedia:Recent additions|Archive]]'''
* '''[[Wikipedia:Your first article|Start a new article]]'''
* '''[[Template talk:Did you know|Nominate an article]]'''
</div>
<noinclude>
<!-- 50 lines removed here -->
==Credits==
<div id="credits">This space is to credit the creators/nominators of the items in this template that in fact appear on the Main Page. If you replace or remove an item before it appears on the Main Page, please revert the promotion of the hook so its template appears again at [[Template talk:Did you know]]  and add a note to the nomination's template explaining why you removed it. Also add the template's link to the [[Wikipedia:Did you know/Removed]] page.
* {{DYKmake|Heures de Charles d'Angoulême|LouisAlain|subpage=Heures de Charles d'Angoulême}}
* {{DYKmake|Heures de Charles d'Angoulême|Martinevans123}}
* {{DYKmake|Heures de Charles d'Angoulême|Hillbillyholiday}}
* {{DYKmake|Heures de Charles d'Angoulême|Cwmhiraeth}}
* {{DYKnom|Heures de Charles d'Angoulême|Gerda Arendt}}
* {{DYKmake|WCHV (AM)|Xenon54|subpage=WCHV (AM)}}
<!--
******************** Example format ********************
** (Follow this or you WILL break something)
**
** Normal credit:      * {{DYKmake|ArticleName|Editor}}
** Nomination credit:  * {{DYKnom|ArticleName|Nominator}}
**
** Each credit MUST go on a new line
*********************************************************
-->

(P10) Discussion

Proposals are still being drafted

• These "credits" should be automated, simple as that. It should not require a human to hand-craft them and doing so is a complete waste of time. ITN has a "credit" system based on its template, it's a one click/save thing which is much better than the DYK system. Sure, it relies on a "click/save" but who really cares about such talkpage credits when most of the nominators have more than 10k edits? The Rambling Man (talk) 22:38, 18 February 2017 (UTC)

One of the common threads I'm seeing is that people perceive that there are a number of things at DYK that are drudgery, rote, and that could be automated or semi-automated through userscripts, bots, etc. Perhaps we should create a list of our "most wanted" automations and then ask the script community if they can come up with something? Mifter (talk) 23:55, 18 February 2017 (UTC)

• This would make things more convenient assuming manual promotion processes continue. It might make a good intermediate update while waiting for automation, assuming such feasible. I'm not sure how easily automated credits could be generated, given that the ones created in the nomination template frequently have issues even today. BlueMoonset (talk) 04:45, 20 February 2017 (UTC)
• It would probably be helpful to have both the hooks and the credits under one header - I've lost count of the number of times I've opened one when I meant to open the other. I don't understand the arguments about automation - it seems to me the credits are pretty much automated already. Gatoclass (talk) 10:46, 21 February 2017 (UTC)

(P11) ENGVAR neutrality check

I suggest adding a DYK nomination approval criterion and checkpoint for ENGVAR neutrality. The objective is to have the hook(s) evaluated for elements that might first be reported in relatively high volume as errors on the Main Page by users strongly associated with either American or British English (but not both) and misinterpreting an acceptable expression in the other variation.
For example, a hook today (2018-09-03) concerned visits by American baseball umpires to hospitals, where they present children with "stuffed animals", a standard term in the U.S., at least, for toy animals filled with a plush material, such as a teddy bear. This was interpreted by one user as meaning the product of a taxidermist and taken to be an error. I am American and had no idea that "stuffed animals" was not a universally understood term.
An admin mentioned that an attempt is made in ITN, for example, to avoid things like "England defeat Germany" with respect to football/soccer, which most Americans would consider to be an error, by rewriting the blurb to avoid the expression.
I presume such an evaluation would require review by an editor who is strongly "bilingual" and could catch these problems at the nomination approval stage. Jmar67 (talk) 21:52, 3 September 2018 (UTC)

Implementation

• To be determined

(P11) Discussion

Proposals are still being drafted