Wikipedia talk:Did you know/Archive 62

Archive 55

←

Archive 60

Archive 61

Archive 62

Archive 63

Archive 64

Archive 65

Implementing ideas

This section is for discussion of how ideas which have attained consensus above, can be implemented. cmadler (talk) 14:39, 12 November 2010 (UTC)

Incorporate CorenBot to scan for plagiarism

• One comment I saw was that Google would not permit text in Google Books to be checked. I'd be curious to know why this is. I would think they would want to help Wikipedia prevent plagiarism. 28bytes (talk) 17:25, 12 November 2010 (UTC)
  • Google will permit text in Google Books to be searched, just not automagically by bots like CSBot. It's a point worth making that it can often be helpful to run a text search directly in Google Books, as even the main web interface does not always cover Books to the depth that a specific Books search will do (question of resources or marketing, not sure which). Physchim62 (talk) 18:43, 12 November 2010 (UTC)
    • Accepting the limitations of CorenSearchBot, does anyone have ideas about how to incorporate it into the DYK process? cmadler (talk) 13:58, 19 November 2010 (UTC)

Encourage editors to manually use online plagiarism checkers

• Obviously, this is something to be incorporated into the proposed reviewing manual. Does anyone have a list of a handful of the best online plagiarism checkers? cmadler (talk) 14:00, 19 November 2010 (UTC)

More transparent logs, better accountability

• There have been several different suggestions about how to do this. My preference, assuming it can be mostly/entirely automated, would by a subpage for each hook nomination, transcluded onto daily pages, much like AfD, etc. That would allow editors to watchlist single nominations, rather than having to look through an entire page, as is currently required. cmadler (talk) 14:03, 19 November 2010 (UTC)

Require article nominators to review articles

• That's this one isn't it? Gatoclass talks of "Matski's proposal" in a later section header, but if it was Matski's I can't see where. Johnbod (talk) 15:00, 12 November 2010 (UTC)
• At the risk of spamming, I'll copy here an implementation suggestion made above. The {{NewDYKnomination}} template could be modified to output a link that a reviewer can use to check the nominator's contributions to T:TDYK, like so: check this user's TTDYK contributions. This would make verification easy. It's not perfect, since right now the link shows contributions to all template_talk pages instead of just T:TDYK, but it's a start, and I'm looking into a way to limit it to just T:TDYK. If people think this is a good idea, I'll put a modified version of {{NewDYKnomination}} in my user space for testing. 28bytes (talk) 15:04, 12 November 2010 (UTC)
  • I don't think it's a big problem that the search covers the whole of Template talk space, as template talk pages don't usually get many comments. See my results, for example: I've made fifty TT edits in 18 months (and I found a DYK I'd forgotten about!) Physchim62 (talk) 15:15, 12 November 2010 (UTC)

(ec)Great. Since the proposal says there must have been a review within the 5 days before the nom, by the time a review is done the nom's quid pro quo review will often have moved off the main suggestions page to a queue etc. How will the check cope with that?

I think people should include the quid pro quo article title in their nom, and it may be necessary sometimes to AGF. Johnbod (talk) 15:11, 12 November 2010 (UTC)

Even if their review has moved to the prep queue or beyond, the contribution will still show. Here are mine and yours to show how it would work. 28bytes (talk) 15:21, 12 November 2010 (UTC)

Yes, but those links won't identify which hook or hooks were reviewed for this particular nom. You might be looking at older reviews. Gatoclass (talk) 15:27, 12 November 2010 (UTC)

True, but both their nominations and reviews will show there. I was assuming that the quid pro quo would allow someone to, for example, review 8 hooks over a week, then submit 8 nominations the next week if they wished, rather than having to go nom-review-nom-review-nom-review. Is that not the case? 28bytes (talk) 15:54, 12 November 2010 (UTC)

I think that would be too difficult to do. I think you would need to do your reviews within a reasonable time period, for one thing your hook wouldn't be promotable until the review has been completed. Gatoclass (talk) 16:19, 12 November 2010 (UTC)

OK. In that case, I misunderstood. I assume then, that previously self-nomimated hooks and articles will be grandfathered in? In other words, if you've self-nom'ed 50 hooks in the past but done no reviews, to nominate #51 you would just need to do one review? I'd kind of figured that was the case, but that should probably be spelled out explicitly in the rules for clarification. 28bytes (talk) 16:28, 12 November 2010 (UTC)

Oh, heck yes! We're not going to make people do reviews for their old noms, that would be an impossible task. No, once the system is implemented it will apply to future nominations, not to old ones. Gatoclass (talk) 16:44, 12 November 2010 (UTC)

(edit conflict): That's one possibility. I was thinking that newDYKnom could be modified to include a string with "review1= review2= " etc. for every article in the hook, and that the nominator would then just add a link to every article he reviewed. Possibly though we could do both, that way we could see what reviews the nominator had reviewed for this hook, and also check easily that he actually reviewed it in cases where the hook has already been removed from the page. Gatoclass (talk) 15:19, 12 November 2010 (UTC)

(ec) I suggest that the following wording be used:

• Editors who have submitted five previous DYK hooks are required to review at least one article for each subsequent article they nominate. Nomination of articles created or expanded by a user other than the nominator is exempted from this requirement, though such nominators are strongly encouraged to do so anyway.

Any thoughts on where this should be added into the rules? Also, there was a suggestion to add a "check contributions" link (check this user's TTDYK contributions) to the DYK nomination template; could someone who's comfortable with such things do that? cmadler (talk) 15:13, 12 November 2010 (UTC)

I think we will need an entire new page. It's about time we wrote a guideline for reviewing in any case. Gatoclass (talk) 15:23, 12 November 2010 (UTC)

Re the link, I can do that. If there aren't objections, I'll knock out a test template for it this weekend. 28bytes (talk) 15:27, 12 November 2010 (UTC)

If DYK implements AfD-style subpages for each hook, transcluded onto daily pages, as discussed above, that would make this easier in all regards: easier to track (just point to the subpage you reviewed), and easier for a reviewer to stay engaged in the discussion of a hook. cmadler (talk) 15:21, 12 November 2010 (UTC)

That sounds like overkill to me. I think the suggestions in the previous section make more sense. Gatoclass (talk) 15:25, 12 November 2010 (UTC)

Sorry, I didn't have time to follow this whole discussion. But I also thought, that a new parameter in newDYKnom might say "nominator reviewed=", filled by article name. Such a parameter could be included right now, first on a voluntary basis, for a transition period and try-out-time. --Gerda Arendt (talk) 15:31, 12 November 2010 (UTC)

Lol, while typing up my suggestion below, Gerda had already made it.. such is life. - Theornamentalist (talk) 15:48, 12 November 2010 (UTC)

• In place of checking contributions, I was thinking that maybe a required parameter to the DYK nom template be added. In it, the nominator would place a link to a nomination they reviewed in the short past, which after saving would appear something like this:

• ... that Robbie "The Flame" Olivier and Ashleigh "The Thunderball Kid" Grimshaw faced off at Cage Rage 27 - Step Up for the Cage Rage British Featherweight Championship?

Created by Paralympiakos (talk). Self nom at 23:31, 30 October 2010 (UTC). Reviewed nom.

or a small linked graphic that would be easier to spot. The reviewer of this nomination could simply click the link, check to see that it is recent, and then proceed to review this nomination. It would be acceptable to not have a review under your belt to nominate before the nomination; leaving the parameter blank could give:

• ... that Robbie "The Flame" Olivier and Ashleigh "The Thunderball Kid" Grimshaw faced off at Cage Rage 27 - Step Up for the Cage Rage British Featherweight Championship?

Created by Paralympiakos (talk). Self nom at 23:31, 30 October 2010 (UTC). Review by Paralympiakos needed, click here for rules.

I think that this would be pretty transparent and easy for reviewers and nominators, and any confused new editor would be given leeway and/or help. - Theornamentalist (talk) 15:46, 12 November 2010 (UTC)

My concern about that approach would be for hooks with multiple articles. For example, something like this would be a huge pain for both the nominator and reviewer (but especially for the nominator), whereas a single link to all of that nominator's DYK contributions would be effortless for the nominator, and one click for the reviewer. 28bytes (talk) 16:07, 12 November 2010 (UTC)

The single link might also work better with regard to new-to-DYK editors (first 5 nominations). cmadler (talk) 16:12, 12 November 2010 (UTC)

But the problem with that as I said before is that there's no way of identifying if the reviews were done for this particular submission. A list of edits at T:TDYK simply doesn't achieve that. You have to have a list of reviews nominated by the author to doublecheck against his edits. Gatoclass (talk) 16:23, 12 November 2010 (UTC)

Admittedly growing in complication, but if we were to gain consensus on separating noms in the way we do AfD's, we could potentially have a "what links here" within the nomination next to the link like:

• ... that Robbie "The Flame" Olivier and Ashleigh "The Thunderball Kid" Grimshaw faced off at Cage Rage 27 - Step Up for the Cage Rage British Featherweight Championship?

Created by Paralympiakos (talk). Self nom at 23:31, 30 October 2010 (UTC). Reviewed nom.(check links)

and if TT:DYK link was given priority, the reviewer could check to see if the review has been linked in any other nominations. Even though the additions seem to be piling up, I think checking these two things would take the reviewer no more than 10 seconds (well, however long it takes to load) and it would not be too big of a deal. - Theornamentalist (talk) 17:20, 12 November 2010 (UTC)

Let's not bring the "format DYK like AfD" proposal back into the discussion just yet; there are serious problems with that approach (IPs wouldn't be able to nominate an article they'd expanded, for one thing) and the logistics would take a while to work out. I'm fine with adding either "contributions" or "reviewed nom" link (or both) to the new nom template, but I don't want us to get derailed by scope creep. 28bytes (talk) 17:37, 12 November 2010 (UTC)

We could have a separate sublist for IP nominations, transcluded under the same section with the other nominations, so aesthetically readers wouldn't be able to tell the difference. And a bot could turn these IP nominations into separate pages after they've been added. It's true that there needs to be work on the specifics and the technicals, but it is feasible, and would make sorting through the DYKs a lot easier (and editors can watchlist specific nominations!).--res Laozi speak 23:33, 12 November 2010 (UTC)

Well, I've started AfDs manually (pre-Twinkle) and it's a bit of a pain. With the current DYK nominations process, you open the date section, paste in a template, fill it out and save it. Walk me through the new (proposed) process. What steps would a nominator need to take to submit a nomination? 28bytes (talk) 00:18, 13 November 2010 (UTC)

Like so:

"If you do it this way, don't forget to add your nomination to the top of the page of Template talk:Did you know."

That's about it. That's one extra step, and the ability to watchlist specific DYK nominations more than makes up for it. Anon IPs can list their nominations on a transcluded sub-list, which can be turned into separate pages, either manually or by bot.--res Laozi speak 00:45, 13 November 2010 (UTC)

DYK Contributions link

Here's a test of my idea. I've copied the NewDYKnomination template to my user space, and modified it to add a DYK contributions link. Here's what it would look like on the nominations page:

Batman

• ... that Batman is right behind you?

Created by 28bytes (talk · DYK contribs). Self nom at 18:21, 12 November 2010 (UTC)

Fairly unintrusive visually, I think. Comments welcome. 28bytes (talk) 18:21, 12 November 2010 (UTC)

That's not technically DYK contributions, just all contributions in the Template Talk namespace. For people who are active in template coding they might have lots of non-DYK contributions there, although for the most part I suppose this link would at least make it easier to locate their DYK contribs. It would take up less space in the edit window if you made a template for that link, something like {{DYKcontribs|28bytes}}. Although, to be honest, if we are going to require that people leave links to their recent reviews along with their nomination, I'm not sure this link would be necessary. rʨanaɢ (talk) 19:35, 12 November 2010 (UTC)

Yep, I'm trying to find a link to just the TTDYK contributions but am not having any luck so far. (I had made User:28bytes/TT contribs for taking up less room and providing better maintainability but couldn't get the transclusion to work right, so I just subst'ed when saving the NewDYKNomination template for this demonstration.) Personally, I think a link like this would be preferable to requiring a nominator to copy and paste a diff into the template, because their most recent reviewing activity should show right at the top of the contribs list anyway without them having to do anything. 28bytes (talk) 19:52, 12 November 2010 (UTC)

That doesn't guarantee that the reviewer of their submission will check right after. The only reason I am supporting linking the difference is so that a particular review is bonded with that nomination. Speculation, but someone might look at TT:DYK and just think "eh, they've been editing the page, guess one of them is good for a review". Ha I'll have to copy the parenthetical enclosure you've made with your suggestion, it looks nice. - Theornamentalist (talk) 20:05, 12 November 2010 (UTC)

It ain't pretty, but this is more specific. Shubinator (talk) 02:31, 13 November 2010 (UTC)

• ... that Batman is right behind you?

Created by 28bytes (talk). Self nom at 18:21, 12 November 2010 (UTC) • Verify (review/1 use)

• Note not different from what I suggested earlier, just using 28bytes style from above. The "1 use" can come or go, currently the only way I can think to check that it is only used once is through "What links here", but that would require making DYK like AfD noms, which I understand is not a popular issue and is certainly not a quick fix. btw 28bytes, that article arose from reading your userpage a couple days ago, ha. - Theornamentalist (talk) 22:10, 12 November 2010 (UTC)
  • That's funny. I was wondering if that was the case. I have List of Atari 2600 games watchlisted (obviously) so when I saw that you'd linked a new one, I clicked over to read it, then went to see if there was a DYK nom for it. 28bytes (talk) 22:28, 12 November 2010 (UTC)

Also:Reviewing Guide

(edit conflict) I assume we will need a new guideline for reviewing. I was thinking of knocking up a draft in the last day or two, but didn't get around to it yet.

I think we'll need to have some specific actions incorporated into the review process. It should include checking the article for plagiarism and copyvio. It should also include, I think, a requirement for reviewers to "stay engaged" with the review process for a hook until that hook is either promoted or rejected. We don't want to have a perfunctory process where someone just leaves a comment as a "review" and then does nothing further. I personally stay engaged with almost every review I do, which is to say, I follow up to assist the nominator in resolving the outstanding issues, so I don't think this would be too onerous a requirement. Gatoclass (talk) 15:08, 12 November 2010 (UTC)

I think one way we could do that (and could work as part of the "transparent logs" proposal), is to have separate pages for DYK nominations, that are then transcluded on the main page. Similar to what the X for Deletion proccesses have initiated. This way, it's possible for editors to watchlist the DYK nominations that they've participated in.--res Laozi speak 23:20, 12 November 2010 (UTC)

That's been suggested before by myself and others, but apparently it is a bad idea due to it further increasing load times. (search for "15:27, 1 November 2010" on this page and you should find some links). SmartSE (talk) 01:01, 13 November 2010 (UTC)

Rjanag wasn't opposed to the idea, but he did bring up the loading times issue, as you mentioned. I don't think that transclusion will increase loading times by a noticeable amount, and any effect is dwarfed by the effect that the sheer size of Template talk:DYK has on loading times. And the net benefits of the idea (being able to watchlist specific nominations, more transparency, easier access to logs), outweigh any of the potential negatives. --res Laozi speak 01:43, 13 November 2010 (UTC)

I like this concept: improves responsibility for reviewers, and makes the process more user-friendly (being able to watchlist specific noms would make following up on comments so much easier). The Xfd model seems to work over there, we could have a similar index-by-date page. Would this system make prep-area moves more difficult? The Interior(Talk) 19:09, 18 November 2010 (UTC)

Has anyone started on the reviewing guide? If so, where is it (so others can help)? If not, I'll probably start it shortly (and post a link here). cmadler (talk) 14:54, 19 November 2010 (UTC)

Not finding anything, I'm starting on it in my sandbox at User:Cmadler/sandbox/DYKreviewguide. Feel free to jump in. cmadler (talk) 15:12, 19 November 2010 (UTC)

Implementing quid pro quo

Following up on the #Require article nominators to review articles discussion above, do we want to wait until new-and-improved nomination templates are in place before starting the QPQ requirement, or should we just put a notice up on the nominations and rules pages stating that it's in effect and to please add a comment with your nomination to indicate which hook you've reviewed? 28bytes (talk) 05:32, 17 November 2010 (UTC)

Getting people used to the idea before building it into the template (i.e., the latter suggestion) makes more sense to me. rʨanaɢ (talk) 05:55, 17 November 2010 (UTC)

OK, how's this?

You can view the whole edit notice as it would appear when editing the page here: User:28bytes/DYKEditNotice. Thoughts? 28bytes (talk) 02:18, 18 November 2010 (UTC)

I like it, this seems like a good transition. How do you propose we should link it, directly to the article or to the edit on the nom page that shows the difference? I think that asking for either would be good, although linking to the article might be fine for now, and much easier for us instead of having to find the difference, which some new editors may not be entirely sure of doing. I think we should introduce a new parameter in the nom template for it like:

{{subst:NewDYKnom | article= | hook=... that ? | status=new | author= | nominator= | reviewed article= }}

• ... that the Loyal Parliament of 1685 put high taxes on sugar and tobacco?

Created by Moonraker2 (talk • review: Batman). Self nom at 06:25, 11 November 2010 (UTC)
or

• ... that the Loyal Parliament of 1685 put high taxes on sugar and tobacco?

Created by Moonraker2 (talk • review). Self nom at 06:25, 11 November 2010 (UTC)

By the way, ha this is pretty lame to ask, but I can claim ignorance on this... is someone working on the whole AfD like nom page? - Theornamentalist (talk) 05:38, 18 November 2010 (UTC)

The more I think about it, the better of an idea I think it would be to show the difference, and 28 I think this can be achieved using the method you had suggested for checking T:DYK edits, maybe somewhat like this when someone is adding a nomination to the page in the last sentence on top:

DYK uses a template for nominating articles.

Please use one of the below strings to post your DYK nomination, using the "author" and "nominator" fields to identify the users who should receive credit for their contributions if the hook is featured on the main page. Check your recent DYK contributions for the "reviewed article" parameter and link the difference.

• Do not wikilink the article title, or the author and nominator usernames; the template will wikilink them automatically.
  
• Do not add a section heading if you are using the template; the template will add one for you.
  
• Do not include a signature (~~~~) after the template.
  
• Do not use fair use images in your hook suggestion.
  
• Do wikilink words in the hook and bold the main article.

1. New Article: {{subst:NewDYKnom | article= | hook=... that ? | status=new | author= | nominator= | reviewed article=}}
2. Expansion: {{subst:NewDYKnom| article= | hook=... that ? | status=expanded | author= | nominator= | reviewed article=}}
3. Nom with image: {{subst:NewDYKnom|article=|hook=... that ?|status=|author=|nominator=|image=|rollover=|alttext=| reviewed article=}}
4. Nom with sound: {{subst:NewDYKnom|article=|hook=... that ?|status=|author=|nominator=|sound=|soundcaption=| reviewed article=}}
5. Nom with video: {{subst:NewDYKnom|article=|hook=... that ?|status=|author=|nominator=|video=|videocaption=| reviewed article=}}
6. Other parameters: |article2=, etc. |author2=, etc. |ALT1= |comment=

See Template:NewDYKnomination/guide for more detailed instructions on usage of this template.

---

• {{subst:DYKtick}}
• {{subst:DYKtickAGF}}
• {{subst:DYK?}}
• {{subst:DYK?no}}
• {{subst:DYKno}}
• {{subst:DYK?again}}

You may notify the nominator of problems with {{subst:DYKproblem|Article|header=yes|sig=yes}}

---

- Theornamentalist (talk) 06:05, 18 November 2010 (UTC)

I guess my preference would be what Rjanag suggested, i.e. put the notice up in various places, then work out the details of the template. That being said, I've got no problem with expanding the template to include a "reviewed" parameter. Ideally it would be optional, and if left blank would spit out some text like "(please replace this text with the name of the nomination you've reviewed)" or something like that, to allow for people submitting a nomination, then finding one to review, then returning. My guess is that nominators will want to do it in that order, but I could be wrong. 28bytes (talk) 06:35, 18 November 2010 (UTC)

I think most nominators would want to submit their articles first, and then work out which article or articles they want to review, so I don't think it's a good idea to have a blank "substitute" text. Instead, New DYKnom should output a string like "review1=[[]] review2=[[]]" etc., then the submitter can just paste in the header of each nomination he reviews. Gatoclass (talk) 08:03, 18 November 2010 (UTC)

That sounds like a good approach to me. 28bytes (talk) 08:37, 18 November 2010 (UTC)

I agree, looks good. Anyone want to be bold and implement it?--res Laozi speak 08:47, 18 November 2010 (UTC)

We might also want a toggle of some kind, so the string only outputs if you have more than five DYKs. Gatoclass (talk) 09:06, 18 November 2010 (UTC)

I don't think that's possible with the way the template is designed right now. It would require some pretty big reworking (somewhere there would have to be a list of everyone with more than 5 DYKs, and even then I'm not sure if template parser functions would be able to handle it). rʨanaɢ (talk) 17:26, 18 November 2010 (UTC)

If this is to be introduced, then there should be a bit of prior notice. I'd suggest create an edit notice now warning of the change to come, and introduce the change after two or three weeks, to get people used to the idea. The edit notice could be worded to suggest that editors voluntarily review an article in the meantime, to get them used to the system. Mjroots (talk) 10:35, 18 November 2010 (UTC)

Why wait? It has been discussed here for about 2 weeks. Start it from tomorrow's noms (ie noms for Nov 19) and add a bit of explanation at the top of each new day for a week to get the regulars used to it. Johnbod (talk) 11:30, 18 November 2010 (UTC)

Problem is there are DYK regulars that didn't participate in the discussion. I think we should spend a week or so getting the word out (through Signpost perhaps?), before actually enforcing it.--res Laozi speak 13:13, 18 November 2010 (UTC)

Many regulars never contribute here except to complain about the treatment of their noms. Maybe they read the page, maybe they don't. The way to reach regulars is through the suggestions page as suggested above - they probably don't read Signpost either, though of course it should be mentioned there as general PR. Johnbod (talk) 13:22, 18 November 2010 (UTC)

I say implement it now. It's clear from discussion that if/when an editor makes a nomination and hasn't yet done a review, they can subsequently do the review and note it in their nomination. My understanding is that when a nomination is made without a review, it would just go on hold, similar to any other fixable problem, and only if it's not addressed would the nomination be rejected. So there's no harm in implementing it even if some people are not yet aware. Also, I'm sure there is portion of editors who, no matter how long we discuss it and how many different notifications we put up, will always plead ignorance. We've been discussing it for quite a while, it's time to implement. cmadler (talk) 14:08, 18 November 2010 (UTC)

I have no problem with implementing it quickly, but I think we should get NewDYKnom set up to handle it first. Gatoclass (talk) 14:12, 18 November 2010 (UTC)

Also I think we should start it on a new day, in order not to create confusion. So the current hooks will not require a qpq, but from day X they will be required. Otherwise we will have to be chasing people up to review for submissions they've already made, which is likely to end up a hassle for all concerned. Gatoclass (talk) 14:29, 18 November 2010 (UTC)

I certainly agree that nominations made before this is implemented should be exempt. No ex post facto quid pro quo! cmadler (talk) 15:53, 18 November 2010 (UTC)

How about bringing it in on 1 December. That would give time to make announcements in the Signpost and via an edit notice at T:TDYK. Mjroots (talk) 17:12, 18 November 2010 (UTC)

December 1 sounds reasonable to me. I agree, which the sheer volume of text coming through this page recently, it's not reasonable to expect every regular (much less occasional) contributor to have read about the new requirement. How about this: we add "Starting December 1" to the above edit notice (example below) and put it on the nominations page and edit notice today or tomorrow? That should give us some time to work out the details with the template while giving everyone else a heads-up of the change. 28bytes (talk) 18:00, 18 November 2010 (UTC)

Implementing quid pro quo (arbitrary break)

On the template end of things, once you guys work out what you want (i.e., section link to the article reviewed, diff, or whatnot), let me know and I can add it to the template; if it's just a diff or link it will be pretty easy. In the meantime, this can all be handled easily using the template's |comment= parameter. rʨanaɢ (talk) 17:29, 18 November 2010 (UTC)

Can someone clarify what exactly constitues a review? Do you have you approve on? Just comment that there is a length or source error? Grsz 11 18:04, 18 November 2010 (UTC)

Gatoclass was working on a "how to review" page (IIRC), but I would think you wouldn't have to approve one per se, just determine whether or not it meets the eligibility requirements and point out any problems found. I think if someone dug into the nomination and found problems with it, that would count as a review. (Slightly off-topic, but in the "how to review" page I'd love to see a comment to the effect of "please be thoughtful. Don't drop a 'the hook is boring' comment in and leave. If you think the hook is boring, help suggest a better one. Take another look at the article to see what interesting facts there are about the subject that might make for a better hook." Most people will do this anyway, but there's always the occasional wiki-lawyer who will insist that the rules didn't specify that they actually had to contribute a useful or thoughtful "review".) 28bytes (talk) 18:25, 18 November 2010 (UTC)

Clarification needed in notice... if I self-nom one hook with five articles, must I review one other hook or five? If it's a dual nom, must we both review an article? What if one nominator has more than 5 self-noms and the other doesn't? You know I am in favour of this proposal, but see the potential for tedious wikilawyering. EdChem (talk) 18:38, 18 November 2010 (UTC)

Can there be more than one nominator? I know you can nominate an article that you and others have worked on, but I thought there was just one nominator field in the template. 28bytes (talk) 18:59, 18 November 2010 (UTC)

I'd say a dual or multiple nom/credit only have to collectively review one nomination; one nomination in, one nomination out. I think even a self nom with 5 articles should only have to review one nomination. Sometimes a review with 3 articles which are easily checked or cited is faster than one whose hook contains multiple citations, or throughout many pages of a book. So let it be said, "one nomination in, one nomination out". - Theornamentalist (talk) 19:11, 18 November 2010 (UTC)

@28bytes and EdChem: There is only one nominator for a given nom, since only one person hits the "save page" button when nominating. rʨanaɢ (talk) 21:11, 18 November 2010 (UTC)

If you're referring to a nom with multiple editors (i.e., multiple people worked on creating/expanding the article and one of them nominated) then it seems to me that the person who nominates the article should be the one to review (he's the one who's participating in DYK). But if you guys haven't decided how to handle these questions yet, well, that's exactly the sort of reason not to be so hasty to implement the proposal before it's figured out. rʨanaɢ (talk) 21:13, 18 November 2010 (UTC)

Yes, I agree that the nominator of the hook (ie the person who posts the hook to T:TDYK) is the one who does the review. However, I think the nominator should review one article per article submitted, because sometimes people submit long multis and they can require a lot more work to review. Gatoclass (talk) 03:03, 19 November 2010 (UTC)

There's a problem with requiring one review per article as opposed to one per nomination. DYK nomination templates can get very unwieldy, and they're harder to track.--res Laozi speak 03:18, 19 November 2010 (UTC)

I don't see how a multinom will get any more "unwieldy" just by adding a string with "review=[[]] review2=[[]]" etc. As for "tracking", I don't see the problem. You just click on the link to confirm the hook has been reviewed, what's so hard about that? Gatoclass (talk) 03:26, 19 November 2010 (UTC)

It would probably be easier on both the nominators and reviewers if multi-article hook submitters found someone's else's multi to review. We should probably strongly encourage that, if not require it. Nobody wants to click on eight different links to confirm an 8-article hook submitter has reviewed eight separate (single-article) hooks. 28bytes (talk) 03:37, 19 November 2010 (UTC)

There are very few big multis so I hardly see this becoming a major problem. Gatoclass (talk) 04:14, 19 November 2010 (UTC)

@Hongkongresident: DYK policy shouldn't be dictated by what is or isn't hard to code into a template. Do what's right for the project, and the template will follow along (or if the template can't handle it, then it can be done outside the template). The rest of Wikipedia would have a field day if they found us making unreasonable policies simply because our template coders don't want to do extra work.

@28bytes: proposing that multi-hook article submitters should have to review other multi-hooks is unworkable. What if you have a good 8-article hook to submit and there are no other multi-hooks on TTDYK (after all, they are the exception to the norm)? You're just screwed. rʨanaɢ (talk) 04:37, 19 November 2010 (UTC)

Well, sure, if there aren't any to review then it would be pointless to require them to review one. I'm just trying to think of things that would lessen the burden on the nominators and reviewers, and if there are multiple-article nominations that can be reviewed, it seems sensible to encourage other multiple-article nominators to review them. I'll concede that a requirement to do that could be counter-productive, though. 28bytes (talk) 04:52, 19 November 2010 (UTC)

At any rate, I'll drop the suggestion if it's contentious. I'd be happy with adding "nominations that feature multiple articles require an equal number of articles (not hooks) to be reviewed" or something to that effect to the notice. That should resolve any ambiguity, assuming we go that route rather than the "one nomination in, one nomination out" approach. I agree with Gatoclass, this is a small minority of cases, so there's not much point getting too elaborate if a simple sentence or two will suffice. 28bytes (talk) 05:12, 19 November 2010 (UTC)

I agree that article for article seems fairest. EdChem (talk) 13:40, 19 November 2010 (UTC)

Re:Rjanag, I'm not too familiar with template coding, as has been made obvious, but if it can be done, I have no objections.--res Laozi speak 05:04, 19 November 2010 (UTC)

Previous discussion also supported article-for-article reviews, rather than hook-for-hook. cmadler (talk) 14:07, 19 November 2010 (UTC)

OK, I've updated the proposed notice box below. 28bytes (talk) 15:34, 19 November 2010 (UTC)

The previous discussion did not support article-for-article reviews. The initial proposal was hook for hook. A user suggested article-for-article, a few editors agreed, but there was never a detailed discussion or consensus on it. I'm not opposed to the idea, but there are a few minor issues that need to be addressed. For example: If a person reviews an 8 multi-article single hook nom, does that count as having reviewed one article or one hook? If you've reviewed one 8 article single hook nom, are you allowed to self nominate 8 separate hooks of your own?--res Laozi speak 16:04, 19 November 2010 (UTC)

Hmmm, now that you mention it, that is a possible complication. Maybe we should just stick to hook for hook after all? I'm not totally set on the article-for-article idea, and hook-for-hook certainly would be simpler .... Gatoclass (talk) 16:20, 19 November 2010 (UTC)

I stand corrected, there was not consensus on doing it article-for-article, and the initial proposal did seem to be worded as hook-for-hook. cmadler (talk) 17:40, 19 November 2010 (UTC)

Shall we do a straw poll on "article-for-article" vs. "hook-for-hook"? Either approach is fine by me but I agree we should probably establish consensus for one or the other before proceeding. 28bytes (talk) 17:57, 19 November 2010 (UTC)

Go for it. They both have legitimate pros and cons. cmadler (talk) 19:15, 19 November 2010 (UTC)

Another issue

And here's another issue that needs to be addressed: When do reviews "expire"? Can you pull out a review you made a year ago for a DYK nominated this month? There needs to be a time limit. But then, how long? A day? A week? A month? Half a year? And can you used reviews made before the proposed December 1st implementation date?--res Laozi speak 16:08, 19 November 2010 (UTC)

The idea is that you do your reviews after you nominate your article. So, you can't use reviews that are older than your nomination to meet the requirement. Now that you mention it though, this will probably have to be explicitly stated in the review guide to avoid confusion. Gatoclass (talk) 16:12, 19 November 2010 (UTC)

Ah, understood now. Thank you for clarifying. But this does bring up another issue. If users are required to review after they've nominated, wouldn't that discourage editors from reviewing multi-article nominations? As multi-article nominations require more work, for essentially the same amount of credit.--res Laozi speak 16:22, 19 November 2010 (UTC)

That's not really any different from the situation already. No one has special incentives to review multi-hooks, but somehow it gets done. Large multi-hooks are rare enough anyway that I doubt it much matters who reviews them. rʨanaɢ (talk) 19:00, 19 November 2010 (UTC)

One more potential problem: There needs to be a criteria for hook reviews. Saying something subjective or brief like: "I don't like the picture" or "The subject is boring", which is a statement that can be made without looking at the article, shouldn't (or should?) count as a review credit. If we're going by review credits, then there needs to be a guideline on what's acceptable and what's not. Otherwise, DYK could be flooded with reviews that are meaningless, pointless, or entirely irrelevant.--res Laozi speak 16:35, 19 November 2010 (UTC)

Yes, the "review" requirement will have to have a few specifics. cmadler is working on a review guide now. Gatoclass (talk) 17:11, 19 November 2010 (UTC)

Hmmm, I had thought reviews could be done before the nomination. I thought I saw somewhere that someone had suggested within a week prior, which I think is a reasonable limit. If that were the case, then nominations made on 12/1 could use reviews done on 11/24 or later. cmadler (talk) 17:25, 19 November 2010 (UTC)

I think it will create problems if users are allowed to use earlier reviews. For one thing, they are more likely to have already been promoted, which means more problems verifying them. For another, I think it will be more natural for someone to want to submit his article first and then decide which hooks to review. If you reverse the sequence, it may encourage more hasty reviews. And then, if you allow older reviews, it will be more difficult to tell whether or not the user has nominated this review previously. The nominator may also lose track himself. Gatoclass (talk) 04:21, 20 November 2010 (UTC)

Implementing quid pro quo (another break)

I added the clarification for multiple-article hooks. Since the article-for-article method was not unanimous, any strong objections to doing it this way? I also added a link to the "How to review a nomination" section; we can update this link when and if there's a full-page reviewing guide. Thoughts? Any further issues that need clarification/discussion before adding this? 28bytes (talk) 15:34, 19 November 2010 (UTC)

Looks good to me, except for the line about users who have "nominated" more than five DYKs. IMO, it should be users who have received more than five DYK credits - otherwise we might be inviting incompetents to do reviews. Also, I would think it would be much easier to check on the number of credits than the number of nominations. Gatoclass (talk) 15:51, 19 November 2010 (UTC)

Er, I'm assuming there was consensus for this (there sure doesn't look like it at quick skim above, though, I may have missed some, I quit reading this page for awhile in all the brouhaha...). But I'm not sure requiring "you have to put on your hook which one you reviewed". That seems like it will (a) clutter up the noms, and (b) seems vaguely peacockish - "look what I did!". It seems to me that assuming good faith might be a better idea - although I do see the problem that if reviewed hooks are promoted then it would be hard to verify...a realisation that just took the wind out of my sails of my initial "strongly against this" motion when I started typing this comment. Ah well, carry on then! - The Bushranger _{Return fire}^{Flank speed} 16:11, 19 November 2010 (UTC)

It's not peacockish (actually, I find the idea that reviewing DYK noms could ever been seen as peacockish -- that would have to be a heck of a review!), it's simply enabling verification that this (new) requirement is met. It's being built into the DYKnom templates, so it shouldn't clutter things up too much. cmadler (talk) 17:20, 19 November 2010 (UTC)

Ah. Putting it in the template should make it quite nominal. I withdraw any objections (and I think "hook for hook" is the way to go). :) - The Bushranger _{Return fire}^{Flank speed} 18:19, 19 November 2010 (UTC)

Grammar in Prep Area 3

One of the hooks in Prep Area 3 currently says:

• ... that in spite the construction of modern office and apartment buildings and the 1985 Mexico City earthquake, Colonia Roma still contains 1,100 of the mansions built there in early 20th century?

That should say either "despite the construction" or "in spite of the construction". --Metropolitan90 (talk) 15:04, 19 November 2010 (UTC)

Fixed, thanks. But note that anyone can edit the prep pages, so next time you can fix it yourself if you like :) Gatoclass (talk) 15:19, 19 November 2010 (UTC)

Another Queue Three grammar issue?

"...then played three years in Major League Baseball..." in the Hub Hart hook seems to me it would read better as, "..then played for three years in Major League Baseball...". - The Bushranger _{Return fire}^{Flank speed} 16:13, 19 November 2010 (UTC)

Missing alt text for picture in Queue 4

The picture for the lead hook in Queue 4 has no alt text. I try to review these at the Prep stage but I missed this one. I suggest 'alt=Mainly black butterfly with a row of blue-green dots on the edge of the hind wings and white dots on the fore wings'. Mikenorton (talk) 19:34, 19 November 2010 (UTC)

These ought to be caught before prep. They shouldn't be approved or promoted without alt-text. The template leaves people nasty messages if they don't use alt-text, which sometimes helps (although some people put in bad alt-text just to avoid the nasty message); the real problem (which is what happened in this case) is when people nominate without an image and then add one later, without alt-text. rʨanaɢ (talk) 19:39, 19 November 2010 (UTC)

Alt text added. --Allen3 ^talk 19:45, 19 November 2010 (UTC)

Thanks, Allen3. Rjanag, I agree that too many nominators just repeat the rollover text as the alt, which is hardly helpful. Mikenorton (talk) 23:56, 19 November 2010 (UTC)

Prep 4/3

In prep 4 I read "... that the city of Guanajuato, Mexico is filled with narrow alleys", so Mexico is filled with narrow alleys? Missing a comma. I also confess that I would prefer the Verdi Requiem, now in prep 3, to go with that picture rather than with a battleship, although that of course is also a way to remember the dead. --Gerda Arendt (talk) 10:08, 20 November 2010 (UTC)

Added the comma. Materialscientist (talk) 10:19, 20 November 2010 (UTC)

Frames not displaying properly at T:TDYK

Am I the only one having problems with the way the frames are displaying on the suggestions page? Simon Burchell (talk) 19:51, 20 November 2010 (UTC)

Seems to have sorted itself out now. Please ignore me... Simon Burchell (talk) 22:03, 20 November 2010 (UTC)

Reporting errors in queues and preps

Template:Did_you_know/Queue says "To report errors in the queue, please post at WP:ERRORS". The message was added by HJ Mitchell on 25 August upon some request. The present reality is that WP:ERRORS is handled by main page admins who are often not a part of the DYK chain. I propose to change it to ".. please post at WT:DYK", but would welcome other ideas. Materialscientist (talk) 09:22, 23 November 2010 (UTC)

You're right, it should be WT:DYK. —Bruce1ee^talk 10:27, 23 November 2010 (UTC)

Changed. Shubinator (talk) 22:06, 24 November 2010 (UTC)

Queue 3 (again)

A wording issue...the hook reading "...of the loaches family..." seems very awkward to me. "...of the loach family..." would read better. (Or as a second option, "...of the family of loaches..."). - The Bushranger _{Return fire}^{Flank speed} 01:40, 24 November 2010 (UTC)

I and Google search agree with you. Changed. Thanks. Materialscientist (talk) 04:26, 24 November 2010 (UTC)

Prep 1

I'm concerned about this article, currently in the queue in Prep #1. It seems to me this article is taking sides, rather than presenting the topic neutrally. I can also see the hook stirring controversy. Should we really be running this? Gatoclass (talk) 08:47, 25 November 2010 (UTC)

Abstaining on the content, the use of the plural in the hook as well as calling the term "death panels" a "word" seem iffy. Haus^Talk 09:55, 25 November 2010 (UTC)

Frankly, I was looking with caution at this hook while promoting other sets, and will hardly promote that set myself. Thus further comments are welcome. Materialscientist (talk) 10:00, 25 November 2010 (UTC)

I've pulled it from the prep set for further discussion. 28bytes (talk) 17:05, 25 November 2010 (UTC)

I wondered about that myself, but from the discussion elsewhere thought other people figured it was OK, so I wasn't going to rock the boat. IMHO the article does have a somewhat "hurr hurr stupid conservatives" air to it. - The Bushranger _{Return fire}^{Flank speed} 19:09, 25 November 2010 (UTC)

Yeah, it kind of does. I may take a stab at rewriting some of it if no one else does. 28bytes (talk) 19:57, 25 November 2010 (UTC)

Current Queue 2

Hi, I notice that the last hook in this set keeps being moved around. IMO, the most startling and quirky hook is the second-to-last, about Homosexuals Anonymous. Anything that follows seems tame by comparison. Yoninah (talk) 09:53, 25 November 2010 (UTC)

It was I who shuffled them, without really having much preference between the last two. If others think Homosexuals Anonymous is quirkier, I'll shift it down. Materialscientist (talk) 10:04, 25 November 2010 (UTC)

I'm biased - I rewrote / expanded the HA article - but would prefer the bottom slot. I'd also like to note that it goes live in a bit over 4 hours, so any decision should be soonish. EdChem (talk) 01:12, 26 November 2010 (UTC)

Queue 6

I don't understand what is so quirky about the last hook in this set. I think millions of non-Jewish readers won't understand it at all. I suggest rewording it this way and moving it up. The hook about Byron McLaughlin is much more suitable for the last place.

• ALT1: ... that Beth Israel Congregation of Chester County was the first synagogue in America to appoint a woman as the senior and sole rabbi? Yoninah (talk) 10:02, 25 November 2010 (UTC)

Not much fun there indeed, but I thought the humor was in someone being conservative, yet making radical moves. IMO, the McLaughlin's hook is less quirky (routine case, probably happened daily at US airports). Materialscientist (talk) 10:10, 25 November 2010 (UTC)

Bach cantata - again

With the first Sunday in Advent we start a new liturgical year. Bach wrote BWV 61 for the occasion, nominated 19 November for 28 November. This is the first time in the weekly sequence that an article on the Bach cantata existed, but I wrote a new one, following the new format, just keeping the list of recordings. Please let me know soon if that is acceptable. --Gerda Arendt (talk) 13:40, 23 November 2010 (UTC)

Two days later, same question, --Gerda Arendt (talk) 13:03, 25 November 2010 (UTC)

The nom is at Template_talk:Did_you_know#Nun_komm.2C_der_Heiden_Heiland.2C_BWV_61. I have checked and approved it. It will need to be queued to appear on Sunday. EdChem (talk) 13:31, 26 November 2010 (UTC)

I've moved it to prep 4. 28bytes (talk) 19:05, 26 November 2010 (UTC)

Thanks! Will start the next one. --Gerda Arendt (talk) 19:09, 26 November 2010 (UTC)

Comment / Suggestion: The queue the BWV 61 hook will appear in is on Sunday only for those in ttime zones GMT+1 to GMT+11... if it were moved back a queue or two it would be Sunday for most oor all of the planet. One queue back would have it on the main page on Sunday morning for EEurope, where it is the anniversary of its initial performance. Gerda, any thoughts on which queue would be most suitable? 28bytes, any view? EdChem (talk) 03:17, 27 November 2010 (UTC)

Yes, I had noticed that as I was filling the latest prep queue. Queue 2 should be moved back to either Queue 3 or 4 once there's a replacement set available. 28bytes (talk) 03:20, 27 November 2010 (UTC)

Hook-for-hook or article-for-article, continued

Judging from the above discussion on "hook-for-hook" vs "article-for-article", it looks like there's no real consensus either way. I was leaning towards "article-for-article", but in the interest of moving things forward one way or another, how about this: to keep things simple, we go with "hook-for-hook" for now, and agree to revisit it if and when it looks like there's a problem with it. Are there any objections to this approach? 28bytes (talk) 22:08, 24 November 2010 (UTC)

None here. - The Bushranger _{Return fire}^{Flank speed} 22:29, 24 November 2010 (UTC)

Go ahead; either is better than neither. cmadler (talk) 01:09, 25 November 2010 (UTC)

Yes (as an a-for-a supporter). Johnbod (talk) 01:14, 25 November 2010 (UTC)

Yep, it's better than nothing (another a-for-a supporter). Royalbroil 04:08, 25 November 2010 (UTC)

Should be article-for-article, IMO, but agree that something is better than nothing. EdChem (talk) 04:27, 25 November 2010 (UTC)

OK, I've created {{DYK rules change}}. Can an administrator place that at the top of Template:Editnotices/Page/Template talk:Did you know? 28bytes (talk) 21:31, 25 November 2010 (UTC)

Is that the best place for it? I would have thought it would be more visible at the top of the page. Gatoclass (talk) 09:46, 26 November 2010 (UTC)

IMO it should go in both places. 28bytes (talk) 19:04, 26 November 2010 (UTC)

I've placed it on the nominations page. I still think it would be helpful to have it in the edit notice as well, but I'll defer to others on that point. 28bytes (talk) 04:50, 27 November 2010 (UTC)

unsourced BLP Drive

In an earlier discussion on this page, Slp1 proposed that "newly and completely (top to toe) sourced BLPs be made eligible for DYK. Not new articles, but older articles that were unsourced as of some recent date, and which have now been fully and reliably cited." 28bytes expressed support for the idea, as did Physchim62 who sensibly (in my view) added that "they can be nominated as "new" (i.e. minimum 1500 characters) without being a five-fold expansion, but that otherwise they have to pass the same requirements as any new BLP on DYK. Cmadler noted (in support) that the referencing would need to be recent and the nomination timely. Naturally, a suitable hook would be needed. Though I did not say so explicitly in this thread, I am also in agreement with this idea. The thread, unfortunately, died in the midst of all the other recent discussions. No opposition to the idea was expressed in the thread, but the views of 4-5 editors in agreement is not community / project consensus to implement the proposal.

To advance the discussion, I nominated the Robert Olmstead article at Template talk:Did you know#Robert Olmstead to test this proposal. It has now been reviewed and rejected on length grounds for a x5 expansion, noting that it does not pass under the existing rules. I accept that this is a reasonable view to take, but would like to invite further comment to see if the DYK community would like to see long-term unsourced BLPs being top-to-bottom sourced (and in this case more than doubled in length to exceed the 1500 character requirement) to be included in DYK. I think coming to a community consensus on whether we support helping recognise the work done in fully referencing long-term unsourced BLPs is desirable, whether or not the consensus finds that my specific nomination is deemed suitable. All perspectives welcome.  :) EdChem (talk) 23:10, 10 November 2010 (UTC)

I do support the idea of the BLP drive (as noted above), but since reviewers may not be following the threads here, it's probably best to put a note somewhere in the rules and instructions saying this is an OK exception before offering test nominations. And the note should probably wait until there's a firm(er) consensus for the exception. Perhaps we can handle this with a test run similar the same way the date flip was done, as a one-week trial with a note at the top of T:TDYK inviting feedback here. 28bytes (talk) 23:43, 10 November 2010 (UTC)

Recognition of such effort is certainly warranted but is DYK the right medium for recognition? Surely the judicious distribution of barnstars would accomplish the same goal of recognition without adding to the DYK workload or diluting its purpose, showcasing Wikipedia's newest articles. It's one thing to receive a little front page exposure for prose you've carefully crafted and quite another to expect it for properly sourcing somebody else's prose no matter how old. - Dravecky (talk) 23:49, 10 November 2010 (UTC)

I'll reiterate my support for the idea (for what it's worth), although EdChem doesn't mention that the proposal was (implicitly) to be time limited until WP:DAY, that is January 15, 2011, or the tenth anniverary of the existence of our favourite online encyclopedia. I completely disagree with Dravecky: an article that has been both saved from the BLP slaughterhouse and has a hook that is interesting is a better candidate for the Main Page than a cookie-cutter article. Sourcing BLPs when you didn't write them yourself, and then finding one that has a decent hook, is undoubdtedly harder than much of the composition that goes on for DYK at the moment, as can be seen by the contribution stats of certain editors. Physchim62 (talk) 00:21, 11 November 2010 (UTC)

I agree that we should wait to see if we can attract more over support votes for this proposal. Thank you EdChem for picking up the ball. And I'd agree with Physchim62 that sourcing the articles top to toe is often very hard work indeed. --Slp1 (talk) 01:00, 11 November 2010 (UTC)

In principle, I'm inclined to support the notion of relaxing the 5x expansion requirement a bit in order to recognize significant improvements to unsourced BLP articles. However, in addition to references, I would want to see a clear increase in the content value of the article, as well as an interesting hook. The Robert Olmstead example doesn't do those things for me. The additions to the article are mostly quotations from reviews (note that DYK has some history of discounting quotations when calculating eligibility), the length increase is barely 2x (I've added a little more to the article since then), and the proposed hook is both too long for DYK guidelines (241 characters vs. a limit of 200) and not very interesting (largely due to its excessive length). --Orlady (talk) 05:24, 13 November 2010 (UTC)

• 28bytes, fyi, I did include a note with the nomination, pointing to the earlier discussion.
• Dravecky, here is a diff for the changes I made - I believe what I did was more than just "properly sourcing somebody else's prose" – consider the diff, you can decide for yourself.
• Physchim62 is quite correct, I missed the implicit date deadline, though I would support including eligibility for long-term unsourced BLPs until the backlog is gone.
• To be clear, this is much less about my nomination than it is about whether we as a project support the principle of assisting in recognising the work in properly sourcing BLPs. I agree with Physchim62 that the sourcing of these articles is time-consuming work, and often involves adding material and redrafting, not to mention wikifying and copyediting. If the consensus is that the idea is supportable but my nomination is unworthy then I'll accept it, but I would very much like us to come to a firm (and preferably rapid) decision. EdChem (talk) 06:09, 11 November 2010 (UTC)

Perhaps a way to gain more consensus for this would be to relax – but not waive – the expansion requirements? Something like 2x or 3x for newly-sourced BLPs? Either that or retain the 5x expansion requirement but go by raw byte count to allow the references to count as part of the expansion? That may bring it more in line with DYK's traditional aims regarding new content. Just a thought. 28bytes (talk) 06:31, 11 November 2010 (UTC)

• As already noted, I support this change. Providing thorough citations for a previously-unsourced BLP article is high value to the encylopedia, and I argue that it's similar to fixing a copyvio, which is something for which we already make a special allowance at DYK. My understanding is that eventually this should cease to be an issue, because all new BLP articles are required to have at least one source; there's a special proposed deletion process for this saying the article can be deleted 10 days after creation if it still lacks sourcing. Since no new unsourced BLP articles should be coming in to Wikipedia, there is a finite number of articles to which this exemption could apply, and other abitrary dates that we might choose aside, once that supply of pre-existing articles is exhausted, there will be no further need for this exemption. cmadler (talk) 12:49, 11 November 2010 (UTC)
• Support: I fully support this concept. We at WP:URBLPR and WP:URBLP really need more editors if we want to eliminate the unreferenced BLP backlog. Barnstars by themselves do not draw in new editors, and many of these articles could be DYK candidates with some editing help. I would propose that the 5x expansion requirement be relaxed to 2x, keeping the minimum length requirement in place, and the nom must be made within 5 days of the expansion. That way the articles are "expanded" as DYK promises.--Milowent • ^talkblp-r 14:15, 11 November 2010 (UTC)
• I like the idea but I'm unsure whether this should be a part of DYK. After all, DYK has a different goal, to showcase new articles. I think we should rather have a separate section on the Main Page similar to DYK but explicitly for such articles, thus emphasizing that such work is very important to the project without mixing it with DYK. After all, if you make this an exception for DYK, people won't know that the article was previously unsourced, thus possibly confusing readers and contributors alike. Regards SoWhy 14:30, 11 November 2010 (UTC)
• I'm keen on this idea, but I might as well point out that whatever happens to the backlog of known unreferenced BLPs in the next few weeks, we are still finding old ones from previous years and have no idea when we will have finished identifying all our unreferenced BLPs amongst our older articles. At some point the importance of adding articles to the pedia will drop compared to maintaining what we already have, so I think it would be sensible to gently broaden DYK towards article improvement. ϢereSpielChequers 14:54, 11 November 2010 (UTC)
• I Support but would prefer some basic requirement for expansion alongside the referencing, something in the way of 5x bytes or in the way of 2-3x in text length, Sadads (talk) 15:59, 11 November 2010 (UTC)
• I think this is a great idea; it would draw more focus on the need to reference BLPs, and also provide an opportunity to showcase some interesting articles and hooks. Unlike writing a good article, it should also be relatively easy for new editors to take part. Warofdreams talk 02:43, 15 November 2010 (UTC)
• I support as well, though I also believe that the articles should, at minimum, meet the 1500 requirement. But treating them as new articles seems fair to me. This is a method that should, hopefully, get more people involved in referencing unsourced BLPs. Silverseren^C 20:02, 15 November 2010 (UTC)
• Support without an expansion requirement, only the normal minimum length requirement. Gigs (talk) 15:15, 18 November 2010 (UTC)
• Support sounds like a great idea to me. As long as they meet the other DYK criteria, waiving the 5-fold and counting them as new should really help the drive. It'll also encourage those people who do work on the drive to take the article from no sources to well sourced, rather than 1 or 2. Recommend they are being specifically highlighted as under this scheme though, as we're significantly raising the profile of these BLPs, and we want to make sure they're right.--Worm 10:27, 26 November 2010 (UTC)
• Support, perhaps the NewDYKNom template could be modified to include a blp= paramater so that it's explicitly clear these are new-BLPs. I'd hate to deny one by mistake! - The Bushranger _{Return fire}^{Flank speed} 18:36, 26 November 2010 (UTC)

An implementation proposal is posted below at Wikipedia talk:Did you know#Including Newly Sourced BLPs at DYK. EdChem (talk) 13:05, 27 November 2010 (UTC)

Hook-for-hook or article-for-article?

Regarding the above discussion for implementing the quid pro quo proposal, at least two options have been discussed for handling nominations that feature more than one article.

• Article-for-article: For example, if a nomination includes four articles, the nominator must review four single-article nominations, or two two-article nominations, or any equivalent combination.
• Hook-for-hook: For example, if a nomination includes four articles, the nominator must review any other nomination, whether it is a single-article nomination, a ten-article nomination, or anything in between.

There are pros and cons to each approach outlined in the discussion above, but we need to gather input and settle on one or the other. I'll start.

• Article-for-article, although I have no strong objections to the hook-for-hook approach. 28bytes (talk) 20:19, 19 November 2010 (UTC)

• Hybrid - I base this on the idea that we should encourage multi-hooks, and that a multi-hook takes more work to review than a single-hook. So I propose that an editor nominating a multi-hook only needs to review one hook, but that an editor reviewing a multi-hook gets credit per-article. That will help to 1) create an incentive for editors to nominate related articles in multi-hooks and 2) avoid a disincentive for editors to review multi-hooks. cmadler (talk) 20:28, 19 November 2010 (UTC)
• Hook-for-Hook I've reviewed a single article hook that took me ten minutes. Time spent is not equivalent to number of articles in hooks. Plus I think AforA is more complicated. Finally, multi-article hooks tend to draw in a reviewer... at least a decent amount of time. - Theornamentalist (talk) 20:33, 19 November 2010 (UTC)
• Hook-for-hook, simpler. The basic unit of DYK is the nom, not the article; setting up a bunch of formulae for dealing with multi-hooks seems to introduce a lot of extra complication, when hook-for-hook reviewing already would address the main complaint (people nominating and not helping review—it shouldn't matter if the amount of articles they nominate and review is not exactly the same, as long as they are making contributions in both areas). rʨanaɢ (talk) 20:36, 19 November 2010 (UTC)
• Hook-for-hook. - The Bushranger _{Return fire}^{Flank speed} 23:27, 19 November 2010 (UTC)
• Hook-for-hook - For simplicity's sake, although if you've just reviewed say a 15x hook common sense should probably allow you to nominate more than one. Mikenorton (talk) 00:01, 20 November 2010 (UTC)
• After momentarily wavering last night, I think I still prefer article-for-article, as on reflection I don't think hkr's scenario above presents any real problem. You can still link individual articles in a multi from the section header, which is simple enough. Gatoclass (talk) 04:28, 20 November 2010 (UTC)
• Article for article Royalbroil 05:00, 20 November 2010 (UTC)
• Article for article possibly up to a maximum of say 4. What was the record we had? 15, or more. Johnbod (talk) 05:06, 20 November 2010 (UTC)
• Neutral. I could be convinced of either position. However, I believe that we may need a working definition of what a "review" is. Some hooks (for example, much of Alansohn's output) are dead-easy to review and approve. If I were trying to game the quid-pro-quo system, I would choose those for easy credit. On the other hand, for some nominations (even single-article hooks) it takes a substantial review effort to get to the point of saying "The hook needs a source." IMO, the quid-pro-quo arrangement should "count" a review effort such as that, and should not require the reviewer to stick with the article and hook through an ensuing series of article revisions and alternate hooks. By that definition, one single-article hook could require many "reviews." However, if "review" is defined to require that the reviewer stay with the process until its conclusion, that will only increase the number of people who volunteer for "easy" reviews, without making much impact on the more difficult reviews. Is my definition of "review" consistent with what the rest of you are thinking? --Orlady (talk) 05:23, 20 November 2010 (UTC)

I don't think we can start parsing reviews for difficulty level. But yes, I do think we will need to set a few ground rules on what exactly constitutes a review. Gatoclass (talk) 10:30, 20 November 2010 (UTC)

• Article for article makes the most sense. Question I don't recall a case where one editor reviewed less than all the articles in a hook. Is there a good precedent for how to make this clear? Would a new type of tick icon be useful for this? Haus^Talk 06:06, 20 November 2010 (UTC)

I think people have always understood that if you review a multi, you are reviewing all the articles for compliance - otherwise you would obviously not be able to approve it. So I really don't anticipate much need to state this explicitly. Gatoclass (talk) 10:37, 20 November 2010 (UTC)

• Hook for hook, preferring simplicity, at least initially. Although multi-article nominators should be "heavily encouraged" to contribute more reviews, a strict article-for-article criteria could result in a lot of unnecessary complications. I wouldn't oppose introducing an article-for-article approach if the hook-for-hook one proves to be successful.--res Laozi speak 20:31, 20 November 2010 (UTC)

Lousy idea. (**I actually hadn't seen the extensive proposal options for this before posting here and would actually agree that this is one of the more sensible options but I still oppose it and five people supporting it is not a consensus) I've officially stopped contributing to DYKs. They are supposed to be fun and enjoyable, not force you to do things. A better solution would be to appoint a dedicated panel of DYK reviewers who actually want to review new articles or to set a maximum limit on the number of DYKs that can be nominated on any given day to make reviewing tem manageable rather than forcing editors to review other people's work. If we must have such a system then it should be optional and a message given every time you post a hook asking for asisstance rather than forcing you to do it as Hong Kong resident says above. I think DYK will now loose out on scores of decent articles because the contributors who have already oftne put a lot of work into an article haven;t the time or patience to be obligated to review the work of others. Sorry but wikipedia is supposed to work by volunteers. And quite frankly there is something about "force" here which I strongly disapprove of. Surely there are better ways to get DYK logs effectively reviewed. I also think that many reviewers who are not really interested in reviewing but have to to meet the new "requirements" will not put much time and thought into the articles of others and may even approve of them without really bothering to research their hooks and in the end the articles will have to be doubly checked anyway.♦ Dr. Blofeld 12:54, 27 November 2010 (UTC)

Okay then, that's your choice. Part of the reason we put this in place was to reduce the burden of existing reviewers, whether that occurs through nominators complying with the hook review requirement or ceasing to nominate, the object of the exercise is obtained. Although I must say I am truly astonished and disappointed to see some contributors reacting in this way. Gatoclass (talk) 14:35, 27 November 2010 (UTC)

No, I've long tired of DYK and the pettiness over articles expanded x4.99 and "not 5 sorry" type attitude. This "rule" well and truly reinforces my decision to no longer nominate my articles. And my lack of contribution to DYK may actually reduce the "burden" for you. I am certain that I'm not the only one who thinks DYK is now no longer worth it, a lot of people can;t be nothered to nom articles anyway, but this certainly decides it when they are now required to review other work as well just to see their nom go through. And for what purpose? So a tiny proportion of daily readers can view it for a very short length of time...♦ Dr. Blofeld 15:54, 27 November 2010 (UTC)

Quite frankly, given that I have probably devoted hours to reviewing your hooks, it's very disappointing to find that you are unwilling to spare even a few minutes of your time to put something back into the running of this project. So you can hardly expect me to be overly sympathetic to your POV. Naturally I hope you will reconsider, but if not, perhaps it's just as well you don't contribute here if you can't do so without resentment. Gatoclass (talk) 17:09, 27 November 2010 (UTC)

Start date for quid pro quo

When the December 1 start date was originally proposed, December was weeks away, but as it's taken time to iron out some of the details, the template has only just gone up. I'm thinking it should be up for more than a couple of days before QPQ comes into play. Should we move the start date back a week? Gatoclass (talk) 06:14, 27 November 2010 (UTC)

I'd say we start QPQ after the holiday seasons, when there may be more editors logging in and hopefully new participants coming in to DYK. Let's not scare away the newbies too soon. How about 2011-01-11? --PFHLai (talk) 07:38, 27 November 2010 (UTC)

I think we'll absolutely get killed over the holiday season if this isn't in place by then. We've barely been able to keep three queues filled the last couple of days. Besides, actual newbies don't have to review anything; it's not until they've nommed 5 articles that the reviewing requirement kicks in. 28bytes (talk) 08:16, 27 November 2010 (UTC)

Is it time to go to three updates a day, at least for a few weeks? Yes, we need more reviewers but also the submission rate at the moment is slow... on which subject, any chance we could agree on the unsourced BLP submission idea? EdChem (talk) 10:26, 27 November 2010 (UTC)

Looking through the above BLP drive discussion, there does seem to be consensus for it. For next steps, perhaps drafting a proposed subsection for Wikipedia:Did you know/Additional rules on its talk page? It seems that the consensus is to keep the 1500-character requirement, but relax the 5x expansion requirement to 2x, and keep all the other requirements in place (nomination date, hook length, hook must be interesting, etc.) Let people review and comment on the proposal for a few days and if there aren't any strong objections, move it from talk to the rules page, and link to it whenever a BLP drive hook is nominated for reviewers unaware of the drive. 28bytes (talk) 11:46, 27 November 2010 (UTC)

28bytes, regarding your first comment: again, DYK has made it through plenty of holiday seasons already without getting killed and without quid pro quo, so I don't think the holidays make its implementation extra-urgent. rʨanaɢ (talk) 12:03, 27 November 2010 (UTC)

Fair enough. So what do we want to do here, December 8? January 1? 28bytes (talk) 12:19, 27 November 2010 (UTC)

I'd like to see it up at least a couple of weeks. We don't want to spring this unexpectedly on people, we may want to give them some time to review the process and get used to the idea. Gatoclass (talk) 13:06, 27 November 2010 (UTC)

PFHLai suggested January 1, so in the interest of picking some date, I'll second that. 28bytes (talk) 19:41, 27 November 2010 (UTC)

Any date is good for me, I'm already QPQing myself as it is - I should probably start doing it for non-self-noms as well. As for cutting back to three updates a day, if it's thought to be necessary, I won't oppose it. - The Bushranger _{Return fire}^{Flank speed} 21:13, 27 November 2010 (UTC)

Can a nominator point to a review which they did long ago and apply it to satisfy the QPQ requirement when making a current nomination, or "bank" reviews to "redeem" towards future nominations? Or does the review have to be of a current or very recent hook? One way or the other, this should be spelled out. Agolib 00:11, 28 November 2010 (UTC)

You can't use an old review, the review should be done after the nomination. Doing it any other way would make it too hard to keep track. Gatoclass (talk) 05:00, 28 November 2010 (UTC)

Hook replaced

I have returned the hook related to the article Mao's Great Famine: The History of China's Most Devastating Catastrophe, 1958-62 to T:TDYK as in my view the article is clearly POV and needs work, apart from the fact that most of it is uncited. Gatoclass (talk) 14:22, 27 November 2010 (UTC)

Drawing a hard line?

Boo. I...am not a fan of reviewing nominations. Can you indicate some other thing? PR for example? DYK checking is source checking, and I find that boring =|. ResMar 05:18, 27 November 2010 (UTC)

Wow. It takes a minute, maybe two, to review a hook? The purpose of DYK tit-for-tat is to increase the number of DYK reviews, so just force yourself to do it if you want to nominate an article. Ed ^{[talk] [majestic titan]} 05:32, 27 November 2010 (UTC)

I've tried it in the past, but I just don't feel confident, when reviewing a hook, that everything is really ok, especially nowadays with so many rules applying to DYK. I think I prefer to just simply stop nominating! Calistemon (talk) 05:54, 27 November 2010 (UTC)

If you know how to submit an eligible article, you know how to review one. In any case, confidence comes with experience, after you've done a couple it won't seem like such a big deal. Gatoclass (talk) 06:00, 27 November 2010 (UTC)

If editors are inexperienced in reviewing but have more than 5 DYK credits and so come under the new QPQ rule, I would have no problem with them conducting a review, marking it as provisional, and then asking here for it to be checked by a more experienced reviewer. This check would include helping them to recognise any issues which they might have missed. There will also (hopefully) soon be a guide to reviewing to assist. There is no shame in being inexperienced at reviewing, nor in asking for help and a second opinion; indeed, working together and mentoring new reviewers is very much the wiki way. EdChem (talk) 06:32, 27 November 2010 (UTC)

I agree... especially at first, if a reviewer makes a good-faith effort at reviewing a hook but needs/wants a second opinion from a regular reviewer, I'm fine counting that as their "review". 28bytes (talk) 08:06, 27 November 2010 (UTC)

Despite WP:BEANS, I have to say this: I am concerned that [1] those who want to get out of reviewing noms would avoid self-nom'ing by asking a friend to nom (and later scratch back by nom'ing an article by this friend), [2] some people would use sock-puppets to self-nom without appearing to have self-nom'ed, and [3] reluctant reviewers frequently doing a sloppy job (maybe hoping others would tell them to stop reviewing...). So I'd suggest including [A] non-self-noms, and [B] some incentives to attract willing reviewers, perhaps a medal for every 50 reviews that do not result in any complaints on Talk:MainPage, WP:ERRORS, WT:DYK or angry edit summaries on T:DYK. Hope this helps. Cheers! --PFHLai (talk) 06:50, 27 November 2010 (UTC)

I'm not too worried about about that. I mean, there's nothing right now to stop a pair of buddies from nomming and approving each others' hooks. If people start abusing this, those of us who move hooks to prep will notice and call them on it. I've had to veto a couple of weak "reviews" this week that had nothing to do with the quid-pro-quo. We (those who move to prep, and the DYK community in general) just have to keep an eye out for that sort of thing. 28bytes (talk) 08:13, 27 November 2010 (UTC)

Except that now it's advertized, rather than discouraged, in shiny toxic yellow. East of Borschov 10:20, 27 November 2010 (UTC)

I think, we should assume that most editors are honest people and wouldn't try to trick the system. For my part, I have tried reviewing a few times before but never saved the the review because I just wasn't convinced I did everything right. Also, keep in mind, most people will only nominate an article occassionally, therfore only few an article occassionally, in the new system, and never really get all that skilled in reviewing. Calistemon (talk) 10:52, 27 November 2010 (UTC)

I agree that we should assume the nominators will be honest. (I mean, really, is reviewing one hook so much of a burden that it's worth setting up a sock account or roping in another editor to game the system?) And even if only half of the nominators are honest and the rest skip out somehow that's still a huge help in easing the reviewing burden. 28bytes (talk) 11:13, 27 November 2010 (UTC)

As a multi-nominator, I would say, set up a list of reviewers that are willing to guide us inexperienced have-to-be reviewers and we should go from there. The system you are trying to implement is fair enough but has its techincal difficutlies, and that would eliminate one of them. Calistemon (talk) 11:18, 27 November 2010 (UTC)

I think that's an excellent idea. 28bytes (talk) 11:23, 27 November 2010 (UTC)

I don't see the point in that. We already have lists of active DYKers, I don't see why we should need a second list of potential "helpers". All the regulars already help however they can. If you're unsure you did a review right, all you need do is post a message here and someone will look over it for you. Gatoclass (talk) 13:02, 27 November 2010 (UTC)

Option #4. A group of wp:pointy reviewers (or a single person if they have a few hours to spend every day) can monopolize reviewing and practically close the door for any outside nominators. It would not take much effort: the inflow of hooks will trickle down quite quickly. A few days, no more DYK. Q.E.D. East of Borschov 23:08, 27 November 2010 (UTC)

Clearly, we'll have to have a WP:IAR that says if there's no hooks to review, you can go ahead and post your submission anyway... - The Bushranger _{Return fire}^{Flank speed}

Wow, that was negative. I love the award idea-couldn't help but roll my eyes, there. ResMar 16:25, 28 November 2010 (UTC)

How would the timing work?

I recently worked on expanding the article banana powder, which is at AfD here. It's quite obvious that it will close as Keep and I wish to submit it to DYK (since it meets both the New and the Fivefold expansion requirements), but I cannot do so until the AfD is over. So I am a bit concerned about the timing of when to submit it, especially when I might be gone for a couple of days this week. What should I do? Silverseren^C 19:08, 28 November 2010 (UTC)

Go ahead and submit it; it can't be approved until the AfD is closed but there's no reason not to submit it if it's likely to be kept. 28bytes (talk) 19:38, 28 November 2010 (UTC)

Margrethe Munthe, another bad call

How anyone could have believed this article was ready to be featured on the main page is beyond me. It's a terrible article that makes little sense due to so much of it not being in English with no translation provided. This is not the type of content we should be showcasing as our best new work. Beeblebrox (talk) 00:09, 28 November 2010 (UTC)

Thank you for commenting on the article on Margrethe Munthe. I have made a few improvements, although probably not addressing your main objections. On the criticism of her songs I have merely cited from the sources, without including WP:OR. Here is my simple OR though: Her "moralizing" songs are of the kind "DO as you have been told, BASTA", with contents such as "Don't forget to take off your cap when you go inside", "When the school bell rings, we happily run to line up two by two", and similar. The old view on bringing up children through authoritarian methods has been abandoned over the years, therefore the criticism. Oceanh (talk) 23:40, 29 November 2010 (UTC)

This is another article from an editor that I raised concerns about close paraphrasing in a hook for Ferdinand Finne a few days ago, with the hook being withdrawn. This one seems okay at first glance in terms of paraphrasing (for the online sources anyway), but their contributions probably need a closer look by someone with some time. Camw (talk) 07:14, 28 November 2010 (UTC)

It surprises me that an admin brings up vague but serious accusations of this kind, without checking diffs to verify which editor included the closely paraphrased translations into the other article. Making one diff takes no time at all, and admins are supposed to know how and when to do so. Oceanh (talk) 23:40, 29 November 2010 (UTC)

DYKSTATS

With the shifting-around to meet backlog demands, DYKSTATS is becoming increasingly subjective; some hooks in the pressure periods that could have otherwise hit the amount don't. Out of interest, maybe we should add a column for "time spent on the Main Page"? ResMar 02:55, 29 November 2010 (UTC)

Gatoclass proposed this once, but somehow this went nowhere. There are many other important factors, such as day (holiday or not) and even time of the day. Number of views is not directly proportional to time spent in the MP. Materialscientist (talk) 03:01, 29 November 2010 (UTC)

To give an idea, Main Page traffic usually drops 15–20% over the weekend. Add into that that several hooks are timed to appear in the time zone when they are thought to attract most interest – the implication being that their 24-hour hit rate wouldn't be four times their six-hour hit rate. I've no firm statistics for the variation on Main Page hits during the day, but some DYK sets always get fewer hits than others... Finally, there is the "current event" bias: two out of the top three hooks on DYKSTATS featured events that were the subject of media coverage while they were posted, but which had been refused by ITN. For me, the best ever DYK hook remains the blind special forces soldier! Physchim62 (talk) 03:09, 29 November 2010 (UTC)

..which stayed for extra-long 12 hours on the MP. With some (current events) hooks, it is also hard to understand which views came from DYK and which from Google. Materialscientist (talk) 03:19, 29 November 2010 (UTC)

I'm not sure how "time spent on the main page" would hake a difference for DYKstats. The bot is automated, so the vast majority of hooks stay on the main page for the same amount of time. The ones that get removed early are outliers. I don't see how this information would be interesting. rʨanaɢ (talk) 03:51, 29 November 2010 (UTC)

What we could do is add an additional column showing hits per hour and then sort the table according to that. As matsci pointed out, the total time that hooks have remained on the front page has varied widely through the history of this project; hooks have been displayed for as little as four hours and as long as 12, 16 or even more. Listing the table by total hits leads to some very misleading results. Gatoclass (talk) 05:21, 29 November 2010 (UTC)

Indeed; I was a little surprised when Cobb Seamount hit 6.9k, for example. In addition, the counting tool itself is fairly unstable, and sometimes misses high hitters entirely because of missing info dumps (Tony brought this up on the Signpost, before). ResMar 21:26, 29 November 2010 (UTC)

How to make DYK useful

Just read a provacative blog, discussing changing DYK to make it more useful. I really grok the guy's main point that a lot of the current DYKs seem to be obscure and even unintersting. Why not do what he says?

http://onwikipedia.blogspot.com/2010/03/how-to-make-dyk-useful.html

TCO (talk) 07:13, 29 November 2010 (UTC)

TCO, you might not be aware but DYK has had a lot thrown at us recently, plus looooong discussions such as Wikipedia talk:Did you know/Archive 61#Changing DYK and the above Wikipedia talk:Did you know#Testing ideas thread. We are presently implementing two ideas - the expansion of DYK to include newly-sourced BLPs to help with the backlog of unsourced BLPs, a significant problem for the project, and a quid pro quo system of reviewing for those with more than 5 DYK credits. A guideline to assist in reviewing is also being written. Other changes are in discussion. Uninteresting, as you will see from these discussions, is a constant problem because it is spectacularly subjective. I have yet to read the suggestions from that blog, I just thought you should be aware of the background. PS: We also lost our most productive and prolific administrator, which has made our queues go from always full to nearly empty. EdChem (talk) 08:43, 29 November 2010 (UTC) PPS: None of this is to say we aren't interested in suggestions, because we are... and feedback is welcome, constructive feedback and suggestions are particularly valuable. However, some of us are feeling more than a little tender at the moment, so please understand that I for one approach the prospect of another discussion of all our faults with some trepidation. EdChem (talk) 08:49, 29 November 2010 (UTC)

It's cool. Honest, I just read it. I know you are getting gruntwork done and I'm being "meta". Was sort of wondering in a way if this was similar to the issue of us having FAs that tend to be on obscure topics, while "core" topics very often have unsat articles. and yes, it's a matter of subjective evaluation, but it's common enough that it's valid. I don't think you'lll find many who actively dispute it, from their subjective view. And a few minutes later I saw the BLP hooha on that blog. Honest. Not raising that. But, I did really like the guys essay. He just wants to take some of your "slots" away and formalize them for use on other parts of the project. and I have no idea all the background and didn't mean to upset anyone. Honest. I'm just rampaging around. TCO (talk) 08:55, 29 November 2010 (UTC)

TCO, truly, I did not mean to imply you had done anything wrong, and it is useful for us to be aware of comment about the project. The idea of devoting some DYK slots to GA, for example, is something that appears in the earlier discussions. I just thought the background to any new discussion is worth noting. Thanks for stopping by, and I hope you will continue to contribute. :) EdChem (talk) 09:02, 29 November 2010 (UTC)

The reason no one writes FAs on core topics is pretty simple: these are huge, huge undertakings. It's no different for DYK; that's why things like Zona Rosa and Guanajuato, Guanajuato should be commemorated (and Thelmadatter, be declared obsessed ;). ResMar 21:33, 29 November 2010 (UTC)

No Queue lined up

There is currently no queue lined up to run at 12:00 UTC. Is is simply a question of copying the prep to the queue, or is it much more complicated than that (I suspect the latter, in which case I need a step-by-step idiot's guide on how to do it). Mjroots (talk) 09:49, 29 November 2010 (UTC)

The task is more complicated than a simple copy, but not too bad. Here are the steps I usually go through:

1. Scan the prepared update for obvious problems (vandalism or POV is inserted on rare occasion after the update was prepared). Fix as needed.
2. Replace the {{User:DYKUpdateBot/REMOVE THIS LINE}} at the top of the queue with {{DYKbotdo|~~~}}. If you would prefer minimize comments on your talk page regarding the update then {{DYKbotdo|[[WP:Did you know|The DYK project]] ([[T:TDYK|nominate]])}} will also work.
3. Copy the complete text from the prep page under the {{DYKbotdo}}.
4. Check the image for correct size (100x100px) and remove any positioning information ("|right", ...). See Wikipedia:Did you know#Images for full image format information.
5. Preview the update. Look for any obvious formatting issues that may have crept through. Also check the credits section for redlinks. Fix any articles names displaying as redlinks in the credits section (this is usually caused by simple misspellings) and check any user names with redlinks to insure the user exists (some are misspellings while others are users without userpages).
6. Save the updated queue entry.
7. Clear the prep area. This may be done by either copying Template:Did you know/Clear to the prep area or searching through the file's history for a recent cleared page.
8. Increment Template:Did you know/Queue/NextPrep to show next prep area to be used.
9. Protect the update image as you would any other image going to the Main page. See Wikipedia:Did you know/Guide#Pictures for various methods of accomplishing this task.

I would also recommend you watchlist User:DYKUpdateBot/Errors. The DYK bot is able to detect most common errors and reports what needs to be fixed to this file. --Allen3 ^talk 12:18, 29 November 2010 (UTC)

Queue 5

I think the word "which" in the last hook of Queue 5 is superfluous. Schwede66 23:41, 29 November 2010 (UTC)

Removing "which" breaks grammar, i.e. it can be removed with a tweak of "was an", but why? Materialscientist (talk) 23:45, 29 November 2010 (UTC)

I think to break up the run-on sentence, even I thought it looked a little awkward. "...in 1940, using..." could work? - The Bushranger _{Return fire}^{Flank speed} 23:57, 29 November 2010 (UTC)

Looks good now. Thanks! Schwede66 01:04, 30 November 2010 (UTC)

Including Newly Sourced BLPs at DYK

Following on from the supportive discussion of including unsourced BLPs at DYK, and the comment of 28bytes, I propose the following rule changes:

On WP:DYK, under DYK Rules...

• Change second sentence to read "DYK is only for articles that have been created, or expanded fivefold or more, or newly-sourced BLPs that have been expanded at least twofold within the last 5 days."
• Under selection criteria, add as third dot point "Former unsourced BLPs which have been thoroughly sourced and in which the prose portion has been expanded twofold or more within the last five days are also acceptable as "new" articles. The content with which the article has been expanded must be new content, not text copied from other articles."

On WP:DYKAR...

• Add to rule A4: "Twofold expansion for newly-sourced BLPs similarly means from the version prior to the expansion and addition of sources."
• Add to rule D8: "For newly-sourced BLPs, the five days starts with the first edit adding new content or references."
• Add to rule D12: "For newly-sourced BLPs that have been two-fold expanded, thorough sourcing of the article is expected."

On WP:Did you know/Onepage...

• Change nomination rule 1 to read "The first priority is to understand that the article must be new, because newness can't be fixed later. To make a long story short: At least 80% of the article must be new (five days old or less) when the article is nominated, or it must be a newly-sourced BLP that is at least 50% new content."
• Citation requirements, rule D2, add "Newly sourced BLPs are expected to be thoroughly sourced."
• Rename rules M4 and M5 to be M5 and M6, and add a new rule M4: "For purposes of DYK, 50% new is sufficient to be considered "new" in a newly sourced BLP; this reduced requirement recognises the time and effort involved in thoroughly sourcing an existing unsourced BLP. Adding enough new material to make an article 50% new is called a twofold expansion, because one-half is 50%."
• Does a section similar to Fivefold expansion need to be written?

Are there any other changes required? Could we add a new status to the DYK nomination template, such as: {{subst:NewDYKnom| article= | hook=... that ? | status=blp | author= }}? Thoughts? EdChem (talk) 13:03, 27 November 2010 (UTC)

• Looks good to me. Re the Fivefold expansion section, I think a new "F7" there noting to substitute "two" for "five" when considering newly-sourced BLPs would be sufficient. 28bytes (talk) 19:35, 27 November 2010 (UTC)

• Those all sound good to me, and I also strongly support the status being added to the nom template. - The Bushranger _{Return fire}^{Flank speed} 21:12, 27 November 2010 (UTC)

• DYK is complicated enough for new users, and adding additional rules is not the answer. Ed ^{[talk] [majestic titan]} 03:32, 28 November 2010 (UTC)

• Ed, we are talking about implementing a new acceptance criterion that has achieved consensus. If you can suggest a way to go about that implementation that also simplifies the rules, I would be thrilled to consider it. However, failing that, our options are to introduce new rules to cover newly-sourced BLPs, or continue the present practice of rejecting them completely. Personally, I am strongly in favour of supporting efforts to deal with the backlog of unsourced BLPs. EdChem (talk) 07:02, 28 November 2010 (UTC)

• Ah, apologies, I didn't realize this had reached consensus before. I'm obviously in the minority, so carry on :-) Ed ^{[talk] [majestic titan]} 07:40, 28 November 2010 (UTC)

• No problem. FYI, the discussion is here, and follows on from the now-archived Wikipedia talk:Did you know/Archive 61#DYK as a possible part the sourcing of BLP drive. EdChem (talk) 07:58, 28 November 2010 (UTC)

• I found the first one before and saw almost unanimous support – that's how I know I am in the minority! Good luck and I hope this change, in whatever form it takes, turns out well. Ed ^{[talk] [majestic titan]} 08:05, 28 November 2010 (UTC)

• Idea and intent seem good. I support going ahead with the proposed rule changes. Camw (talk) 07:22, 28 November 2010 (UTC)

 Done rule changes implemented. EdChem (talk) 04:56, 4 December 2010 (UTC)

Wikipedia:DYKSTATS

Would anybody object if i moved this page to WP:Did you know statistics or WP:Did you know/Statistic? This is to make it in line with the rest of the pages in this project. Simply south (talk) 03:03, 28 November 2010 (UTC)

I would object. But only because a statistic is a single number. So, moving it to WP:Did you know/Statistics would be ok.  :) EdChem (talk) 06:59, 28 November 2010 (UTC)

Ahh, the amazing wonders of typos! Simply south (talk) 14:58, 28 November 2010 (UTC)

If no one properly objects by this Friday, i'll move it. Simply south (talk) 11:12, 29 November 2010 (UTC)

It is done. Simply south (talk) 23:16, 3 December 2010 (UTC)

Queue 3

The lead hook is way in excess of 200 characters. Schwede66 18:14, 3 December 2010 (UTC)

• True, but the "(pictured)" doesn't count. It could be shortened by calling him W.W. Talcott instead of William Wilson Talcott. Cbl62 (talk) 18:19, 3 December 2010 (UTC)
  • If it must be shortened, this would bring it under 200 characters: ... that ice cream manufacturer W. W. Talcott (pictured) jumped to his death from an excursion steamer into Lake Michigan with rocks in his pockets after failing to extricate his wife from a "love cult" in 1922? Cbl62 (talk) 18:25, 3 December 2010 (UTC)

Accepting Newly-Sourced BLPs

I have made the changes agreed to in the discussions above, so we can now all expect to see some nominations under this category. The requirements for these articles are:

• must start from unsourced within the last five days; typically these articles can be found in CAT:BLP
• must be two-fold expanded and above 1500 readable characters
• must be thoroughly sourced – this is a subjective standard, but there is discretion for rejecting nominations with poor referencing, especially if references for significant facts about the person are missing. One or two references makes an article no longer unreferenced; it doesn't make an article main page worthy.
• must satisfy all usual requirements about the hook – watching for unduly negative or uninteresting hooks is particularly important here

I will be posting notices about the new DYK rules at appropriate noticeboards. Please, help to spread the word; I see this as DYK contributing to the drive to eliminate the unsourced BLP backlog, so we want the news of the rule change to be spread widely.
On a related issue, it would be very helpful if someone who knows how templates work could modify the nomination template to have a new status other than "new" and "expanded" – perhaps a status=newblp option (or similar)? I looked at the template and am nowhere near skilled enough to attempt such a change. Thanks. EdChem (talk) 05:10, 4 December 2010 (UTC)

• I love this change. As for the template, that thing is the most complicated template I have ever seen. /ƒETCHCOMMS/ 19:57, 4 December 2010 (UTC)

BWV 70

The hook about BWV 70, now in prep 4, "... that performance of Bach's cantata Wachet! betet! betet! wachet! for Advent was acceptable in Weimar but not in Leipzig, because Leipzig didn't allow music during Advent?" is not precise, because music was permitted in Leipzig on the first Sunday of Advent. Suggestion: "... that performance of Bach's cantata Wachet! betet! betet! wachet!, for the Second Sunday of Advent in Weimar, was not acceptable in Leipzig during Advent?" --Gerda Arendt (talk) 16:53, 4 December 2010 (UTC)

Corrected as suggested. Materialscientist (talk) 04:15, 5 December 2010 (UTC)

Reminder: last 15 hours of voting in the ArbCom elections

Dear editors,

Now is your final chance to vote in the December 2010 elections for new members of ArbCom. Voting will close just before midnight UTC tonight, Sunday 5 December (earlier for North America: just before 4 pm west coast, 7 pm east coast). Eligible voters (check your eligibility) are encouraged to vote well before the closing time due to the risk of server lag.

Arbitrators occupy high-profile positions and perform essential and demanding roles in handling some of the most difficult and sensitive issues on the project. The following pages may be of assistance to voters: candidate statements, questions for the candidates, discussion of the candidates and personal voter guides.

• Proceed here to cast your vote. Once you have decided how to vote, casting your vote is quick and convenient, using the Foundation's software.

For the election coordinators, Tony (talk) 09:49, 5 December 2010 (UTC)

Bad hook

The item in the hook for Peter Shivute is not explained in any way in the article text. How this escaped the attention of the DYK reviewer is beyond me. Beeblebrox (talk) 03:24, 6 December 2010 (UTC)

With multi-article hooks, the hook fact does not need to be mentioned in all of the articles. You will find the information from the referenced hook in the third article, Supreme Court of Namibia. --Allen3 ^talk 03:41, 6 December 2010 (UTC)

(ec) Allen said it better than I was going to. Further. This particular hook is just a "quirky hook" and its detailed elaboration in the articles won't improve them. Materialscientist (talk) 03:46, 6 December 2010 (UTC)

I'm no expert on the ins and outs of DYK rules, but I think most readers would expect the hook to relate to the first link. I certainly did. Beeblebrox (talk) 04:07, 6 December 2010 (UTC)

Testing ideas

Due to the discussion of improving DYK functionality and quality, in the same way we recently worked out changing the order of noms by date, I think we should take Hongkongresident's excellent list and vote. In place of talking , as some of these suggestions have been tossed around for quite some time, I think we can afford to implement any or none of them. Afterwards, we can review changes and remove or try others; please add any suggestions to the vote; I think it would be best to place discussion in a separate area to keep the vote from clogging up.

UPDATE I think it would be less confusing if you only showed support below, by not supporting it is assumed that you are opposing the idea. Leave comments in subsection in order to avoid discussion within the voting area. Or don't. - Theornamentalist (talk) 02:17, 11 November 2010 (UTC)

Actually I only saw this after adding both Supports and Opposes (was it added?); but I think it is better to have both. But remove the Opposes if you like. Johnbod (talk) 02:34, 11 November 2010 (UTC)

I'm quite happy to add oppose !votes simply to oppose the idea that people cant add a short opposition, if that's what's needed. Wikipedia is not Burma, nobody is obliged to !vote yes. Physchim62 (talk) 02:42, 11 November 2010 (UTC)

I understand, I just wanted to simplify the process, and to avoid turning a vote into a discussion in the same area. However, whatever works... works. - Theornamentalist (talk) 02:47, 11 November 2010 (UTC)

OK, I understand as well (I hope). Can we just keep comments short ;) Physchim62 (talk) 02:50, 11 November 2010 (UTC)

I've broken off each proposal as a subsection, to make discussion easier. cmadler (talk) 12:53, 11 November 2010 (UTC)

NOTE Some sections have been closed (very prematurely in my view). Discussion continues on others lower down. Please do not close any more - they have only been open for 30 hours. Johnbod (talk) 14:15, 12 November 2010 (UTC)

Slowing down the output rate

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

No consensus. Gatoclass (talk) 13:06, 8 December 2010 (UTC)

---

Seems to have general consensus already. Physchim62 (talk) 02:02, 11 November 2010 (UTC)

support Johnbod (talk) 02:08, 11 November 2010 (UTC)

Comment - not an end in itself. It was only one possible means of reducing the burden on reviewers and there has been no agreement on a method of reducing the rate. Gatoclass (talk) 03:40, 11 November 2010 (UTC)

Over ten days of discussion, nobody has offered an argument as to why to why the current rate of output is Good; on the contrary, many arguments have been made as to why it is Bad. Physchim62 (talk) 04:37, 11 November 2010 (UTC)

The current rate of output is Good because it ensures that everyone who wrote an eligible article got a DYK. Reducing the rate of output is not necessarily bad, but there's been no agreement on how best to achieve this and, by my estimation at least, not much chance of establishing a consensus on a method right now. Gatoclass (talk) 06:44, 11 November 2010 (UTC)

There's no need for a Main Page slot to give out "awards" to all qualifying articles. I assume that Gatoclass will be happy if we use the DYK Main Page slot for something with more focus on our readers, rather than as the simple Smartie factory that it has obviously become, without even any respect for its own criteria and certainly none for the title "Did you know?". Physchim62 (talk) 14:12, 11 November 2010 (UTC)

Oppose - the key is to slow the input rate to allow more thorough review. This whole thing was kicked off by copyvio concerns which slower output will not address. - Dravecky (talk) 05:45, 11 November 2010 (UTC)

Support This is the cornerstone in any improvement of the project. Lampman (talk) 11:52, 11 November 2010 (UTC)

Oppose per Gatoclass and Dravecky. cmadler (talk) 12:58, 11 November 2010 (UTC)

Oppose as a driver of change, Support as a consequence. Reducing hooks displayed without other change will require arbitrary rejections, and I cannot support that. However, meaningful changes in standards and practices that have the effect of increased rejections and longer times on the main page for those hooks selected is fine as a consequential effect. EdChem (talk) 14:35, 11 November 2010 (UTC)

Oppose, per Cmadler (talk · contribs). -- Cirt (talk) 16:45, 11 November 2010 (UTC)

Oppose treats a symptom, not the disease. Haus^Talk 16:58, 11 November 2010 (UTC)

Oppose. This proposal is the same as Reducing DYK frequency below! (the number of hooks per set is very hard to change significantly) Rejecting poor-quality noms is primary, the output rate should be flexible depending on the availability of approved noms. Limiting the output will simply bloat the T:TDYK page, which is already slow to load. Materialscientist (talk) 07:04, 12 November 2010 (UTC)

It's not actually the same proposal as the DYK frequency one below. Limiting the DYK frequency would (among other things) provide a hard maximum to the number of hooks. This proposal doesn't provide any hard maximum; it merely says that the throughput should come down if there's to be additional reviewing requirements (specifically, copyvio) given that we cannot assume that the number of reviewers is going to increase significantly. Physchim62 (talk) 13:19, 12 November 2010 (UTC)

Oppose per Dravecky and Materialscientist. —Bruce1ee^talk 08:52, 12 November 2010 (UTC)

Support—"The current rate of output is Good because it ensures that everyone who wrote an eligible article got a DYK."... This is entirely unacceptable as a reason. Is this some kind of socialist welfare state? Tony (talk) 09:06, 12 November 2010 (UTC)

Um, no, that wasn't actually my reason for opposing this measure. That was just a response to a user's questioning the utility of a high rate of output. Most of these half-baked proposals have unfortunately completely missed the point, which is that the key to improving anything is to reduce the burden on reviewers - anything that doesn't take account of that is just a distraction. Gatoclass (talk) 17:55, 13 November 2010 (UTC)

Support— There should be no 'guarantee' of a slot on the main page. Qualitative criteria must come first, thus slowing down would create a bigger selection to weed out 'weak' candidates. --Ohconfucius ^¡digame! 10:21, 12 November 2010 (UTC)

Support It makes no sense to me to reserve a fixed number of slots for DYK if the pickings are slim and a slot or two have to be filled with some candidates that make many editors’ noses wrinkle a bit. Quality before quantity. Keep it flexible. If there are a number of really good candidates, then expand the quantity that day (or spread them out across two days). Greg L (talk) 18:38, 12 November 2010 (UTC)

Oppose per Dravecky and Materialscientist.4meter4 (talk) 20:24, 12 November 2010 (UTC)

Support, makes sense. SlimVirgin ^{talk|contribs} 10:58, 13 November 2010 (UTC)

Oppose and agree with EdChem, no one has any decent proposals as to how we can decrease the output rate. SmartSE (talk) 21:27, 14 November 2010 (UTC)

Support per Tony. We should be improving quality of articles and hooks by not seeing DYK as an entitlement. First Light (talk) 21:27, 16 November 2010 (UTC)

Strong oppose per Dravecky and Materialscientist. - The Bushranger _{Return fire}^{Flank speed} 00:20, 20 November 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Incorporate CorenBot to scan for plagiarism

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Consensus in favor of implementation cmadler (talk) 13:36, 12 November 2010 (UTC)

---

Fine, but how much help is it? Johnbod (talk) 02:08, 11 November 2010 (UTC)

a bit, but certainly not the only tool to be used. This is not a practical problem, everyone agrees about a bit more copyvio checking: basic copyvio training can be provided and reviewers can use the methods they see best. Physchim62 (talk) 02:25, 11 November 2010 (UTC)

Support 28bytes (talk) 02:31, 11 November 2010 (UTC)

Support - Dravecky (talk) 05:45, 11 November 2010 (UTC)

Support Lampman (talk) 11:52, 11 November 2010 (UTC)

Support, since it should help catch copyvio/plagiarism without significantly adding to the workload. cmadler (talk) 13:07, 11 November 2010 (UTC)

Comment. Just as a note, Coren has said that Corenbot must be used manually to scan articles, since the bot only checks for new articles. Also, due to TOS issues, Corenbot can't check Google Books. Either way, I still support this proposal.--hkr (talk) 13:17, 11 November 2010 (UTC)

Support as one of a suite of tools and checks. I would hate to see a CSBot tick being seen as a guarantee of no plagiarism. EdChem (talk) 14:36, 11 November 2010 (UTC)

Support, per Cmadler (talk · contribs). -- Cirt (talk) 16:45, 11 November 2010 (UTC)

Support. While it can't scan Google Books, it would certainly help elsewhere. —Bruce1ee^talk 08:54, 12 November 2010 (UTC)

I don't understand this proposal. Plagiarism is bad and any tool which fights it is good - nobody will object this (proposal). The question is technical: who and how will do that? Materialscientist (talk) 09:01, 12 November 2010 (UTC)

Support, without knowing much about the bot. Sounds good. Tony (talk) 09:03, 12 November 2010 (UTC)

Oppose— Lazy option that creates a false sense of security. Does not absolve editors from physically checking entries for thinly disguised copyvios. --Ohconfucius ^¡digame! 10:21, 12 November 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Encourage editors to manually use online plagiarism checkers

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Consensus in favor of implementation cmadler (talk) 13:45, 12 November 2010 (UTC)

---

Support Johnbod (talk) 02:08, 11 November 2010 (UTC)

simply reading the article (without a checksheet in your hand), source-checking and a judicious use of Google make a good practical substitute for this Physchim62 (talk) 02:35, 11 November 2010 (UTC)

Support 28bytes (talk) 02:31, 11 November 2010 (UTC)

Support - Dravecky (talk) 05:45, 11 November 2010 (UTC)

Comment. Other than CorenBot, there are two (maybe more?) free plagiarism checkers online that can be used. One problem is that they aren't accurate as paid services. But I still support this proposal. --hkr (talk) 13:20, 11 November 2010 (UTC)

Support. - PM800 (talk) 14:26, 11 November 2010 (UTC)

See above support comment - encouraging editors to do a range of checks is good, mandating particular checks risks the development of a "checklist" mentality which I think is anathema to what we seek to achieve. EdChem (talk) 14:37, 11 November 2010 (UTC)

Support, per Hongkongresident (talk · contribs). -- Cirt (talk) 16:46, 11 November 2010 (UTC)

Support, but we'll need a list of recommended online checkers. —Bruce1ee^talk 08:57, 12 November 2010 (UTC)

How long does a string have to be before it's an unacceptable duplication? How different does it have to be to be acceptable as paraphrasing? Tony (talk) 09:05, 12 November 2010 (UTC)

Support I do it all the time when something looks suspect. It's called Google string searches. ;-) But usually not very useful unless it is a wholescale copyvio. --Ohconfucius ^¡digame! 10:31, 12 November 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Require two reviewers per hook

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Consensus not to implement at this time. There seems to be interest in this as in the long term, but an agreement that it is not workable at present; this may be worth revisiting down the road (maybe in 6 months). cmadler (talk) 13:51, 12 November 2010 (UTC)

---

Oppose Johnbod (talk) 02:08, 11 November 2010 (UTC)

medium-term objective; additional reviewer resources should go to the borderline cases, not the ones that are clear yes/no. Physchim62 (talk) 02:46, 11 November 2010 (UTC)

Oppose - Currently impractical, and only of value if throughput was substantially reduced, and as I said above there is no consensus for doing that or for a means of doing so. Gatoclass (talk) 03:43, 11 November 2010 (UTC)

Oppose - Reviewer resources are better used for more thorough examinations of each article. Doubling the workload will work against that goal. - Dravecky (talk) 05:45, 11 November 2010 (UTC)

Oppose Probably not practicable. Lampman (talk) 11:52, 11 November 2010 (UTC)

Oppose but open to reconsidering this pending other changes. cmadler (talk) 13:23, 11 November 2010 (UTC)

Oppose. It takes long enough to get one review. - PM800 (talk) 14:26, 11 November 2010 (UTC)

Definitely not now, but encourage the thinking that moving an article to prep is taking some responsibility for judging the article and hook "DYK-ready" and "main page-worthy". We already have checking at T:TDYK, moving to prep, and promoting sets to the queue. Each step should include some level of check; none of them should be seen as purely routine and housekeeping. EdChem (talk) 14:38, 11 November 2010 (UTC)

Oppose, WP:GAN process should have higher standards — but this is not done there. -- Cirt (talk) 16:47, 11 November 2010 (UTC)

Oppose per Lampman. Nev1 (talk) 23:39, 11 November 2010 (UTC)

Comment: reduce the number of items appearing if reviewer resources are thin. Tony (talk) 08:39, 12 November 2010 (UTC)

Oppose. This would be nice, but it's not practical. —Bruce1ee^talk 08:59, 12 November 2010 (UTC)

Encourage, not require, support or object - the more the better, but we can not set a fixed limit here. The consensus seems solid for rejecting boring hooks. This automatically means more than one editor will evaluated the "boringness", so we automatically get more than one reviewer :-) Having 2 or more approvals for every single noms is not yet feasible. Materialscientist (talk) 09:05, 12 November 2010 (UTC)

Oppose - Corblimy... it's not just the hooks that need reviewing, it's the whole frigging article. --Ohconfucius ^¡digame! 10:33, 12 November 2010 (UTC)

I think you've misunderstood this one (and others? it helps to read the debate above). Johnbod (talk) 11:13, 12 November 2010 (UTC)

Sort of support. Imposing a requirement in the short run is probably impractical, but we could have a system of encouraging Two Reviewers, by not promoting single-reviewer hooks unless DYK is short of hooks. If that bedded down well enough, it could evolve into a requirement. Rd232 ^talk 12:43, 12 November 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

More transparent logs, better accountability

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Consensus in favor of implementation. cmadler (talk) 13:54, 12 November 2010 (UTC)

---

Support, not sure how helpful. Johnbod (talk) 02:11, 11 November 2010 (UTC)

Support 28bytes (talk) 02:31, 11 November 2010 (UTC)

Support, but proper implementation of this will require detailed discussions. - Dravecky (talk) 05:45, 11 November 2010 (UTC)

Support Sub-pages for each day would probably be the best solution . Lampman (talk) 11:52, 11 November 2010 (UTC)

Comment, EdChem brought this proposal up which was focused on 1) Archiving T:TDYK, 2) More detailed DYK templates on article talk pages, and 3) Double-checking for COI issues. May take a while to implement, but I support the idea.--hkr (talk) 13:25, 11 November 2010 (UTC)

Support. I've previously mentioned that I'd like to see each hook get it's own subpage, transcluded onto daily pages in a manner similar to AfD. cmadler (talk) 13:27, 11 November 2010 (UTC)

Oppose - sounds like a lot of additional red tape for very little benefit to me. If someone can come up with a low-maintenance process, it might be workable, but in any case we can only do one thing at a time and there are more important issues to deal with. Gatoclass (talk) 13:36, 11 November 2010 (UTC)

It really doesn't involve any red tape. All it requires is a change in a couple of templates and a new bot to archive T:TDYK. It may take time to get through the technical stuff, but it certainly won't be done manually.--hkr (talk) 13:53, 11 November 2010 (UTC)

Well if it can be done without creating more work for anybody, there is probably no good reason for opposing it. I would like see the system first though. Gatoclass (talk) 15:22, 11 November 2010 (UTC)

The one thing there does seem very wide consensus on is that we can do more than one thing at a time, and should. Johnbod (talk) 11:15, 12 November 2010 (UTC)

Strong support - our current records suck, but the process needs to be bot-run. Accountability need not be a scary thing. It will allow us to see where our weaknesses are, it may allow us to help editors having trouble getting used to our standards, plus we can recognise the people who contribute a lot of high quality work. EdChem (talk) 14:38, 11 November 2010 (UTC)

Comment. I'm concerned that this will just add extra bureaucracy to a Process that already has a lot of "process". It's obviously not a Bad Thing in itself, but will the supposedly better reviewing compensate for the time taken in completeing the bureaucracy? I'd suggest leaving this to one side until the excessive throughput rate has been dealt with. Physchim62 (talk) 15:46, 11 November 2010 (UTC)

Support, per Cmadler (talk · contribs). -- Cirt (talk) 16:48, 11 November 2010 (UTC)

Support Should be trivial to implement, and useful some of the time, therefore, net benefit. Sasata (talk) 07:41, 12 November 2010 (UTC)

Support, if it can be implemented without too much effort. —Bruce1ee^talk 09:01, 12 November 2010 (UTC)

Comment— logs are quite transparent enough. Its the use they are put to that is important. --Ohconfucius ^¡digame! 10:21, 12 November 2010 (UTC)

Support. A pre-requisite for various improvements. Rd232 ^talk 12:45, 12 November 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Introduce Good Articles to DYK

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

No consensus. Gatoclass (talk) 13:10, 8 December 2010 (UTC)

---

Possibly Johnbod (talk) 02:11, 11 November 2010 (UTC)

Comment - There was clearly no consensus for this in earlier discussion, and would require a radical restructuring of this project that I don't think we are ready for yet. Gatoclass (talk) 03:49, 11 November 2010 (UTC)

Actually there was clear consensus for it above. I counted something like 13/6, which should count as a supermajority. The problem is that I posted a note about it on the GA talk page, and there's been no response. This won't be possible to do without cooperation from the GA project. Lampman (talk) 11:26, 11 November 2010 (UTC)

Well there might have been a brief flurry of support for it when it was first proposed, but when discussion moved to the question of how to implement this it quickly became evident that consensus would be difficult to achieve. Gatoclass (talk) 14:14, 11 November 2010 (UTC)

Rather when participation in the discussion fell to include only DYK regulars. Obviously a discussion involving more than one project needs participation from the whole community. Lampman (talk) 16:43, 11 November 2010 (UTC)

Oppose - Does nothing to address the problems of limited resources or need for more thorough review of hooks submitted to DYK. - Dravecky (talk) 05:45, 11 November 2010 (UTC)

Oppose but open to reconsidering this in the future based on other changes. cmadler (talk) 13:32, 11 November 2010 (UTC)

Not now - we have enough to fix, and I think this is inconsistent with DYK's core business. EdChem (talk) 14:39, 11 November 2010 (UTC)

Support, would introduce a bit more high quality material to DYK here. -- Cirt (talk) 16:50, 11 November 2010 (UTC)

Support, but there's enough going on that I can accept putting off further discussion of it for a month. But, please, let's not just forget about this, or the idea of highlighting WP:CSB articles. Rd232 ^talk 17:01, 11 November 2010 (UTC)

Oppose. Per my comments in the prior lengthy discussion. Cbl62 (talk) 17:37, 11 November 2010 (UTC)

Support. There are clear advantages to this, and the only disadvantages so far explained are that it would take time and work to set up and that co-operation from the GA people is not yet arranged. --Demiurge1000 (talk) 18:37, 11 November 2010 (UTC)

Support It's a way of introducing higher-quality articles into DYK rather than slap dash material that's been thrown together in a few days. Part of the problem with "new" articles is that many are obscure and so uninteresting; with over 10,000 GAs there must be some with interesting hooks. Nev1 (talk) 23:42, 11 November 2010 (UTC)

Oppose. There are many pros and cons, and the key is: This proposal means diverting DYK reviewers to double screen GAs (surely they have to be screened for hook, MP issues, image, etc.) I vote to improve the quality of DYK reviews instead. Materialscientist (talk) 07:21, 12 November 2010 (UTC)

Oppose (for now) Initially I liked this idea, but I think some of the other changes should be tried first. If they fail to have the desired outcome (whatever that is ... higher quality submissions and more interesting hooks, I think) we can come back to this idea. Sasata (talk) 07:57, 12 November 2010 (UTC)

Support per Cirt, though I think this should wait a little bit while the other problems are worked on. This would actually give GA a purpose and give DYK more substantive content for the MP. Ed ^{[talk] [majestic titan]} 07:59, 12 November 2010 (UTC)

Support. Tony (talk) 08:36, 12 November 2010 (UTC)

Oppose, for now as per EdChem. —Bruce1ee^talk 09:07, 12 November 2010 (UTC)

Support— good way to boost quality in pretty short order. --Ohconfucius ^¡digame! 10:21, 12 November 2010 (UTC)

Support as a way to encourage improvement of the quality of articles. --Hegvald (talk) 14:25, 12 November 2010 (UTC)

Oppose for the reasons I've given in past discussions of this issue. rʨanaɢ (talk) 15:12, 12 November 2010 (UTC)

Not now - This may be a good idea in the long term, but it will not address the immediate issue of more thorough review of nominated DYK articles. Also, without some mechanism to reduce input (e.g., higher standards for DYK articles), this would result in a huge backlog at DYK. -- Black Falcon ^(talk) 18:21, 12 November 2010 (UTC)

Oppose. This suggestion is moving away from DYK's fundamental purpose which is to encourage the creation of new articles at wikipedia.4meter4 (talk) 20:29, 12 November 2010 (UTC)

Support. Enwiki adds about 1,000 articles a day compared to about 10 GAs a day — which number stands to benefit more from mainpage exposure? Also, a new GA is less likely than a new stub to suffer the quality issues which spurred this whole imbroglio. I haven't seen any arguments on this page to support the idea that many new editors use DYK as a springboard for a prolific editing career. Haus^Talk 22:12, 12 November 2010 (UTC)

Oppose mainly due to the decreased space for non GAs - without decreasing them, there's no way these will fit! I'd like to see GAs on the main page, but don't think this is the place to discuss it. SmartSE (talk) 00:37, 13 November 2010 (UTC)

Support - GAs are usually "fresh content" anyway, which is essentially the point of DYK. Technical rules about what counts as the necessary ratio for a DYK-able "expansion", or how many days old an article is before it is no longer "new", may not be met by recent GAs. However, those rules are clearly there as a method of identifying fresh content, and the definition of "fresh" isn't necessarily limited to the rules as they stand at the moment. DYK has suffered problems with reviewing, and at least GAN means that a fairly thorough review should already have occurred. Workload and project cultures may differ between GA and DYK; whether this proposal can be made to work, depends a lot on how effectively the two processes can be integrated. There was discussion above that suggested that a good structure for integration can be designed. TheGrappler (talk) 02:04, 16 November 2010 (UTC)

I have always been an opponent of bringing GAs to DYK, but you do raise a good point about GAs being (usually) mostly new content. I think there's something worth thinking about there. rʨanaɢ (talk) 02:26, 16 November 2010 (UTC)

I wonder if, rather than "newly promoted GAs", we could restrict it to "recently written, newly promoted GAs". That would allay many of the concerns expressed in this section, all it needs is a good definition of "recently written". New GAs are usually either new articles or rewritten/expanded old articles. "In the fortnight before being submitted for GA review, the article was either (a) created, (b) greatly expanded, or (c) extensively rewritten" might work, particularly if (b) and (c) could be pinned down more precisely. "At least 50% new or rewritten content" from looking at the diffs might roughly do. I wonder if there is an automated tool that can give a quantitiative rather than qualitative evaluation of the size of the difference between revisions? That would allow "sufficiently big rewrites" to be identified systematically... but to be honest, it's usually self-evident on eyeball inspection, and even if this is objected to, "brand new or 5-fold expansion before GAN submission" would obviously be workable criteria. TheGrappler (talk) 21:05, 16 November 2010 (UTC)

Support - I think this would be an excellent way of encouraging more GA writing and reviewing. ·Maunus·ƛ· 02:31, 16 November 2010 (UTC)

Support - Definitely help improve DYK quality as above. Derild4921☼ 02:39, 16 November 2010 (UTC)

Support This seems like a good idea. Not every editor is in to starting their own article from scratch, and many are probably more interested in improving existing ones, so this would be an excellent way to increase participation in DYK. WTF? (talk) 04:51, 16 November 2010 (UTC)

That is irrelevant; DYK does not require that editor start new articles from scratch (see the rules regarding 5x expansion). Please familiarize yourself with DYK before voting. rʨanaɢ (talk) 15:20, 16 November 2010 (UTC)

IMHO, I think what WTF is referring to is that sometimes articles are already expanded quite a bit and 5x expansion is very hard, in which case reaching GA is easier. Just what I think. Derild4921☼ 22:29, 16 November 2010 (UTC)

Support The main page should include GAs somewhere. Combining them with the DYK hooks makes the most sense to me. First Light (talk) 21:28, 16 November 2010 (UTC)

Support This is the logical step, it seems to me. We could reduce DYK output (which is necessary to improve quality) while maintaining a reasonably high turnover. At the same time it would provide well-earned exposure for the GA project. Lampman (talk) 22:29, 18 November 2010 (UTC)

Oppose - We need to improve the DYK process, adding yet more potential candidates to the existing creaking process will not solve the problems, they will still need to be checked. Mikenorton (talk) 22:37, 18 November 2010 (UTC)

Support - Takes some pressure off DYK, adds some encouragement to the GA process and improves quality of articles linked from main page. An all round winner imho. Regards, SunCreator ^(talk) 01:12, 19 November 2010 (UTC)

Support: looks like a good idea, as noted in above comments; the proposal is to implement this and see if it is any good, so let's see. —innotata 00:08, 20 November 2010 (UTC)

Support - The Bushranger _{Return fire}^{Flank speed} 00:21, 20 November 2010 (UTC)

Support Ummm... why not? WikiCopter (radio • sorties • images • lost • defense • attack) 20:32, 20 November 2010 (UTC)

Oppose. Doesn't address the problem. Additionally, last time I checked, GAs are still only reviewed by one person. Wikipedia is a work in progress and that is the point of DYK. If you want to put higher quality content on the main page then maybe we'd use featured lists and A-class articles here, but that isn't the point. All this will do is hammer the main page with music and TV which account for around one fifth of GAs (at a very quick estimate). Rambo's Revenge (talk) 20:55, 20 November 2010 (UTC)

Oppose. This would undermine the value of DYK for encouraging the development of new content that crosses a minimum threshold for quality and quantity. Also, I agree with Mikenorton that it would increase the load on the DYK review process, which (IMO) is a valuable QA review process that focuses more on substance and less on form than the GA process does. --Orlady (talk) 21:28, 20 November 2010 (UTC)

Strong support. Able to display articles that are of better quality and for a longer time on the main page. OhanaUnited^{Talk page} 18:28, 22 November 2010 (UTC)

Oppose Spend the time to get it to feature it or you don't get on the main page. Have a larger group like the FA reviewers do it or you'll likely not solve any of the problems since GA has a single reviewer. Royalbroil 01:08, 28 November 2010 (UTC)

Support Encourages the progression of Wikipedia as a whole and should help to improve content. And as more and more articles are created, the hooks are going to become more obscure under current methods. Brad78 (talk) 01:24, 2 December 2010 (UTC)

Oppose I would be willing to have a lower "Five fold expansion" threshold (maybe 3x expansion) that could take in some GA under its umbrella (likely submitted before GA approval was granted since we should still keep the 5 day rule). But there is no reason that merely being a GA alone should get it on the main page. Agne^Cheese/^Wine 20:24, 4 December 2010 (UTC)

Oppose I've always felt that DYK is an outstanding incubator to encourage people to pick up stubs and develop them or to write new articles; the GA process has the same amount of reviewers as DYK does (one), and I'm not sure if this is the best route to go if we're going to feature quality content on the main page. Nomader ^(Talk) 08:53, 8 December 2010 (UTC)

Oppose. If a GA is created as a result of expanding an existing article, it already qualifies for DYK, and the single-reviewer for promotion is troublesome as well. howcheng {chat} 09:14, 8 December 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Abandon the "new article" concept

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Proposal failed. Gatoclass (talk) 13:13, 8 December 2010 (UTC)

---

Oppose Johnbod (talk) 02:11, 11 November 2010 (UTC)

equivalent to abandoning DYK completely; not a subject for this talk page. Physchim62 (talk) 02:48, 11 November 2010 (UTC)

Comment - related to the GA question above, and my response is similar to that one. Gatoclass (talk) 03:51, 11 November 2010 (UTC)

Oppose - The consensus is strongly against this and would radically alter a fundamental purpose of the project. - Dravecky (talk) 05:45, 11 November 2010 (UTC)

Oppose cmadler (talk) 13:37, 11 November 2010 (UTC)

Oppose. - PM800 (talk) 14:26, 11 November 2010 (UTC)

Oppose - dreadful idea, and as Physchim62 notes, not something that could or should be decided here. EdChem (talk) 14:40, 11 November 2010 (UTC)

Oppose, per EdChem (talk · contribs). -- Cirt (talk) 16:50, 11 November 2010 (UTC)

Oppose. Cbl62 (talk) 17:35, 11 November 2010 (UTC)

Support—Well, if you can find enough good hooks from new articles, fine. But I see no evidence of this. Convince me new articles provide a big enough flow of opportunities. Tony (talk) 08:35, 12 November 2010 (UTC)

Oppose, as per Dravecky. —Bruce1ee^talk 09:08, 12 November 2010 (UTC)

Support— anything to widen the pool to dilute weak candidates must be a good idea. --Ohconfucius ^¡digame! 10:21, 12 November 2010 (UTC)

• I'm not quite sure what this means. I would agree that the concept that DYK=new articles should be abandoned; DYK is a tool for showcasing content and providing interesting facts to readers. Pointing the tool solely at new articles is arbitrary, as evidenced by permitting 5x expanded articles. So, formally abandon the concept, and be open to including other sources of content into the DYK Main Page setup - but without abandoning the idea that some DYK hooks come from new articles. Rd232 ^talk 12:32, 12 November 2010 (UTC)

Support. This lies at the heart of the problem. People creating new articles, no matter the quality, to get DYKs, which then have to be rushed because they're only accepted within a certain timeframe. It reduces the quality of both new creations and DYKs. SlimVirgin ^{talk|contribs} 11:02, 13 November 2010 (UTC)

• "Fresh content" is perhaps a better description than "new articles" - it already isn't that, as it's certainly "new and recently expanded articles". Strangely, an article can get a complete rewrite and referencing, but fail to qualify under either of those headings, despite being essentially a brand new article! Is it really such a big leap of faith to go from "new and recently expanded" to "new and recently improved" (e.g. by incorporation of recent GAs)? I think the principle is still the same: displaying fresh content, of a certain quality, and hopefully drawing in new editors to do so. TheGrappler (talk) 01:55, 16 November 2010 (UTC)

Oppose The idea of encouraging new articles, or greatly expanding stubs, is a good one. First Light (talk) 21:29, 16 November 2010 (UTC)

Oppose per above comments; DYK is a great idea for promoting new content, and new content seems the most suitable place to find odd facts for the main page. —innotata 00:12, 20 November 2010 (UTC)

Strong oppose - although TheGrappler's comment bears considering. - The Bushranger _{Return fire}^{Flank speed} 00:22, 20 November 2010 (UTC)

Oppose Believe it or not, there's still a lot of redlinks out there that could be turned into interesting articles, and DYK encourages that. Simon Burchell (talk) 18:35, 20 November 2010 (UTC)

Oppose as worded but I am open to TheGrappler's "Fresh Content" concept that would be more flexible to expansion. I think we need to move beyond the hard and fast 5x prose expansion as the only sign of "new content" being produced. Agne^Cheese/^Wine 20:31, 4 December 2010 (UTC)

Oppose DYK is a fantastic way to promote new content in the encyclopedia, and this is one of the best ways to encourage new article creation. Nomader ^(Talk) 08:56, 8 December 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Abandon or increase the time limit criteria

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Proposal failed. Gatoclass (talk) 13:15, 8 December 2010 (UTC)

---

Oppose Johnbod (talk) 02:11, 11 November 2010 (UTC)

equivalent to abandoning DYK completely; not a subject for this talk page. Physchim62 (talk) 02:48, 11 November 2010 (UTC)

Oppose - There is already some wiggle room for hooks nominated on day 6 or intended for a specific significant date in the future so any increase would only serve to make more articles eligible, increasing workload for little tangible benefit. - Dravecky (talk) 05:45, 11 November 2010 (UTC)

Oppose per Dravecky, this would take us in the opposite direction from where we need to go. cmadler (talk) 13:38, 11 November 2010 (UTC)

Oppose - unDYKian. EdChem (talk) 14:40, 11 November 2010 (UTC)

Oppose, per Dravecky (talk · contribs). -- Cirt (talk) 16:51, 11 November 2010 (UTC)

Oppose per Dravecky. Cbl62 (talk) 17:34, 11 November 2010 (UTC)

Oppose, as per Dravecky. —Bruce1ee^talk 09:10, 12 November 2010 (UTC)

Support— It's hard (but not impossible) to create an article of any quality in five days. --Ohconfucius ^¡digame! 10:21, 12 November 2010 (UTC)

Oppose. For "new articles", 5 days seems fine. See my comment above though - we should be open to adding other content sources to DYK than new articles. Rd232 ^talk 12:38, 12 November 2010 (UTC)

Support. We're encouraging people to highlight articles on the main page that they've spent almost no time working on. SlimVirgin ^{talk|contribs} 11:04, 13 November 2010 (UTC)

Oppose per Dravecky.4meter4 (talk) 22:19, 13 November 2010 (UTC)

Oppose. Articles should have been worked on (sandbox, user space - in unlimited time) before they appear. From then on, 5 days is fine. --Gerda Arendt (talk) 22:38, 13 November 2010 (UTC)

Oppose drafts in user space allow for taking as long as you like already. SmartSE (talk) 21:25, 14 November 2010 (UTC)

Oppose per Physchim62 (and Smartse). —innotata 00:13, 20 November 2010 (UTC)

Oppose per Psychim62 and SmartSE. - The Bushranger _{Return fire}^{Flank speed} 00:23, 20 November 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Reject boring hooks

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

No consensus, leaning oppose. Gatoclass (talk) 13:19, 8 December 2010 (UTC)

---

Support Johnbod (talk) 02:11, 11 November 2010 (UTC)

this is simply requiring that the current DYK criteria be respected. Physchim62 (talk) 03:08, 11 November 2010 (UTC)

Support, in that this is already in the DYK criteria. Crafting an excellent hook is not the same skill as writing a quality article so experienced reviewers are a vital link in this process. - Dravecky (talk) 05:45, 11 November 2010 (UTC)

Oppose - subjective, time-consuming, and really like many of the other proposals in this section, too lacking in specifics. Gatoclass (talk) 06:54, 11 November 2010 (UTC)

There's no lack of specifics here: Johnbod and I have outlined a system that would work fairly and with little extra reviewer time. The fact is that rejecting boring hooks is already in the DYK criteria, so DYK has to have a method to do it, otherwise it doesn't deserve the title "Did you know?" (or its Main Page slot). Physchim62 (talk) 14:17, 11 November 2010 (UTC)

Please supply a link to discussion of your "system that would fairly work". Gatoclass (talk) 12:40, 12 November 2010 (UTC)

My version is discussed here, Johnbod's version is discussed here Physchim62 (talk) 22:19, 12 November 2010 (UTC)

So which version are we voting for, yours, Johnbod's, or somebody else's? It just reinforces my point - this proposal is far too vague. Gatoclass (talk) 20:17, 13 November 2010 (UTC)

Oppose As GC says, too vague. Lampman (talk) 11:52, 11 November 2010 (UTC)

Support in principle, but I'm not sure how this would be implemented fairly. cmadler (talk) 13:40, 11 November 2010 (UTC)

Comment. Articles shouldn't be rejected for boring hooks, although the "interesting-ness" of an article could be a topic of discussion in reviews. That, along with the subjectivity issues lead me to oppose this proposal.--hkr (talk) 13:46, 11 November 2010 (UTC)

It's not a question of saying that the article is boring or otherwise unworthy, merely that the hook is unsuitable for a section entitled "Did you know?" EdChem came up with three of his/her newly sourced BLPs a couple of days ago: all three of them were decent articles but, for two of them, it was really difficult to find a hook that fitted with a "Did you know?" section (and, in one case, accepted Main Page legal prudence). Such articles simply don't belong in a section entitled "Did you know?", whatever their other merits. Physchim62 (talk) 14:52, 11 November 2010 (UTC)

Support. Interesting hooks from an article should be found whenever possible and should certainly be given first priority. There's little point in putting a hook on the main page if it won't generate any clicks. - PM800 (talk) 14:26, 11 November 2010 (UTC)

Oppose arbitrary judgments, but recognise that the rules do allow us to consensus-reject hooks as unsuited to use. EdChem (talk) 14:41, 11 November 2010 (UTC)

Oppose, per Gatoclass (talk · contribs), Lampman (talk · contribs), and EdChem (talk · contribs). This would lead to problems over being too subjective, arbitrary, vague. -- Cirt (talk) 16:53, 11 November 2010 (UTC)

Support. It may be subjective, but it needs doing. People should not be approaching the process with the viewpoint that it doesn't matter how dull their hook is and that if there are no solid technical reasons for rejecting their nomination then they have a "right" for it to go on the main page. --Demiurge1000 (talk) 18:42, 11 November 2010 (UTC)

Oppose on subjectiveness. However, I could see supporting a combination of this with a hook limit: i.e., if you have more than x hooks per month, boringness becomes a criteria. Haus^Talk 18:50, 11 November 2010 (UTC)

"Boringness" is already a criterion, and indeed is inherent in the very title of the section "Did you know?" Physchim62 (talk) 18:54, 11 November 2010 (UTC)

Support Sometimes boring is just boring. Nev1 (talk) 23:38, 11 November 2010 (UTC)

Support. Main page must be interesting to as many readers as possible. Materialscientist (talk) 07:16, 12 November 2010 (UTC)

Strong support - we need to reject boring hooks much more often. Ed ^{[talk] [majestic titan]} 08:02, 12 November 2010 (UTC)

Support Yes, it's subjective, but any disagreements on the boringness of a hook will be ameliorated by the greater number of reviewers who will be able to give 2nd, 3rd, 4th, etc. opinions (assuming the "Require article nominators to review articles" proposal is accepted). Consensus will then dictate the suitability of 'marginal" cases, and extra eyes will be there to help tweak mundane hooks into something more interesting. Sasata (talk) 08:10, 12 November 2010 (UTC)

Support—Hey, it's on the main page. The current method is letting hooks on there that make WP look lame. This has gone on for too long. It's embarrassing. Tony (talk) 08:27, 12 November 2010 (UTC)

Support. I know there are subjectivity issues here, but I believe this can be overcome. See Sasata and Physchim62's ideas above for example. —Bruce1ee^talk 09:21, 12 November 2010 (UTC)

Support— WhoTF wants boring hooks? A 'Quick fail' mechanism is needed. --Ohconfucius ^¡digame! 10:21, 12 November 2010 (UTC)

Neutral: Support in spirit, but this can't be done without a proposal for how to implement it. Just saying "let's reject boring hooks now" isn't going to change anything. rʨanaɢ (talk) 15:14, 12 November 2010 (UTC)

There are basically two proposals as to how to implement it. On is Johnbod's proposal of "voting on hooks", which is being discussed in more detail just below. The second is my proposal that, if a reviewer spots a bad hook on T:TDYK, they note the fact that they think it's not DYK material. Anyone is entitled to disagree with that assessment, of course, and if an article gets reviewed we should be entitled to assume that the hook is OK. But a submission with a hook that is evidently unsuitable for DYK shouldn't even be reviewed until the hook problem is sorted out. My proposal probably needs some mechanism for submissions to "drop off" the end of the reviewing queue after a certain length of time (5 days? 7 days?) to be fully workable, but I see this as a minor point: the length of time that hooks stay on the queue could even be an ajustment factor to keep the backlog in order – shorter time in the reviewing queue if there's a backlog of approved articles, longer time if hooks are running short. Physchim62 (talk) 16:47, 12 November 2010 (UTC)

If that's your proposal, it's no different than the system already in place. Reviewers are supposed to be leaving complaints about hooks that are too boring; back when I reviewed I did it all the time (and people complained about how I was impeding their nomination's progress even though the article met all the requirements). Your proposal also has the same problems as the status quo: 1) it's only as good as the reviewers who enforce, or don't enforce, it; 2) a single reviewer with an unnatural interest in, say, highways can let a ton of otherwise boring hooks slip through. There is nothing new in your proposal, and Johnbod's doesn't seem to be getting consensus. rʨanaɢ (talk) 19:21, 12 November 2010 (UTC)

If there's nothing new in my proposal, then why is it getting so much opposition? ;) And why are so many editors complaining about boring DYK sections? And why does the average DYK hook only get a thousand click-throughs? Physchim62 (talk) 19:37, 12 November 2010 (UTC)

I'm not sure where people are voting on your proposal in particular, so I don't know why it's getting opposition. As for DYK sections being boring, well, like I just said (did you read my comment?) the status quo doesn't work either, and your proposal is no different than the status quo. Finally, it has been known for a long time that click-throughs are not a great metric for article interestingness; some interesting hooks get few clicks (because of the time they are shown, their location in the list, or random variation), and as you can see from WP:DYKSTATS, some not-so-interesting hooks get many. rʨanaɢ (talk) 20:04, 12 November 2010 (UTC)

Well we know (at least) three objective point:

• half of all DYK hooks get fewer than a thousand click-throughs while they're on the Main Page [1]
• this isn't because DYK is "below the fold" because, over the same period, OTD hooks had twice the click-through rate of DYK hooks (after adjusting for the rapid rotation of DYK sets)
• and there must be reader eyes on the DYK section because, when a really good hook goes on, it gets tens of thousands, or even hundreds of thousands of click-throughs (see WP:DYKSTATS)

So I don't think my proposal represents the status quo, when the status quo is producing hooks that our readers just don't want to click on: it represents actually requiring hooks to be interesting before even looking at the rest of the article. I simply don't believe that there's a host of wonderful articles behind all those lazy, boring hooks: I reckon that, if I could be bothered to click on them, I would find that the lazy, boring hooks link to lazy, boring articles. But that's irrelevant really, because if nobody clicks on the hooks we'll never find out. Physchim62 (talk) 21:52, 12 November 2010 (UTC)

Again, read through my comments. If you do so, you will see I am not debating that DYK often produces boring hooks. What I am saying is that your proposal also will, because it's no different than what people are already supposed to be doing. rʨanaɢ (talk) 00:46, 13 November 2010 (UTC)

Of course we agree that DYK often produces boring hooks, and that my proposal is no different from what people should be doing anyway. The point is that reviewers aren't rejecting hooks because they're boring, and editors aren't refusing to put them into prep queues, when they should be doing under DYK current guidelines and any common sense interpretation of the title "Did you know?" I don't have a magic wand that can change peoples attitudes; I'm just trying to say "look, it isn't that difficult to reject these hooks." Everyone will benefit if these hooks are weeded out before they reach the Main Page, preferably before DYK has even invested reviewer time in looking at the whole article. Contributers will have more readers for their articles, reviewers will have less work to do and Wikipedia will have a better Main Page. But, if it's so easy and it's already in the rules, why isn't it being done? Physchim62 (talk) 02:31, 13 November 2010 (UTC)

Oppose - subjective and a potential source of lengthy and unproductive discussions about whether certain facts are interesting. Some facts will be interesting to some people and boring to others ... that is something which cannot be changed. By all means, I support revising hooks in ways that may make the more interesting to more people, but this proposal is not that. Also, this proposal does not address the core issue which was raised at the beginning of these discussions: the quality of the articles, not the hooks. -- Black Falcon ^(talk) 18:26, 12 November 2010 (UTC)

It does address the issue of article quality: why should precious reviewer time be wasted on reviewing articles with utterly mundane hooks when it could be used on ensuring the quality of the articles with hooks that actually fit in a section entitled "Did you know"? Physchim62 (talk) 19:40, 12 November 2010 (UTC)

What you're saying makes sense in the context that you're considering (one where judgments can be made about which hooks are mundane and which are not) but it is inapplicable in the context that I am considering (one where such judgments are entirely subjective and not useful). I don't oppose improving hooks using an approach taken by Tony (here, without the negativity), but I don't believe that the mundanity of a hook can be judged objectively or on its own merits. Holding constant the quality of the hook itself, hooks about topics which do not interest us will be more boring than hooks about topics which do interest us, and this type of judgment is completely personal and subjective. -- Black Falcon ^(talk) 20:13, 12 November 2010 (UTC)

Oppose, mostly - Interesting and boring are in the eye of the beholder, so this is seriously subjective. Also, we wouldn't necessarily be judging the submitted hook. Many boring hooks can be improved by cleverness in the review process (something that I and some other reviewers actually seem to enjoy doing). However, I would support a rule that says that it's OK to reject articles/hooks that are BOTH boring and substantially similar in topic to other articles/hooks by the same contributor that have been featured recently or are on the noms page. It's the combination of boringness and sameness that I would reject, not boringness alone. --Orlady (talk) 20:33, 12 November 2010 (UTC)

• Strong oppose. What's boring to one person may not be boring to someone else. For example, I find many sports related hooks dreadfully dull because I don't like sports. A sports fan, however, would find it interesting. This policy is only likely to create a lot of wiki-drama here.4meter4 (talk) 20:35, 12 November 2010 (UTC)
• Support but in the sense that hooks should be interesting, which is less subjective than what is boring (or at least it is IMO!). SmartSE (talk) 00:34, 13 November 2010 (UTC)

Interesting that you should think that way. The proposals that have been worked through (including mine, obviously) have tended to assume that it is easier to identify the "obviously bad" than the "obviously good". For me, all hooks that are posted to the Main Page should clearly fit within a section entitled "Did you you?", which sort of implies that they should be interesting. Another way of wording it might be that the hook fact has to be "unusual or unexpected" (rather than an "extraordinary claim", as the current selection criteria put it). Physchim62 (talk) 01:18, 13 November 2010 (UTC)

• Oppose. Again, subjective. --Rosiestep (talk) 04:37, 13 November 2010 (UTC)
• Oppose. Subjective and counterproductive. Will encourage sensationalism. ·Maunus·ƛ· 02:33, 16 November 2010 (UTC)
• Am concerned (leaning to oppose) that "interesting" hooks are often misleading or sensationalist. Good on April 1. Good to see the odd eye-catching one in an otherwise dull list. But if you try to make it into "today's surprising but possibly somewhat misleading facts" then actually the "shock value" of the good ones will be lost, while the whole thing loses a little bit of dignity. "Interesting hooks" are nice, and although subjective, it's certainly true that there would be good correlation between different people's opinion on what counts as one... I just don't think a continual diet of them (nor pressure on editors to manipulate an "interesting" hook out of a dull-but-worthy type of article) is particularly useful. TheGrappler (talk) 21:09, 16 November 2010 (UTC)
• Conditional Support, but only if there is a fair system of judging "boring" that involves more than one reviewer. I realize that the current system already allows a single reviewer to reject a hook as too boring, but nobody uses it because everyone realizes it is patently unfair and subjective. I prefer Johnbod's approach just below, but others could also work. First Light (talk) 21:35, 16 November 2010 (UTC)

Support this obviously makes sense but any changes must be done carefully. (I've submitted much too boring hooks (for other's articles, and when other hooks were rejected).) —innotata 00:16, 20 November 2010 (UTC)

Current DYK rules should be enforced: that's enough. —innotata 00:20, 20 November 2010 (UTC)

Strongest Possible OPPOSE - aside from all the other problems I have with it, implementing this would get the camel's nose under the tent for "I don't like you/I have a beef with you/etc., therefore I say your hook is boring" incidents. - The Bushranger _{Return fire}^{Flank speed} 00:25, 20 November 2010 (UTC)

Oppose This is just too subjective - I have just about zero interest in sports and politics, for example, but accept that some people find them very interesting. So I could quite easily scroll down all those noms and strike them out as boring, while everyone else would be outraged. Likewise, I find archaeology interesting, but to other people that's just piles of old rocks and broken pots... Simon Burchell (talk) 18:39, 20 November 2010 (UTC)

Oppose. Too subjective. OhanaUnited^{Talk page} 18:24, 22 November 2010 (UTC)

Strong Oppose completely subjective, will bring lots of WP:IDONTLIKEIT. Royalbroil 01:13, 28 November 2010 (UTC)

Reality Check this !vote has been going for well over two weeks now, are people going to carry on adding 50% oppose and 50% support until we have a month's worth of it? --Demiurge1000 (talk) 01:24, 28 November 2010 (UTC)

• Oppose Entirely too subjective. We have a global readership of millions of people from different cultures, background and experiences and those people are naturally going to have different likes, dislikes and interest. What is interesting to one person maybe stone cold boring to another but whose "interpretation" of interesting are we going to value? Agne^Cheese/^Wine 20:34, 4 December 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Specifically, rate hooks for interest

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Proposal failed. Gatoclass (talk) 13:22, 8 December 2010 (UTC)

---

Support Johnbod (talk) 02:11, 11 November 2010 (UTC)

Oppose - too subjective and too time-consuming. Gatoclass (talk) 06:54, 11 November 2010 (UTC)

Oppose. While I agree (in principle) with rejecting boring or mundane hooks, I don't see a great value to rating for subjective interest. As an example, there is currently a hook on the nominations page, which I just approved, that has to do with a cricket match. I have no interest in reading about cricket, but it was definitely an unusual (neither boring nor mundane) and "hooky" hook. cmadler (talk) 13:51, 11 November 2010 (UTC)

No need for a specific "interestingness" rating (how on Earth would we construct one of those?), simply reject the hooks that are obviously mundane. If an editor can't be bothered to find a non-mundane hook, why should a reviewer be bothered to read the article? Physchim62 (talk) 14:20, 11 November 2010 (UTC)

Just to clarify, I support the proposal as discussed in detail above, but I do think my proposal for simply not reviewing mundane hooks is quicker, simpler and more in line with DYKs vocation as a Main Page section, so I prefer it. Either one could work, but doing nothing is already going against the current DYK criteria, not to mention any other good reasons for rejecting mundane hooks. Physchim62 (talk) 17:13, 12 November 2010 (UTC)

Well I'm sure I'm not the only one who doesn't review boring hooks, but then someone else always does, eventually. By leaving a quick low rating you could actively express your lack of interest & disapproval. At the moment the culture is such that leaving a query sign just for boringness usually gets overriden. And if say 3 low ratings are left you are on the way to overcoming the subjectivity issue. But one way or another we need a way to actually stop boring hooks and articles going forward. Johnbod (talk) 17:42, 12 November 2010 (UTC)

Oppose, just adds a systematic / objective appearance to a decision process that remains fundamentally arbitrary. EdChem (talk) 14:43, 11 November 2010 (UTC)

Oppose, per EdChem (talk · contribs) and Gatoclass (talk · contribs). -- Cirt (talk) 16:54, 11 November 2010 (UTC)

To all of these, the idea (discussed in detail above) is to overcome subjectivity by getting several quick views - the wisdom of the crowd. But the ratings should not bind those choosing hooks, who can ignore them if they want to. It is a way of reducing rows with noms, since I anticipate that typically views will actually coincide, and also attracting new help to the page - something none of the other proposals are likely to do, with many likely to put newcomers off. Johnbod (talk) 16:55, 11 November 2010 (UTC)

Oppose on subjectiveness. Haus^Talk 18:48, 11 November 2010 (UTC)

Support. Someone is putting "too subjective and too time-consuming" everywhere. Main-page appearances need to be a little more time-consuming to be worthy of such exposure. The too-subjective argument seems to reject any notion of striving for quality. Tony (talk) 08:34, 12 November 2010 (UTC)

Support, as per Johnbod's comment above. —Bruce1ee^talk 09:23, 12 November 2010 (UTC)

Support. We ought to be able to construct a viable voting system so that the more interesting hooks get given priority in the limited Main Page space. Rd232 ^talk 12:27, 12 November 2010 (UTC)

Oppose Don't see how this is workable and don't see how it improves upon any other proposal for rejection of boring hooks; it just seems to add process creep without actually ensuring the outcome that we are looking for. rʨanaɢ (talk) 15:15, 12 November 2010 (UTC)

Oppose per above: subjective, time-consuming, and does nothing to address the quality (or quality control) of DYK articles, which is the key issue requiring DYK reform. -- Black Falcon ^(talk) 18:29, 12 November 2010 (UTC)

Oppose - Subjective, time-consuming, and a form of instruction creep. Also, many boring hooks can be improved by cleverness in the review process (something that I and some other reviewers actually seem to enjoy doing). --Orlady (talk) 20:25, 12 November 2010 (UTC)

Oppose per Orlady.4meter4 (talk) 20:36, 12 November 2010 (UTC)

Oppose. Subjective. --Rosiestep (talk) 04:35, 13 November 2010 (UTC)

Support Plus my "conditional support" of Reject boring hooks just above depends on this, or a similar system, being instituted. First Light (talk) 21:36, 16 November 2010 (UTC)

Not clear what this is supposed to be; does not sound like a good idea. —innotata 00:21, 20 November 2010 (UTC)

Strong oppose. - The Bushranger _{Return fire}^{Flank speed} 00:27, 20 November 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Increasing the character limit

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

No consensus, leaning oppose. Gatoclass (talk) 13:27, 8 December 2010 (UTC)

---

Support - Theornamentalist (talk) 01:54, 11 November 2010 (UTC)

Oppose - ok maybe to 2,000. Johnbod (talk) 02:11, 11 November 2010 (UTC)

Oppose - Dravecky (talk) 05:45, 11 November 2010 (UTC)

Support Going through a few entries, it's clear that this will rid us of a lot of dross. The limit would have to be relatively high to have any impact (see my stats above). Lampman (talk) 11:52, 11 November 2010 (UTC)

Oppose - According to Lampman's stats, the character limit would have to be pretty high (4,000 to 5,000) to have a real impact, and I think such a character limit is too high for DYK. cmadler (talk) 13:53, 11 November 2010 (UTC)

No strong view - adjusting to 2000 or 2500 characters seems reasonable, and we do get cookie cutter stuff that just makes 1500 characters, but I am unsure that this wouldn't just change those to just-2000 character cookie cutter articles. EdChem (talk) 14:44, 11 November 2010 (UTC)

Oppose. character count ≠ quality, and any attempt to pretend that it does will inevitably lead to a loss in quality. I would support removing the current 1500 character minimum, but now is hardly the time to be increasing DYK input when the reviewing procedures are already stretched beyond their limit. Physchim62 (talk) 15:38, 11 November 2010 (UTC)

In theory yes, in practice many editors simply scramble trivialities to fit into 1500. Here extra 500-1000 bytes of prose means a lot (personal experience). Materialscientist (talk) 07:12, 12 November 2010 (UTC)

Support, would have to be debate about what to increase it to, but yes, good idea. -- Cirt (talk) 16:54, 11 November 2010 (UTC)

Support increasing limit to 2000, but not higher at this time. Because the proposal is vague it will not reach consensus. For example, my "support" vote appears to be in line with Johnbod's "oppose" and EdChem's "no strong view." Cbl62 (talk) 17:32, 11 November 2010 (UTC)

And perhaps Cmadler's oppose too. So an increase to 2K might well achieve consensus. Johnbod (talk) 17:40, 11 November 2010 (UTC)

It might reach consensus, but it would still be pointless on any objective criterion. Physchim62 (talk) 18:58, 11 November 2010 (UTC)

Support (2000 or 2500). I would oppose any increase to the 5x rule though. Materialscientist (talk) 07:12, 12 November 2010 (UTC)

Support Yes, some will "pad" articles with extra verbiage to qualify, but those cases will (hopefully) be caught in the screening process. Reviewers should not be afraid to reject a hook for an article that has been obviously "padded". Sasata (talk) 07:44, 12 November 2010 (UTC)

Support—One of the several reasons hooks fall flat on their face is that not enough information is provided for the reader to "get it". Combine with fewer items, please. Tony (talk) 08:30, 12 November 2010 (UTC)

Tony, this proposal is to increase the character requirement for readable prose in the article, not to increase the allowance for characters in the hook. EdChem (talk) 09:06, 12 November 2010 (UTC)

I'd also dispute the comment about hooks: often they need to be cut down to make them more "hooky". Physchim62 (talk) 13:24, 12 November 2010 (UTC)

Hooky, sure, but many of them fall flat because they lack just those few extra words that will make them self-explanatory ... the surprising or interesting bit, the whole point. Tony (talk) 12:04, 13 November 2010 (UTC)

Support, up to 2000 or 2500. —Bruce1ee^talk 09:26, 12 November 2010 (UTC)

Support. However, downside is that it may actually increase the temptation of committing plagiarism. --Ohconfucius ^¡digame! 10:21, 12 November 2010 (UTC)

Oppose. What does this actually achieve? It doesn't tackle the "cookie cutter" problem, it will just create bigger, harder to check cookies. And it'll reduce the supposed benefit of DYK for newcomers, with a higher threshold making their input less likely. A length criterion of 1500 is useful to exclude trivially short articles, but it is not a measure of quality. A crude measure of quantity is not a substitute for identifying quality. Rd232 ^talk 12:24, 12 November 2010 (UTC)

Oppose - for now because it's already been shown that the limit would have to be substantially increased to make a difference and no actual limit has been proposed here. Also, I think we should try qpq first. Additionally, per rd232. Gatoclass (talk) 13:59, 12 November 2010 (UTC)

Oppose Quantity ≠ quality, and the issue that started this whole discussion was article quality. 1500-character articles can still be good and interesting, and 2500-character articles can still be bad and boring. rʨanaɢ (talk) 15:17, 12 November 2010 (UTC)

Oppose - not a solution. It should take approximately the same amount of time to review a 3,000-character article as two 1,500-character articles. Requiring more text is not likely to reduce the workload of DYK reviewers. Increasing the character requirement may be a good idea for later, but it should not be part of the reform to address quality and quality control issues. -- Black Falcon ^(talk) 18:34, 12 November 2010 (UTC)

Oppose - Because 1,500 characters seems to be the right length to provide good basic coverage of many topics, that threshold encourages people to write solid articles instead of stubs. Rather than encouraging quality, I expect that increasing the minimum length would lead to more padding of articles with copyvio material, excessive verbosity, and irrelevant details. Additionally, it would increase the burden on reviewers by increasing the effort involved in reviewing an individual submission. --Orlady (talk) 20:14, 12 November 2010 (UTC)

Strong support. Most topics are still stubs at 1500 characters. I would support raising the bar to 1800 or 2000.4meter4 (talk) 20:39, 12 November 2010 (UTC)

Support although quantity ≠ quality and this may encourage close paraphrasing and padding, 1500 really isn't a lot and good DYKs tend to have more. I'd support rising to 2000, but maybe consider an IAR clause for amazing hooks where nothing more can be found to increase the length of an article. SmartSE (talk) 00:50, 13 November 2010 (UTC)

Comment. The selection criteria already allow reviewers to reject articles of more than 1500 characters if they feel the article is too short. Maybe reviewers don't want to use those provisions, I don't know: if that is the problem, it is the same problem as the "boring hooks", where again the criteria say reject boring hooks but the reviewers don't do it. Physchim62 (talk) 03:25, 13 November 2010 (UTC)

Personal opinion can always be contensted, and maybe this is why rejection of 1500+ articles is rare. Here putting a clear formal criterion would help reviewers. I wish we had such digital criterion for boringness :-) Materialscientist (talk) 03:58, 13 November 2010 (UTC)

Oppose. I oppose any move to make DYK a more difficult UX than it is for the novice. For veteran contributors, I'd support the 2000. --Rosiestep (talk) 04:31, 13 November 2010 (UTC)

Support. Writing should be succinct but the hooks need to be long enough to be well-written. SlimVirgin ^{talk|contribs} 11:05, 13 November 2010 (UTC)

No, this is for articles not hooks! There's not much point in commenting on these summary headings if you haven't looked at the discussions above, lengthy though they are. Johnbod (talk) 11:08, 13 November 2010 (UTC)

• I see very little downside, on the whole, to a substantial increase in size thresholds - 3,000 or above is quite reasonable, and even 5,000 would not ruin things. (If we go much above 3,000, however, I'd like us to consider commensurately increasing the time allowed for nomination - perhaps ten days or two weeks - so as not to penalise "gradual" authors) Shimgray | talk | 11:41, 13 November 2010 (UTC)

Comment"Gradual" authors can always work in userspace before moving their work into the live article - I don't think increasing the character limit necessarily means you have to increase the time allowed for nomination. Simon Burchell (talk) 18:45, 20 November 2010 (UTC)

Oppose - I've looked at my own DYK articles and found that 11 out of 61 are below 2,000, 26 between 2,000 & 3,000, 13 between 3,000 & 5,000 and only 11 over 5,000. Some articles are never going to be much bigger than 1,500, because there just isn't much written about them in easily accessible sources - none of those 61 articles have been significantly expanded since they appeared on DYK, arguably suggesting that further expansion is non-trivial. Mikenorton (talk) 13:07, 13 November 2010 (UTC)

Oppose - some short articles can be both excellent and interesting. Toughening length requirements may make it harder for novices, and for people writing on obscure or poorly documented topics. TheGrappler (talk) 01:49, 16 November 2010 (UTC)

Oppose per TheGrappler and others. —innotata 00:27, 20 November 2010 (UTC)

Strong Oppose - as I've said before and will say again, a 1,000-character article on an obscure subject can be FAR more interesting and complete than a 5,000-character article on a less obscure one. - The Bushranger _{Return fire}^{Flank speed} 00:29, 20 November 2010 (UTC)

Conditionally support Keep 1500 for lists, otherwise they would need rubbishy super-long leads to comply. Adabow (talk · contribs) 00:39, 6 December 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Increasing the citation requirements

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Proposal failed. Gatoclass (talk) 13:30, 8 December 2010 (UTC)

---

Oppose Johnbod (talk) 02:11, 11 November 2010 (UTC)

Support Same requirements as at GA should apply; one ref per paragraph is meaningless. Lampman (talk) 11:52, 11 November 2010 (UTC)

Support, better referencing = the Wikipedia of the 2010s decade. Geschichte (talk) 11:56, 11 November 2010 (UTC)

Oppose - DYK currently requires a non-trivial level of referencing (minimum 1/paragraph), and I see raising it further as a back-door attempt to replace new-article DYK with GA. 1/paragraph may not be GA-level, but it is decidedly not "meaningless". cmadler (talk) 13:59, 11 November 2010 (UTC)

It is meaningless because the need for references depends on the content. One paragraph can contain several contentious statements, while others can perfectly well stand on their own. Lampman (talk) 16:56, 11 November 2010 (UTC)

Comment: This can't be given a simple support/oppose. The quality of the sources used in an article is important, but discussions of sourcing requirements on Wikipedia always seem to degenerate into issues of quantity and mechanical adherence to over-simplified rules: the number of sources or the density of footnotes in the text. A single widely-accepted in-depth treatment of a topic is superior to three superficial newspaper articles on the same. A footnote after a paragraph is perfectly fine if it is clear that it supports the paragraph, and the footnote can bundle sources and explain what supports what part of the statement. Insisting on a footnote after each sentence (or more) just encourages close paraphrasing and plagiarism of the type that has been debated above on this page. --Hegvald (talk) 14:21, 11 November 2010 (UTC)

Your assessment is correct, but quality is already an enforced criteria for DYKs, and not up for discussion. This one is on quantity, although I am ambivalent on the merits of it (for the same reasons that you have described).--hkr (talk) 14:44, 11 November 2010 (UTC)

Support some change - certainly almost naked web addresses are as bad as entirely naked ones. We need to come to community consensus on what is reasonable referencing as a minimum requirement. EdChem (talk) 14:45, 11 November 2010 (UTC)

Support, per Geschichte (talk · contribs). -- Cirt (talk) 16:55, 11 November 2010 (UTC)

Comment. Proposal is too vague for me to know what I'm voting for. What would the new citation requirements be? Cbl62 (talk) 17:30, 11 November 2010 (UTC)

Oppose. As pointed out by Lampman and Cbl62, I just don't see how this could possibly work, especially from a reviewer's perspective. I tell a nominator that their three-sentence paragraph has to have one ref per sentence, they tell me the ref at the end of the paragraph supports all three sentences, what do I do then? (Especially if the ref is offline). --Demiurge1000 (talk) 18:46, 11 November 2010 (UTC)

I don't see a clear proposal here. "Two sites per para instead of one"? - surely not. The rule of at least one reliable site covering every non-trivial paragraph is good, it simply needs to be properly enforced, by checking the reliability of the sources. This I support Materialscientist (talk) 07:08, 12 November 2010 (UTC)

Oppose, as per Demiurge1000 . —Bruce1ee^talk 09:29, 12 November 2010 (UTC)

Support— can do with being much more stringent, but is no substitute to close manual checking. --Ohconfucius ^¡digame! 10:21, 12 November 2010 (UTC)

Neutral. Seems like meaningless aspiration or needlessly bureaucratic rule. It's basically down to reviewers - and that's why I'd support moving to Two Reviewers. Rd232 ^talk 12:49, 12 November 2010 (UTC)

Oppose - our citation standards are fine. If articles are getting through with inadequate citations, that's because of sloppy reviewing not sloppy citation standards. Gatoclass (talk) 14:04, 12 November 2010 (UTC)

Oppose If an article is poorly-cited enough that it deserve a {{refimprove}} tag, then reviewers are supposed to be rejecting it anyway. I don't see what this proposal would add to that. (FWIW, "one citation per paragraph" is a heuristic only, not a rule as far as I know, and I never much liked it anyway.) rʨanaɢ (talk) 15:20, 12 November 2010 (UTC)

If this proposal is for raising a per-paragraph citation requirement, then I oppose it'. If it is for requiring that all (or almost all) information in an article be properly attributed (using inline citations) to multiple, reliable sources, then I completely support it. -- Black Falcon ^(talk) 18:37, 12 November 2010 (UTC)

Oppose The basic citation requirements are fixed WP-wide. Interpreting those basic requirements really depends on the article: different subject areas have different points that can be "taken for granted" without needing citations, for example. DYK should focus on having a good interpretation of those basic requirements (with appeals for a second opinion if necessary). It is a subjective judgement call, and always will be. Obviously, if a reviewer thinks the article is insufficiently referenced, then they shouldn't pass it; I don't think there's any real disagreement on that point. Physchim62 (talk) 19:19, 12 November 2010 (UTC)

On a related note, I suspect that the absolute requirement to have an inline citation directly after the hook fact may be a sort of perverse reason behind some of the "boring hooks", with submitters simply taking a referenced sentence, changing it into a question and posting it as a hook (i.e., without thinking "is this really a good hook?"). Just a reminder of the law of unintended consequences! Physchim62 (talk) 19:19, 12 November 2010 (UTC)

Interesting observation with a lot of truth to it. --Orlady (talk) 20:40, 12 November 2010 (UTC)

Oppose - In my experience, the current citation requirements, combined with the expectation of one inline citation per paragraph, are effective in encouraging many articles to be substantially improved between the time they are nominated and the time a hook is approved for DYK. I agree with Gatoclass that it comes down to the quality of the review -- if reviewers do their job, the current rules are effective. --Orlady (talk) 20:40, 12 November 2010 (UTC)

Oppose per Orlady. Also, increasing referencing standards will only further increase the liklihood that articles by new wikipedia editors will be rejected. As it is, most articles by newbies require DYK reviewers to step in and help clean things up. Let's not make so many hoops that DYK reviewers are less likely to step in and "save" a potential article.4meter4 (talk) 20:44, 12 November 2010 (UTC)

Oppose DYK's are not/should not be required to be Good Articles. Grsz¹¹ 05:10, 13 November 2010 (UTC)

• Support DYK's should be good examples of short articles within policy. They should be well enough sourced to exemplify the current sourcing requirement standards. That is still a much lower requirement than GA. ·Maunus·ƛ· 02:35, 16 November 2010 (UTC)

Oppose per cmadler and Physchim62. - The Bushranger _{Return fire}^{Flank speed} 00:30, 20 November 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Reducing DYK frequency

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

No consensus. Gatoclass (talk) 13:34, 8 December 2010 (UTC)

---

Fundamental. there are many good suggestions that would work with this, but none that would work (IMHO) without it. Physchim62 (talk) 02:02, 11 November 2010 (UTC)

Yes, support, but how is the issue. Johnbod (talk) 02:11, 11 November 2010 (UTC)

Oppose on the grounds that it reduces only output and does nothing to address the actual problems of input or the need for more thorough reviews. - Dravecky (talk) 05:45, 11 November 2010 (UTC)

Support Reducing output is essential to improving quality. Can only work in combination with some of the above options though. Lampman (talk) 11:52, 11 November 2010 (UTC)

Output should be reduced, but only in conjunction with input. And since the proposals that are likely to pass won't affect the input, I oppose any tampering with the output.--hkr (talk) 13:57, 11 November 2010 (UTC)

Oppose output-based "solutions". Reducing output requires some additional change in DYK selection, and without knowing what that other change is, I can't support this. cmadler (talk) 14:02, 11 November 2010 (UTC)

Wikipedia:Did you know/Guide already states "Not all suggestions have to be used in the template. Choose the ones that will pull in a variety of readers." (emphasis in the original) No big change needed at all, simply for DYK to adhere to it's own guidelines. Physchim62 (talk) 18:11, 11 November 2010 (UTC)

See earlier response, I haven't changed my view since earlier in this thread. EdChem (talk) 14:46, 11 November 2010 (UTC)

Comment. DYK has to choose whether it is a quality control stamp on new articles, something which doesn't in itself need a Main Page section, or a process to compile a Main Page section entitled "Did you Know?" I'm quite willing to open a specific RFC on this one, because I think there will be no lasting improvement at DYK while it treats its Main Page slot as something which can be sliced up at will. Physchim62 (talk) 15:13, 11 November 2010 (UTC)

I'd agree with that. The "change nothing" mentality that persists here shows that this needs wider input, since we're actually talking about the main page of the entire encyclopaedia, not just some limited project. Lampman (talk) 17:11, 11 November 2010 (UTC)

'Oppose, in favor of other measures (increasing chars size, citation requirements, etc) that would have the same impact. -- Cirt (talk) 16:56, 11 November 2010 (UTC)

Support. Three updates per day would be optimal IMO. Cbl62 (talk) 17:28, 11 November 2010 (UTC)

The optimum would be one update per day, so that DYK hooks can be seen by readers in all timezones. That's probably too big a step to be taken at once, unless it's forced from outside. Physchim62 (talk) 18:13, 11 November 2010 (UTC)

Comment to give an example of one of the problems caused by DYK's current rotation frequency, see this edit at WP:ERRORS: when problems with an article or hook are discovered through the hook being on the Main Page, they are very rarely addressed because the hook has already disappeared. Another example is the "Recent deaths" link at the bottom of the "In the news" section… never noticed it? Well it gets (on average) more click-throughs than all the DYK articles put together! Physchim62 (talk) 18:33, 11 November 2010 (UTC)

Support. I realise this is only the "output" end of the system, but it needs to happen at the same time the other changes are put in place, otherwise we risk having a "crisis" caused by running out of available prepared nominations. --Demiurge1000 (talk) 18:48, 11 November 2010 (UTC)

• We can (and have) adjust the output flow pretty quickly in response to available nominations, both through frequency of updates and number of hooks per update. Right now we have six updates in queue/prep, and about 200 hooks on the nominations page. Assuming a 75% approval rate of nomations, we have more than a week's worth at our current rate. The rate could fairly quickly be throttled back to two updates per day, which gives us about a two-week backlog. I suspect that even under the most stringent proposals (except for those that explicitly limit output) we can find 16 suitable hooks per day, which is enough for two updates (which I think is the optimal amount). So I don't argue that we shouldn't seek to reduce the update frequency, but I do say that the update frequency is a result, not a cause, and we need to treat it as such. cmadler (talk) 21:12, 11 November 2010 (UTC)

Support - I think the frequency has been a driver for general sloppiness and stress in the DYK process. Not pointing fingers; 4x per day is just a hard thing to keep up with.  Frank  |  talk  21:19, 11 November 2010 (UTC)

Oppose. This proposal is the same as "Slowing down the output rate" above! (the number of hooks per set is very hard to change significantly). Rejecting poor-quality noms is primary, the output rate should be flexible depending on the availability of approved noms. Limiting the output will simply bloat the T:TDYK page, which is already slow to load. Materialscientist (talk) 07:04, 12 November 2010 (UTC)

No, this isn't the same as the proposal above. The proposal above is saying throughput rate needs to come down to allow better reviewing at constant resources. This proposal would apply a hard limit to the number of sets per day, which is also equivalent to limiting the number of hooks per day (with a little leeway for 7- and 9-hook sets). Ideally, the limit would be one set per day, but I accept that DYK would have to run at two sets a day for at least an interim period while the change beds down and participant expectation have time to change. Physchim62 (talk) 13:47, 12 November 2010 (UTC)

Oppose, as per Dravecky and Materialscientist. —Bruce1ee^talk 09:31, 12 November 2010 (UTC)

Support per my arguments above re increasing pool and thus quality of what gets onto MP. --Ohconfucius ^¡digame! 10:21, 12 November 2010 (UTC)

Oppose - if the object of this poorly stated proposal is to ease the workload on reviewers by giving them less hooks to review, it won't do that. As Dravecky said, it will do nothing to reduce the total pool of submissions needing review, therefore it achieves nothing. Gatoclass (talk) 12:57, 12 November 2010 (UTC)

Actually no, that isn't the object of the proposal at all. There are two main objects. Firstly to guarantee a higher reward (in terms of time on the Main Page and hence article reads) for those hooks that are selected, as a sort of "compensation" to DYK submitters for accepting the necessarily more stringent reviews. What has happened up to now is that the prolific submitters have been allowed to debase the reward of a DYK slot, by increasing the number of sets and so reducing the time that any individual hook is on the Main Page. This is typical of the way DYK has been run for the benefit of its prolific contributors and to the detriment of occasional participants and new comers, and it has to stop. Which brings me to the second object of the proposal: to focus the attention of all participants in the DYK process on the fact that DYK exists to generate a Main Page slot. It might do other things as well, but it's primary purpose is to provide material for a section on the Main Page entitled "Did you know?" If not, then well, we'll just use that Main Page space for something else, there's no shortage of ideas as to what could be done with the space. Physchim62 (talk) 13:47, 12 November 2010 (UTC)

If that was the object of the proposal, it should have been specifically stated and not left for !voters to try and guess what it was about. But your comment just underlines my own criticism of many of these proposals as half-baked and unclear. As for your other comments, everyone has their own opinion on what exactly DYK is "about" and at this point yours has no more validity than anyone else's. Gatoclass (talk) 14:12, 12 November 2010 (UTC)

Of course it would have been better if there had been links back to the discussions above when this !vote was set up, that's been mentioned elsewhere. As for what DYK is "about", then well, if it's not "about" producing a Main Page section then fine, we'll just find another use for that Main Page section, it's not a problem. Physchim62 (talk) 14:38, 12 November 2010 (UTC)

So if you can't get people to agree on what you think DYK should be about, you will move to have it abolished? Sounds a little petulant to me. However, you will need to get consensus for that, and I suspect that will turn out to be more of a problem than you anticipate. Gatoclass (talk) 14:51, 12 November 2010 (UTC)

Not petulant at all. I've been saying DYK has big systemic problems for a long time now. I'd much rather work with DYK regulars to sort those problems out, as that is obviously the most constructive solution. But I'm not got to stop saying that DYK has problems if I haven't been able to overcome the natural inertia on this page. Physchim62 (talk) 17:49, 12 November 2010 (UTC)

Oppose - I agree with Dravecky and Gatoclass that this would not reduce the total pool of submissions needing review. Furthermore, any measure that artificially limits the number of hooks by setting a quota would increase acrimony at DYK, due to battles over whose hook gets accepted and whose hook gets rejected. DYK can and does adjust the frequency and size of updates to match the availability of content. It also can change the number of suggestions through encouragement or discouragement of third-party nominations. --Orlady (talk) 20:22, 12 November 2010 (UTC)

Oppose per Dravecky and Materialscientist.4meter4 (talk) 20:45, 12 November 2010 (UTC)

Support will go a long way towards allowing more thorough reviews. Queues can be offset by raising standards and restricting number of simultanoeus nominations allowed.·Maunus·ƛ· 02:36, 16 November 2010 (UTC)

Support increasing quality of DYKs. First Light (talk) 21:39, 16 November 2010 (UTC)

Oppose: shouldn't we just put as many DYKs on the page as are cleared? —innotata 00:22, 20 November 2010 (UTC)

Oppose. - The Bushranger _{Return fire}^{Flank speed} 00:32, 20 November 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Require article nominators to review articles.

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Consensus to implement this idea. Physchim62 (talk) 14:08, 12 November 2010 (UTC)

---

Support Johnbod (talk) 02:13, 11 November 2010 (UTC)

Support 28bytes (talk) 02:31, 11 November 2010 (UTC)

Comment. This is the quid pro quo proposal that has been discussed throughout the talk, and of all the proposals, seems to enjoy the highest amount of consensus, although there is some concern that review quality could be affected. I support the idea, but the question is, how can it be enforced?--hkr (talk) 13:42, 11 November 2010 (UTC)

• cmadler has suggested that it becomes a part of the review, i.e. checking that the nominator has reviewed a hook since their previous nomination, which sounds like it could work OK. Mikenorton (talk) 13:54, 11 November 2010 (UTC)

• Seems like this could be incorporated into the nomination template pretty easily: check this user's TTDYK contributions. Click that, and if they have decent edit summaries, it's instant verification. 28bytes (talk) 15:58, 11 November 2010 (UTC)

• That would also show up editors that spend a lot of time doing mundane and useful tasks at DYK, which should I think count for something. Mikenorton (talk) 16:15, 11 November 2010 (UTC)

Support - I've suggested this several times, and I'm glad to see that it finally seems to be gaining traction. cmadler (talk) 14:03, 11 November 2010 (UTC)

Support - Stumbled in here, as an infrequent self-nominator, I'd say this is a good idea in concept, though you'll end up having to make sure that the newby reviewers don't completely screw up their reviews.--Milowent • ^talkblp-r 14:29, 11 November 2010 (UTC)

Support, preferably bot-monitored through a new DYKref template. This would also address the quality concern - putting yourself down as the reviewer means asserting you have done a proper review, and will be logged. It means taking responsibility as a contributing member of the DYK community. Editors who will not take that seriously deserve to be held accountable for fnot participating as a responsible and trust-worthy member of our community. EdChem (talk) 14:47, 11 November 2010 (UTC)

Support, per EdChem (talk · contribs) and Milowent (talk · contribs). -- Cirt (talk) 16:57, 11 November 2010 (UTC)

Support Nev1 (talk) 23:44, 11 November 2010 (UTC)

Support Don't see any disadvantages here. Any "tit for tat" reviewing will eventually be caught by our team of eagle-eyed reviewers. Sasata (talk) 07:46, 12 November 2010 (UTC)

Support Ed ^{[talk] [majestic titan]} 07:59, 12 November 2010 (UTC)

Support, as per EdChem. —Bruce1ee^talk 09:34, 12 November 2010 (UTC)

Oppose as WP:CREEP. Good in theory, but who's gonna keep tabs in practice? --Ohconfucius ^¡digame! 10:35, 12 November 2010 (UTC)

People know who nominates a lot, and if people don't point to a review as part of a nomination when they should, someone will notice sooner or later. Equally, shenanigans in reviewing will become apparent sooner or later, and if logs are more transparent, it will be a fair deterrent to misbehaviour. Rd232 ^talk 12:54, 12 November 2010 (UTC)

Support per EdChem and cmadler - but strongly recommend moving to Two Reviewers to ensure that this doesn't reduce reviewing quality. Would also recommend specifying that reviews need to be of articles created by newcomers, to prevent gaming by exchanging reviews. (People would probably notice that sooner or later, but still.) Rd232 ^talk 12:54, 12 November 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

This one looks like it's been closed way too fast. I don't care personally if this rule is implemented, but I don't know how it'll work with new editors. —innotata 00:26, 20 November 2010 (UTC)

Having a DYK lottery (either through Yzx's method or Roux's gradual approach)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

No consensus to implement. Grsz¹¹ 05:08, 13 November 2010 (UTC)

---

Very dubious Johnbod (talk) 02:13, 11 November 2010 (UTC)

Oppose - this is not a game show - Dravecky (talk) 05:45, 11 November 2010 (UTC)

Oppose - pointless. If we're going to limit output, it should be a deliberate, rather than a random, selection. cmadler (talk) 14:07, 11 November 2010 (UTC)

Oppose. - PM800 (talk) 14:26, 11 November 2010 (UTC)

Unconvinced EdChem (talk) 14:48, 11 November 2010 (UTC)

Oppose, per Cmadler (talk · contribs). -- Cirt (talk) 16:58, 11 November 2010 (UTC)

Oppose. The basic principle of lottery is fundamentally incompatible with Wikipedia. --BorgQueen (talk) 17:17, 11 November 2010 (UTC)

Oppose. Per BorgQueen and Dravecky. Cbl62 (talk) 17:24, 11 November 2010 (UTC)

Oppose. BorgQueen puts it very nicely, but I'd add that it's neither necessary, nor a solution to a problem. Physchim62 (talk) 03:25, 12 November 2010 (UTC)

• Comment: I can only presume the people commenting in this section haven't actually read my proposal; it was only called a 'lottery' because it built off a proposal that was a lottery. → ROUX ₪ 03:31, 12 November 2010 (UTC)
• As I understand it (Roux, correct me if I'm wrong), Roux's proposal is to have a large list of approved hooks (about 200, the same as the current "backlog") and that each editor receives a random selection of eight of those hooks in the DYK section when they hit on the Main Page. The oldest hooks in the set of 200 would be replaced as new hooks are approved. Physchim62 (talk) 03:36, 12 November 2010 (UTC)

• I think that might have been the original idea, but I think it was rejected as infeasible to randomly pull eight hooks each time the page is displayed. The only feasible way to do this is to randomly pull eight hooks that will be displayed for everyone for a length of time. In other words, updates would be compiled randomly rather than deliberately. cmadler (talk) 14:38, 12 November 2010 (UTC)

Oppose. I would rather have my nom rejected because it's not good enough, than by "the luck of the draw". —Bruce1ee^talk 09:44, 12 November 2010 (UTC)

Oppose— culling ought to be on qualitative grounds. --Ohconfucius ^¡digame! 10:23, 12 November 2010 (UTC)

Oppose - complexity of this isn't worth the benefits. I'd rather see a system of voting on hooks, so that any exclusion is on qualitative grounds. Rd232 ^talk 12:19, 12 November 2010 (UTC)

Oppose per all above.4meter4 (talk) 20:47, 12 November 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Limit monthly or daily self-nominations

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Proposal failed. Gatoclass (talk) 13:38, 8 December 2010 (UTC)

---

Support - Theornamentalist (talk) 01:54, 11 November 2010 (UTC)

Support Johnbod (talk) 02:13, 11 November 2010 (UTC)

Support Oppose Agree with Gatoclass below; no point in this one if quid pro quo goes forward. 28bytes (talk) 02:31, 11 November 2010 (UTC)

Oppose - see absolutely no point in this, will be unlikely to significantly reduce the number of submissions and will penalize those who, for example, want to build the occasional multi. Also I think the quid pro quo proposal will greatly reduce the rationale for this. More submissions now = more reviews, so it will even out in any case. Gatoclass (talk) 04:07, 11 November 2010 (UTC)

Support as an excellent way to address the input problem, as long as limits are set high enough to allow reasonably prolific writers to submit their best work. - Dravecky (talk) 05:45, 11 November 2010 (UTC)

DYK is supposed to encourage new article creation. I am strongly opposed to any measure likely to discourage new content or participation in this project - especially when there is no evidence that this will make any substantial impact on the total number of submissions, in addition to penalizing a particular group of contributors. Also, see my previous comment above. And BTW I think it's far too early to put a proposal like this to a vote, when it's had limited discussion up to now. Gatoclass (talk) 06:12, 11 November 2010 (UTC)

Not early at all, there's been a substantial amount of discussion under Wikipedia_talk:Did_you_know#Dispelling_a_myth_about_DYK and Wikipedia_talk:Did_you_know#Consensus_so_far. However, I do agree that a quid pro quo approach may make this proposal less appealing. And although the linked discussions weren't !votes, they did have (around) 11 in support of the proposal and 7 against, so it's dubious that there will be enough consensus for it to be implemented. --hkr (talk) 13:35, 11 November 2010 (UTC)

Support Will shift established editors' focus from quantity to quality. Lampman (talk) 11:52, 11 November 2010 (UTC)

Conditional support - only if we decide not to require nominators to review articles, and then only if the limit is per-hook. In those cases, I'd be OK with a limit of 2/day and/or 20/month. I am absolutely opposed to any per-article limit. cmadler (talk) 14:13, 11 November 2010 (UTC)

• Oppose for now. We seem to have consensus on going forward with the requirement for nominators to also review nominations. I'd prefer to wait a bit and see what kind of effect that has, both on the number of incoming nominations, and on the reviewer activity. cmadler (talk) 17:51, 12 November 2010 (UTC)

Comment: If this is to happen, it should be a limit on hooks accepted (rather than nominated, recognising more will be rejected as standards rise) and not on hooks nominated or on articles. Quid pro quo reviewing is a good start, but I remain concerned about high volume cookie cutter articles. EdChem (talk) 14:48, 11 November 2010 (UTC)

Perhaps I should point out that nobody has even demonstrated that such a system would substantially reduce the number of submissions yet. I think that's the least that should be done before a proposal like this is made. Not that I'd be likely to vote for it in any case. Gatoclass (talk) 15:13, 11 November 2010 (UTC)

Clearly not! But the figures above seemed pretty convincing to me and others, and showed it would be more effective than your own proposal to achieve a similar end by increasing article size. Now you are saying "Reducing the rate of output is not necessarily bad, but there's been no agreement on how best to achieve this and, by my estimation at least, not much chance of establishing a consensus on a method right now", and opposing each individual suggestion that works in this direction on the grounds it will not be effective by itself. Johnbod (talk) 17:09, 11 November 2010 (UTC)

Haven't done a full statistical analysis but these figures suggest a per month cap would make a difference:

TonyTheTiger: 44 DYKs in Oct. 2010; 58 DYKs in September 2010; 38 in July 2010;

Alansohn: 52 DYKs in Oct. 2010; 61 DYKs in Sept. 2010; 64 DYKs in Aug. 2010; 70 DYKs in July 2010; 65 DYKs in June

Geschichte: 32 in Aug. 2010; 32 in April 2010; 21 in March 2010; 28 in Feb. 2010; 31 in Jan. 2010

BillyHathorn: 24 in Oct. 2010; 19 in May 2010; 18 in April 2010; 25 in Jan. 2010

cbl62: 20 in Sept. 2010; 21 in Aug. 2010; 30 in July 2010; 19 in May 2010. Cbl62 (talk) 17:20, 11 November 2010 (UTC)

Thanks for the hard work, but that's nowhere near a sufficient survey. Even so, the highest month you've got there - September - has 58 from one user and 61 from another. Reduce them to, say, 15 per month and you've saved 90 slots. That's 90 slots out of 1080 for the month - only 8% of the total. And that's probably an exceptional month, it would probably be half that much normally. I might also add that Alansohn's submissions are almost invariably very easy to verify. What this proposal would do is potentially impose a huge penalty on a handful of fine contributors for a very minor net benefit. Gatoclass (talk) 17:39, 11 November 2010 (UTC)

Even if it was only an 8% reduction, which I doubt, that's a considerable help. You know perfectly well that Tony's Wikicup contributions aroused a lot of complaints here at the time, & Alansohn's have also been the subject of adverse comment from Sandy Georgia & others. Which is where we came in. For one person to have a new item on the main page every day seems excessive to me. Johnbod (talk) 17:51, 11 November 2010 (UTC)

For one person to be submitting two new articles per day over a one-month period shows that the DYK "award" has been debased to chicken-shit level. It has been debased by lowering the standards (and the reward of time on the Main Page) so that these people can get their hooks up regardless of any consideration for the rest of the project or the readers of the Main Page. That's why Main Page readers overwhelmingly don't click-through on DYKs. Physchim62 (talk) 18:01, 11 November 2010 (UTC)

Okay, since no-one else got around to it, I just collated the totals from our top 7 contributors over the last 10 months. Collectively, they averaged 18.7 submissions per month each. So if you imposed a limit of, say, 15 articles per month per person, you would have saved a total of 3.7 * 7 or 25.9 articles per month. We feature 1080 hooks per month, so the net saving from this proposal would be approximately 25.9/1080, or 2.4%. Gatoclass (talk) 06:15, 12 November 2010 (UTC)

Except that an average over 7 months is not at all an accurate way to measure the effect of a cap. Cbl62 (talk) 06:34, 12 November 2010 (UTC)

It was over an average of 10 months, not 7. Yes, it would have been better to do it over 12, or better still 24, but I didn't have time to go back that far and it would be unlikely to appreciably affect the end result. Gatoclass (talk) 06:46, 12 November 2010 (UTC)

That's not my point. Averaging collapses the highs and lows in individual user's output. To examine the impact a cap would have, you need to look at the data on a month-by-month basis. Cbl62 (talk) 06:51, 12 November 2010 (UTC)

I'm afraid I have to disagree. Averaging shows the net saving overall. Cherry picking the highs and ignoring the lows gives a very distorted view of how effective a measure like this would be. Gatoclass (talk) 07:01, 12 November 2010 (UTC)

Here's why averaging hides the impact. If you look at the last four months, and look only at five users (and there are certainly others who have been excluded), the impact of a 10 DYK limit would be significant. Chart below. That said, I've already noted that I'm fine with the "quid pro quo" alternative. Cbl62 (talk) 07:15, 12 November 2010 (UTC)

Editor	October	September	August	July
Alansohn	52	61	64	70
cbl62	9	20	21	30
Geschichte	13	18	32	7
BillyHathorn	24	15	7	15
TonyTheTiger	44	58	5	38
Cap Savings (limit of 10)	93 (8.6%)	122 (11.3%)	87 (8.1%)	113 (10.5%)
Cap Savings (limit of 15)	75 (6.9%)	97 (9.0%)	72 (6.7%)	93 (8.6%)

Yes, but this underlines my other point. There is really only one user who consistently contributes more than about 20 DYKs a month, and that is Alansohn who has a phenomenal average of 29.8 a month and who sometimes produces 60+ a month. A 15-hook-per-month cap would hugely diminish his contributions. I fail to see why one user should be so heavily penalized for the sins of the project as a whole - particularly by a measure that will only marginally address the problem.

I might add that some of those top 7 users have contributed little or nothing to the actual running of DYK. Quid pro quo is going to mean a much bigger contribution from them, which will greatly outweigh the relatively minor impact made by a monthly cap. Gatoclass (talk) 07:40, 12 November 2010 (UTC)

It's not about "penalizing" anyone. It's about implementing reforms that will satisfy those who might otherwise seek to get rid of DYK as we know it. And I'm willing to support the market-driven approach. There doesn't appear to be consensus for a cap, but there is clear consensus for quid pro quo. And implementing both a cap and quid pro quo is overkill in any event. Cbl62 (talk) 07:49, 12 November 2010 (UTC)

Really? I've been puzzled by your earlier comments positing the two as either/or. Quid pro quo is about increasing reviews, this is about reducing volume (whether it's called "input" or "output"). I see no connection between the two, and like most people here (not Gatoclass obviously) I think we need to introduce several changes to achieve the desired effects. The useful last bit of this discussion has not changed my view supporting a cap at all btw. Johnbod (talk) 12:35, 12 November 2010 (UTC)

The connection is that qpq reduces the volume per reviewer, because it adds reviewers to the pool. Reducing the burden on reviewers is the goal of most of the proposals - reducing the volume of submissions is only one possible way of achieving that, it's not an end in itself. Gatoclass (talk) 13:24, 12 November 2010 (UTC)

Actually, reducing the number of submissions is a worthy (and I'd say necessary) goal in itself. Our readers are looking for a bottle of champagne each day, not four bottles of lemonade! I'd rather submissions came down through self-selection on the part of the regulars, to give the reviewers more time to spend helping the newcomers. But if people think that some sort of imposed restriction is needed as well, then so be it, it's no big deal. Unless, of course, you think DYK exists for the submitters rather than the readers... Physchim62 (talk) 14:03, 12 November 2010 (UTC)

Support, agree with Lampman (talk · contribs), above. -- Cirt (talk) 16:58, 11 November 2010 (UTC)

Support, tend to agree with Lampman. --BorgQueen (talk) 17:15, 11 November 2010 (UTC)

Support, though I'm fine with trying "quid pro quo" first, as it is a sort of cap and trade alternative to an absolute cap. Either or both are fine with me. The question is what cap? Anything in the range of 10-20 per month is fine with me. Cbl62 (talk) 17:17, 11 November 2010 (UTC)

Oppose. No reason to quench prolific writers. I sense a gross logical mistake here "reducing quantity will force them to improve the quality" - No! They will simply do something else on WP on in RL. Writing and quality check/improvement are the top WP priority, IMO. Further, I see no evidence that DYK blunders originate from prolific contributors. Why should they get punished? Materialscientist (talk) 06:55, 12 November 2010 (UTC)

Oppose I'm with Material Scientist on this one; prolific contributors contributing "cookie-cutter" articles will simply have their hooks rejected if they are uninteresting. If they can write large quantities of articles that meet the increased length requirements, are reasonably well referenced, and interesting, good for them, and thanks for contributing to Wikipedia! Sasata (talk) 07:50, 12 November 2010 (UTC)

Oppose - per MS. No matter how much the boring Louisiana politicians bug me, we shouldn't penalize him for writing them. Ed ^{[talk] [majestic titan]} 08:01, 12 November 2010 (UTC)

Oppose, as per Sasata. —Bruce1ee^talk 09:47, 12 November 2010 (UTC)

Support, but I fear unworkable - the original object, IIRC, is to encourage newbies to participate and create new articles. Having no limit threatens that objective by crowding out the newbies. Needs somebody to keep track, and to also take account of frequent reciprocal nominations. --Ohconfucius ^¡digame! 10:25, 12 November 2010 (UTC)

Oppose per Gatoclass. Rd232 ^talk 12:17, 12 November 2010 (UTC)

Oppose - Of all the suggestions, this is the one I oppose the most (no, I would not be affected by it). A strict numerical cap on submissions from the most active contributors will certainly reduce input, but in the worst way possible: by discouraging article-writing and without regard to quality (i.e., the first 10 or 15 submissions are accepted, the rest rejected). I'm not convinced that there will be a "shift of focus" from quantity to quality: (1) submissions from experienced editors tend (in my experience) to be of a higher-than-average quality, so limiting their contributions would decrease the average quality of DYK submissions; and (2) the shift of focus will be from DYK to other things. -- Black Falcon ^(talk) 18:47, 12 November 2010 (UTC)

Oppose per Gatoclass.4meter4 (talk) 20:49, 12 November 2010 (UTC)

Oppose I can't see how this would solve our problems. Black Falcon (and others) have summed it up nicely. Lampman's point doesn't seem to be based on any evidence. SmartSE (talk) 00:22, 13 November 2010 (UTC)

Oppose. This is tackling the problem from the wrong end: it doesn't matter who writes the hooks. Regardless of creator, if the hook and article are good then use it, otherwise select another article. If some editors are flooding in cookie-cutter noms which get rejected, then they'll learn to either raise the quality of their contribs or else not submit weak articles to DYK. --BrownHairedGirl (talk) • (contribs) 02:29, 13 November 2010 (UTC)

Oppose. DYK is about writing new articles. --Rosiestep (talk) 04:18, 13 November 2010 (UTC)

Oppose Would senselessly confine good editors. The ones contributing lots of article aren't usually the problem. That said, all the Princeton and Michigan basketball season articles were annoying, so perhaps some sort of limit like that, but not like what is proposed. Grsz¹¹ 05:06, 13 November 2010 (UTC)

Support. We should encourage quality, not quantity. SlimVirgin ^{talk|contribs} 11:07, 13 November 2010 (UTC)

I agree, but this proposal addresses quantity only. It gives no consideration to the quality of nominated articles. -- Black Falcon ^(talk) 17:14, 13 November 2010 (UTC)

• Oppose First of all I must thank all those who have made positive comments about my DYK contributions. I think that rather than a hard monthly cap, which becomes yet one more statistic that needs to be tracked, that we should increase the minimum article size to 2,500 or 3,000 characters of prose, which has the benefit of cutting many of the bare stubs that pass through. Alansohn (talk) 00:53, 16 November 2010 (UTC)
• Oppose - raising the bar on submissions to decrease the submission pool makes more sense than hard limits. Haus^Talk 01:18, 16 November 2010 (UTC)

Oppose eh? No obvious reason, no benefits, and no good for some of our best contributors. —innotata 00:31, 20 November 2010 (UTC)

Oppose. This is nothing less than "You're doing too well, so we must penalise you!" newthink. - The Bushranger _{Return fire}^{Flank speed} 00:35, 20 November 2010 (UTC)

• Oppose Anything which discourages article creation and improvement is clearly way off.♦ Dr. Blofeld 16:06, 27 November 2010 (UTC)
• Oppose. Hard cap rarely works well. People can get around this rule easily by asking others to nominate on their behalf. OhanaUnited^{Talk page} 06:35, 30 November 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Do nothing

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

not a practical option Physchim62 (talk) 02:02, 11 November 2010 (UTC)

Better than doing something bad, though. cmadler (talk) 14:14, 11 November 2010 (UTC)

DYK is already a disaster area that corresponds neither to its title, nor to its vocation as a Main Page slot. Doing nothing is tantamount to abolishing it. Physchim62 (talk) 17:26, 11 November 2010 (UTC)

• Support - may be the easiest way of ensuring a quick death for the present DYK concept. --Ohconfucius ^¡digame! 10:26, 12 November 2010 (UTC)
• Comment - I don't see how DYK is a disaster and I see a long future for this highly useful endeavor to promote new material at wikipedia. I'm not saying things are perfect here, but for the most part DYK runs just fine in its current state.4meter4 (talk) 20:53, 12 November 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Comments

• Increasing the character limit.

• 2500 seems fair; reducing the logic, simply the time it takes to write would make contributors spend 40% more time on an article, and 2500 is not that hard to achieve. - Theornamentalist (talk) 01:54, 11 November 2010 (UTC)

• According to Lampman, 68% of noms are already over the 2500 limit. Upping the limit would more penalize submitters for whom English is not their first language (as noted in the stats above for the "Norwegian" contributions). Physchim62 (talk) 02:17, 11 November 2010 (UTC)

• Limit monthly or daily self-nominations

• 20 a month seems good to me, max a year at 240 gives those who love to amass DYK's still something to achieve, and by maxing out their contributions, it could free up probably 100 spots for other editors a month. - Theornamentalist (talk) 01:54, 11 November 2010 (UTC)

Some of those are (IMO) terrible ideas, but I'll respect Theornamentalist's request not to indicate my opposition inline. 28bytes (talk) 02:31, 11 November 2010 (UTC)

It's just a collection of all the ones (good or bad) that have been proposed so far. I agree, some of them aren't practical.--hkr Laozi speak 03:26, 11 November 2010 (UTC)

Comment - I don't see any point in having a vote on these issues, at least, not right now and not in this format. The issues for each are generally more complex than are presented here, and with the exception of matsci's quid pro quo proposal above, none of them have looked close to achieving consensus. Also, I think we should give the qpq system a chance before trying anything more radical. One step at a time. Gatoclass (talk) 03:31, 11 November 2010 (UTC)

(ec from below) Your abstention from the !vote is noted, as is the habit of new sections appearing just as consensus might be reached on a previous section, an attempt at divide et impera perhaps. In any case your concerns are noted, and shall be duely treated. Physchim62 (talk) 03:41, 11 November 2010 (UTC)

I thought I might leave a few comments anyhow, to try and clarify some of the problems. Gatoclass (talk) 03:47, 11 November 2010 (UTC)

Actually I'm not sure if it is helpful commenting on these proposals because many of them were not discrete proposals in the first place, and they can't be addressed in isolation from one another. I think perhaps I will stick to my original instinct and refrain from commenting upon them further. Gatoclass (talk) 03:57, 11 November 2010 (UTC)

I think that it could help give focus, and the more popular ideas could emerge from the paragraphs of text above. When that's done, we could move on towards implementation and testing.. eventually. - Theornamentalist (talk) 03:38, 11 November 2010 (UTC)

Re "One step at a time", I agree. Debating 16+ proposals at once is a surefire way to ensure none of them move forward. 28bytes (talk) 06:21, 11 November 2010 (UTC)

One problem is that the number of participants has dropped a lot over the last week, and though of course all suggestions have complex arguments for or against, discussion has become rambling. This is hopefully a way to attract more participants. Johnbod (talk) 04:09, 11 November 2010 (UTC)

Personally, I'm inclined to think the best thing we could do with this discussion is hatnote it. With all due respect to Theo, he hasn't been engaged at any point in these debates until now and I don't think his summary of proposals is accurate, and a number of them are simply missing the point. I can see this whole section quickly degenerating into another rambling discussion about everything and nothing. IMO we'd be better off moving on before that happens. Gatoclass (talk) 07:14, 11 November 2010 (UTC)

I agree with Gato that we should give the qpq system a chance before making other moves. I suspect that qpq may have a similar effect as the monthly "quota" system that I had advocated. I see qpq as a "cap and trade" alternative to a true quota. Let's give it a chance before adding more elements all at once. Cbl62 (talk) 07:15, 11 November 2010 (UTC)

Theo hasn't, but I've been here since the (nearly) very beginning of the discussion, and it looks like the listed proposals are derived from the chronology of the discussion that I wrote earlier on in this talk, but admittedly without the discussion of history or the flaws brought up for each proposal. The chronology was never meant as a !vote, just a brief overview of the discussion events for newcomers to the talk. However, I do not debate why Theo sees the need for there to be a straw poll, which was done in good faith, and he does have a point. As 28bytes said, we have a small group of people debating 15+ proposals all at once, something needs to be done.--hkr Laozi speak 07:36, 11 November 2010 (UTC)

My basic concern with this new section is that it has divorced a grabbag of proposals from the actual discussion that took place about them. I mean, if I read a proposal like "Reject boring hooks" - well of course I'd be in favour of that, who wouldn't be? We'd all like to see better quality hooks on the mainpage. But since this proposal is presented in isolation, I can see it just regenerating the same debate it generated the first time.

If someone feels strongly about proposing this as a method of reducing submissions and improving quality, what they would need to do is start a fresh discussion listing all the pros and cons that have already been discussed, and then invite further comment. Or add some new suggestions of one's own. That is how to present a proposal - not just throwing out a catchphrase and asking people to vote on it. It seems to me that is just an invitation to going round in circles. Gatoclass (talk) 07:59, 11 November 2010 (UTC)

The specifics for each of the proposals listed here are detailed in the talk, if you're willing to dig through a 300+ KB discussion. These are just brief summaries of each proposal.--hkr Laozi speak 07:12, 11 November 2010 (UTC)

As I recall, nobody ever actually got around to proposing a specific method about how to implement such a system fairly. What is the point of voting on a general principle when nobody has been able to propose a satisfactory method? If someone wants to propose a specific method, we can debate the pros and cons of that, but otherwise, I don't see the point. Gatoclass (talk) 07:33, 11 November 2010 (UTC)

The initial chronology does list the cons that have already been discussed and relative consensus of each proposal (which was not included in this new list). And again, this wasn't intended as a vote, the (initial) list was just a chronology of the various proposed ideas and the flaws discussed by the opposition for each of them.--hkr Laozi speak 08:09, 11 November 2010 (UTC)

Yes, I'm not criticizing the initial list, which may have had some utility in summarizing some of the salient points. It's the !vote that I'm concerned about. Gatoclass (talk) 08:15, 11 November 2010 (UTC)

I strongly support this effort; further discussion at this point will only have us going in circles. I see no evidence above that people are voting out of a position of ignorance about the foregoing discussions. Lampman (talk) 11:57, 11 November 2010 (UTC)

Well - I assumed after 400k of largely fruitless discussion, everyone was exhausted by it and ready to settle for a modest reform. It seems I was wrong about that - some people would apparently like another 400k of discussion. I admire your stickability, but I find it hard to persuade myself that anything useful will come of it, and I'm sure I'm not the only one who feels that way. Gatoclass (talk) 13:28, 11 November 2010 (UTC)

I was hoping to catch more of an audience, its just that I've seen similar discussions get quite lengthy and lose steam, and although I haven't taken part in this one, I've been reading it, and see many points brought up in the past that seemed to go nowhere. We need reform! I think we need to take action and be brave. In my opinion some of the proposals, while they would certainly come with strong opposition as does nearly anything changed on WP, would be better implemented for a short period of time to see how they would work and discuss when we actually have data to discuss on. I feel like we could be stuck in theoretical for more time then it's worth. - Theornamentalist (talk) 12:01, 11 November 2010 (UTC)

This is a pretty useless poll that encourages superficial replies to badly worded suggestions. Take "Increasing the citation requirements", for instance. This can't be given a simple support/oppose. The quality of the sources used in an article is important, but discussions of sourcing requirements on Wikipedia always seem to degenerate into issues of quantity and mechanical adherence to over-simplified rules: the number of sources or the density of footnotes in the text. A single widely-accepted in-depth treatment of a topic is superior to three superficial newspaper articles on the same. A footnote after a paragraph is perfectly fine if it is clear that it supports the paragraph, and the footnote can bundle sources and explain what supports what part of the statement. Insisting on a footnote after each sentence (or more) just encourages close paraphrasing and plagiarism of the type that has been debated above on this page. --Hegvald (talk) 14:16, 11 November 2010 (UTC)

Just as a note, each proposal has a corresponding section with a full in-depth discussion explaining all the details in the talk. It's not "badly worded" per se, it's a summary of all the proposals brought up in each section of the above talk. Admittedly, the editor who created the poll should have linked to each relevant section, but it is there if you want to read it.--hkr (talk) 14:19, 11 November 2010 (UTC)

I have read it (even commented in it), and the issues are more complex than these poll questions and brief replies allow for. That was my point, but perhaps I didn't express it clearly enough. Anyway, I moved my comment on sourcing requirements. --Hegvald (talk) 14:25, 11 November 2010 (UTC)

"Increasing the citation requirements" is detailed fully in Wikipedia_talk:Did_you_know#Higher_standards_for_sourcing. Each heading is just a summary, and all these proposals are very detailed in their own respective sections, but none of the sections are linked (which is a problem, and should be addressed, perhaps by copy-pasting the details?).--hkr (talk) 14:31, 11 November 2010 (UTC)

As you can see, the replies in the poll quickly degenerated to precisely the quantitative/mechanical issues I find problematic. I have seen it before in debates over deletion (I can find you an example or two if you wish). --Hegvald (talk) 14:55, 11 November 2010 (UTC)

• (ec) There is one enormous value to this, which is that it will allow us to put to rest the proposals that are currently widely opposed. That seems to include "Require two reviewers per hook" (5/5 opposed), "Abandon the new article concept" (5/5 opposed), "Abandon or increase the time limit criteria" (4/4 opposed), and "Having a DYK lottery" (3/3 opposed). Others seem to be widely supported, and we should start looking at implementation: "Incorporate CorenBot to scan for plagiarism" (5/6 support, 1 appears neutral), "Require article nominators to review articles" (4/4 support, plus strong support higher up this page under "Matsci's quid pro quo proposal"). Then I'd suggest that we temporarily set aside disputed proposals, and agree to revist those after a pre-determined period of time (1 month?). That will give us time to implement the uncontroversial proposals and start to get a feel for how they work. cmadler (talk) 14:35, 11 November 2010 (UTC)

Agreed. I think it's becoming clearer which proposals have consensus now. And my comment was in favor of the proposal! Even if it did list my criticisms of it...--hkr (talk) 14:39, 11 November 2010 (UTC)

The problem is that many of the above proposals are linked. Nobody is suggesting that having nominators also review articles is a Bad Thing, but neither is anyone suggesting that it's a solution on its own. I think we should eliminate those proposals which are tantamount to abolishing DYK, because any editor who wants to discuss them further can do so at T:MP. Physchim62 (talk) 15:30, 11 November 2010 (UTC)

I agree this is a useful stage in the discussion, narrowing down the wide range of options & proposals. There are "big picture" options, especially in terms of reducing output/frequency, and a number of specific measures that would go towards achieving this. Perhaps at some point these wider "aims" and detailed measures need to be taken separately. I wish I could agree with Lampman that everyone votiong here seems aware of the discussions above. Johnbod (talk) 16:42, 11 November 2010 (UTC)

Strongly agree with Cmadler. There are some proposals with wide support, let's give them the attention they deserve. 28bytes (talk) 18:19, 11 November 2010 (UTC)

• This section has been up for more than 36 hours now. Unless someone objects, I'm going to go through and close as either kept or rejected the proposals that are overwhelmingly leaning one way or the other (3-1? 4-1?). I would again like to suggest that we take 1 month to implement and test the proposals that have overwhelming support, and that, at the end of that month (let's just say December 15), we reopen discussion on all the more controversial proposals. cmadler (talk) 13:28, 12 November 2010 (UTC)

• Johnbod left a note on my talk page requesting that I not close any more discussion because it's "too early to do this". Personally, I think it's become clear that some proposals have consensus for/against now, and that is unlikely to change, and that some proposals do not have a consensus now, and that's unlikely to change. It seems reasonable to me to go ahead and close discussions, agreeing to revisit all the no-consensus ideas in about a month. However, at Johnbod's request, I'm not closing any more discussions, and if anyone thinks I misread a discussion as for/no-consensus/against, they are welcome to change or reopen it. I just think it's time to move on and stop talking about ideas that aren't going anywhere now, and start implementing the things for which we do have consensus. cmadler (talk) 14:17, 12 November 2010 (UTC)

Only 30 hours in fact, which is no time at all on these important issues. I've re-opened the ones that were no consensus, but am leaving the ones with a clear result one way or the other. There is plenty to do meanwhile implementing the 4 proposals that passed. The "lottery" one could also be closed. Johnbod (talk) 14:29, 12 November 2010 (UTC)

Might a closure of WT:DYK#unsourced BLP drive be considered? It would be good for it and its preceding discussion not to be drowned out by everything else being discussed. EdChem (talk) 15:01, 12 November 2010 (UTC)

I'd be wary of closing it outright: there seems to be some disagreement as to whether the BLPs are going to treated as new articles or whether there should be some other sort of expansion. Why not bring the section down to the bottom of the page, and note that this point needs to be decided on before it can be signed off. Physchim62 (talk) 15:39, 12 November 2010 (UTC)

• Please re-open all the polls. Some of us are just getting to this conversation and it is standard to leave open a five day window on these sort of conversations. Two days is hardly enough time to get enough input on any topic, even if it looks like a WP:SNOW close.4meter4 (talk) 20:59, 12 November 2010 (UTC)

One of the points that some participants here seem to have missed is that editors participate in WP voluntarily, and for a wide range of reasons, but they do so primarily because they get some form of enjoyment from it. Personally, I participate because I enjoy building content through writing or expanding articles, responding to questions, and (sometimes!) through discussing content matters with other editors. Submitting articles to DYK is a by-product of that - it's often quite rewarding to have an article mentioned on the front page, but I contributed articles long before I was aware of the DYK processes and hope to continue to do so irrespective of whether anything I do in future goes through the DYK process or not. I do sometimes contribute thoughts on DYK articles and hooks, but I know that there is a group of editors who spend much more time than me on processing DYK candidates, and they do an excellent job - but I feel no obligation to join that group because it's not what I get most pleasure from doing. So, there needs to be recognition that different editors have different roles on WP, and because some editors contribute new articles into the DYK process should not necessarily mean that it should be the same editors processing those submissions. Ghmyrtle (talk) 10:37, 17 November 2010 (UTC)

• FWIW, I think all the polls can be closed now. They have been open for over a week and non-one "voted" yesterday. I think the extra exposure was beneficial though. Johnbod (talk) 11:35, 18 November 2010 (UTC)
• I've just been commenting and "!voting", as have others; it looks like more comments are desirable, and the closed proposals were closed by people taking an active part in other discussions, after sometimes a very brief time, with fairly few comments and no signs of certain or snowballing consensus. —innotata 00:40, 20 November 2010 (UTC)