Wikipedia:Did you know/2020 RFC LT Solutions

Perma link to LT Solutions - May 2020

Original LT solutions 2/update

So far the first option, which requires an RfC, looks like it needs to be tweaked to this:

Nominators who fail to respond to a reviewer asking for a fix within 10 days should receive a talk page notification such as {{subst:DYKproblem|Article|header=yes|sig=yes}}; instruction for this should be added to the DYK notification template. Failure to respond to that notification within another 10 days is an automatic fail. Reviewers should note at the nom that they’ve posted to user talk, providing the date. Nominators may note when nominating at the nom at any time that they will not be available during certain dates, in which case the clock will not start ticking until the date they've said they'll be available again. Instructions should be updated at Finishing the review.

Please offer suggestions to flesh this out or tweak it so we can run an RfC on this. —valereee (talk) 18:20, 9 May 2020 (UTC)

I would hope that nominators can note when they aren't available even later on the nomination process: if it takes a month or more for a reviewer to show up, a nominator may not be available for reasons that did not exist when the nomination was made. Perhaps "Nominators may note at any time that they will not be available"? As RfCs take a month to conclude, I'd like to point out that there is nothing stopping reviewers right now from giving nominators a set period of time to respond (and posting to their talk page accordingly), and marking nominations with the fail icon if no progress is made. Since pings from the nomination are not always reliable, the talk page post is needed. I'd like to suggest that the initial (full) review be given the talk-page notification, and a final warning be given after seven or ten days, also with another talk-page notification. Since this will be a new way of doing things, it's only fair to make clear that prompt responses are now required. BlueMoonset (talk) 22:27, 9 May 2020 (UTC)

BlueMoonset, I'm not sure exactly what you're asking, would you revise the statement to reflect your suggestions? —valereee (talk) 23:25, 9 May 2020 (UTC)

Per comments made before, I would suggest increasing the time for either or both messages from seven days to ten, to allow for more time to respond. In addition, there's also the question of how this will affect class contributions; from past experience, a proportionally high number of "nominations that failed due to nominator inactivity" were cases where the nominator was a student editor who worked as part of a class and stopped editing after the class ended. If the nominator simply stops editing as soon as the edits are done, who should be contacted: the student or the coordinator? And perhaps in such cases, maybe it would be a good idea to mention to coordinators that the students should be ready to answer feedback regarding their nominations? Narutolovehinata5 ^tccsdnew 09:36, 10 May 2020 (UTC)

Narutolovehinata5, whoever was the nominator would get the notifications. I guess I don't have an objection to ten days for each. Not sure any length of time is going to help when the class is over and the student has no actual interest in editing. —valereee (talk) 10:54, 10 May 2020 (UTC)

Ten days is too long and there should be no requirement for talk page notifications. With such loose parameters, the number of nominations that fall under the criteria will probably be so small as to make the requirement pointless, at least if the object is to reduce the number of nominations. It should be seven days from the last post a reviewer made on the nomination page. Reviewers should not have to chase up nominators, if they can't be bothered tracking their own nominations, why should a reviewer have to be bothered doing it for them? Gatoclass (talk) 14:01, 11 May 2020 (UTC)

Gatoclass, that's a little hard on new nominators, I think. Many time I'll discover a reviewer has completed an initial review on one of my nominations and not pinged me, and I haven't noticed for several days. I don't care whether it's talk page notifications or pings, but one or the other should be tried before failing a nom, I think. I don't have a strong opinion on how many days we need to give. —valereee (talk) 14:36, 11 May 2020 (UTC)

Not to mention that in many cases, nominators sometimes disappear after nominating, which tends to happen in the case of student nominations. With that said, I have encountered cases where active and regular editors simply don't reply to talk page or ping messages despite being active elsewhere. In these cases, if the nominator is simply unresponsive despite still editing, I wonder if less leeway should be given or to otherwise treat these nominations as abandoned, because from experience in these cases the nominators rarely ever return or end up responding after all. Narutolovehinata5 ^tccsdnew 15:23, 11 May 2020 (UTC)

• There's also one thing that has been forgotten about in this section: it's not too uncommon for nominated articles to be put up for GOCE copyediting, which can takes weeks or even months. In these cases, I would suggest that the countdown not start until the copyedit request is either completed or rejected, and that the nominator should be informed of any updates to said copyedits. Narutolovehinata5 ^tccsdnew 13:06, 18 May 2020 (UTC)

Other LT solutions 2

The other three options received no opposition and don't require RfC. This is the final reading of the banns:

1. Go to 7 queues and preps.
2. Go to 2-a-days any time we hit 120 approved nominations and stay at 2-a-days until we're under 60 approved nominations.
3. Do 2-a-day weekends when we have more than 60 approved nominations.

—valereee (talk) 18:20, 9 May 2020 (UTC)

The final one, 2-a-days every weekend, may not be feasible if we're going through a very slow patch; it's important to have the flexibility to stay at once daily if it's getting hard to put together enough sets. I think there have been a few times when we've actually averaged under eight new noms a day for short stretches, as hard as that is to imagine just at the moment. So no objections, really, so long as we can be flexible if needed. As for the 7 queues and preps, we'll need to coordinate the switchover with Shubinator, but that won't be difficult. BlueMoonset (talk) 22:27, 9 May 2020 (UTC)

BlueMoonset, we can totally tweak that to 'Do 2-a-days every weekend whenever we're above X nominations." —valereee (talk) 23:28, 9 May 2020 (UTC)

valereee, I think for both of them it should be "X* approved nominations"; we could have 500 nominations in total, but if only (for example) 30 are approved and ready to promote, it's hard to build balanced sets. BlueMoonset (talk) 23:35, 9 May 2020 (UTC)

None of these methods will make a sufficient difference IMO. #2 might work if it was modified to say that we go to two sets per day any time we reach X number of hooks and stay at two per day until we reach Y number of hooks. If we did that, we would at least be acting before the backlog got totally out of control. But just going to two a day for a week is likely to see us only a short distance from the trigger number of nominations at the end of the week, and would put us in danger of constantly yo-yoing between one set and two sets. Gatoclass (talk) 13:51, 11 May 2020 (UTC)

You may well be right, Gatoclass, and I have my doubts about the third proposal—I do agree that once you start two-a-day per the second proposal, it's best to keep going until you get down to a certain level, whether it takes one week or three or longer. However, regardless of what we set here, we'll almost certainly be a ways off from the first implementation of either of the last two proposals, since we need to get the backlog down to normal levels before regular X and Y values come into play. As you point out, with the second proposal, we could keep on piling week after week if we're still above "X", or shift back and forth frequently, which makes planning for special occasion hooks a pain. My thoughts on the three after further reflection:

1. We've had all six queues and preps filled more than once over the past several days, and new prep set makers and queue promoters, so going to seven of each gives us more flexibility and makes us better able to stay ahead of the game if any regulars have to be away for a bit, without making the Queues page too long and unwieldy. I'm prepared to make arrangements with Shubinator to coordinate the switchover to seven should we decide to go ahead, since bot changes are needed along with many pages and such—I've got all the tasks planned out if we decide to go ahead—but I'd like more of a consensus than has been seen thus far. The original proposal was Cas Liber's.
2. I would prefer Gatoclass's construction of "hit X* and run until we we're down to Z*" over —valereee's "hit X* and go for a week exactly", even if the latter implies that we start up again immediately if we're still over X*. My proposal for numbers: if we hit 100 approved, we continue until we're down to 60 approved. Or it could be 120 and 60. But it we're only running for a week, it should be 100; 120's too high for that structure.
3. The two-a-days for Saturday and Sunday is something I'm more dubious about. If we decide to give it a try, then I'd put the Y* threshold at 75. No more than 80, certainly. If we're at 75 by Thursday noon, say, then we definitely go ahead for the upcoming weekend regardless of what happens later, because we need to plan ahead with any special occasion hooks. However, simplicity argues for either proposal two or three rather than both, and two is the only one that's structurally capable of getting the approved nom numbers back low enough.

I do think we are hitting (have hit?) the stage of proposal burnout: it's been going on long enough and there's so much text that many people have stopped engaging; I'm close to that point myself. BlueMoonset (talk) 17:06, 12 May 2020 (UTC)

BlueMoonset, I have no objection to going to seven preps and queues, as I have said, though I still think it won't make a lot of difference. With regard to where X and Y (highest and lowest number of nominations to trigger/untrigger 2 sets per day), I haven't given much thought to it and I usually think in terms of total nominations rather than approved noms. But if you want it to be on approved noms, I would have thought something like 150/80, as we can manage 150 before the noms stop transcluding and we don't want to go too low at the other end or a lack of variety can result. With regard to 2-per-day on weekends, I am not in favour, for the reason you yourself gave, which is that it would burn through too many noms in quieter times. But also, I think it would be pretty unfair to users to have some featured for the full 24 hours and others for only 12 on a week-by-week basis, and could also be open to gaming. Gatoclass (talk) 17:24, 12 May 2020 (UTC)

Gatoclass, thanks for the reply. Your points on the weekend option are well taken. There are too many disadvantages to it, and since the second option is so much more useful (and I don't think we should be doing both), I'm withdrawing my support for the weekend in favor of option two. (Pinging valereee to let her know.) However, I do disagree with you on the levels. Having a backlog of 150 approvals is simply too high: that's about 19 days of approved hooks at one a day, and we shouldn't be carrying that level of backlog. Being at 120 is a 15 day backlog; 100 is 12 to 13 days...and those numbers do not include the preps and queues that are already filled, which would be up to another 12 days (14 if we add the seventh prep and queue). If you counted approved plus prep/queue filled slots, then I could see something in the 150 to 200 range. As I type this, we have 184 approved plus 88 in queues and preps, or 272 in all (17 full days worth at two a day). Also, I can't imagine having any problem filling a prep set of 8 with 60 approved noms to choose from; indeed, 60 was a luxury back when I was an active prep builder.

The thing I really like about going to two daily at a fixed number and back to one when we drop below a lower fixed number is that we don't have to ask every time the backlog grows. Because of resistance, it always takes until the Approved page stops transcluding before grudging support is given, and it makes for longer-than-necessary periods of two a day every time. If we caught it earlier, and had a defined level for starting and stopping, it happens automatically. (We can always adjust the levels later, if these first choices don't work well.) BlueMoonset (talk) 20:02, 12 May 2020 (UTC)

BlueMoonset, I could probably accept 120/60, but I think 100/60 doesn't give a great enough span between the high and low points. Again, I don't want us to be yo-yoing too frequently between one set and two sets per day. Certainly, I'd want to be persuaded that 100/60 wouldn't cause that. Gatoclass (talk) 20:20, 12 May 2020 (UTC)

Gatoclass, I'm fine with 120/60 to start with. I've just changed "100" to "120" in the proposal. BlueMoonset (talk) 20:27, 12 May 2020 (UTC)

But if you want to look at other ways to reduce the number of nominations, here are a couple of others, one of which I suggested above:

1. For any QPQ review that approves a hook which turns out to be factually incorrect, the reviewer's own nomination for which he did the QPQ is disqualified, at the discretion of the user identifying the error. This would have the added advantage of forcing QPQ reviewers to check hooks very carefully to ensure they didn't lose their own nomination because of a sloppy review.

2. Create a directorship and appoint somebody to just give the flick to, say, 50 nominations whenever the total number reaches 350, based on hook and article quality. This would have the added advantage of improving the overall quality of nominations reaching the main page. You might want to have some sort of additional oversight for the sake of fairness, for example, the director could nominate 80 nominations for others to !vote on and the 50 which received the most !votes either to delete or keep would be respectively deleted or kept. Gatoclass (talk) 14:17, 11 May 2020 (UTC)

@Gatoclass:

Re #1 - Eh ... we have a learner class among our reviewers, and nominations are promoted more according to balancing a set than according a chronological waiting in line. What do we do if the error is only discovered after the nominator's hook is on the main page, while the flawed review is still not closed? In theory, it sounds good. But in practice, it has the possibility of creating a bottleneck.

Regarding #2, the obvious "director" to me would be @BlueMoonset:, the one who assists by making a list of the oldest nominations, and the one who seems to be more in tune of when we do - or do not - have so much backlog that we need to change the rotation schedule. But it adds more bureaucracy. — Maile (talk) 15:24, 11 May 2020 (UTC)

we have a learner class among our reviewers

Yes I know, that's part of the reason I said "at the discretion of the user identifying the error". And you'd probably want some sort of quick review process to ensure fairness. My post wasn't intended as a comprehensive description of such a system, just a posing of the basic idea.

What do we do if the error is only discovered after the nominator's hook is on the main page - Well, I actually covered that in my initial post, but deleted it for the sake of simplicity. If the nominated article had already gone through the system, you could simply ask the reviewer to nominate a nomination of his choice for disqualification. Or you could even accept a nomination of his choice from the outset, not necessarily the nomination for which the QPQ review had been done. Suffice to say that there are a number of ways to do this that would not cause any disruption to the ongoing process.

the obvious "director" to me would be @BlueMoonset: - again, my suggestion as to how one would go about creating a directorship was not intended to be definitive, there are many possible approaches. For example, we could have, say, five people elected who all nominated 20 hooks for possible deletion apiece, and then have a wider !vote on those. And so on. Gatoclass (talk) 16:30, 11 May 2020 (UTC)

I think the learner class comment is really important. Unlike other Main Page projects, DYK welcomes in the less-experienced and even first-time article writer. We’re easy(er) to figure out, and there are helper tools and helpful regulars. We leave messages on talk pages when a review isn’t going smoothly. Often reviewers will help fix an article or hook, then request a new review. DYK is the entry-level introduction to peer review. We don't want to make DYK impenetrable for anyone who doesn't nominate a hook a week. Ideally we'd keep all the newbs and encourage them in their first peer review process, and ask the more prolific nominators to maybe cut down (or learn to promote preps) while we're overwhelmed. —valereee (talk) 16:49, 11 May 2020 (UTC)

Asking people to check a hook for factual accuracy is hardly making DYK "impenetrable", indeed we already expect that (once somebody has five DYKs). The above suggestion simply adds a consequence for getting it wrong - or if you prefer, an incentive for getting it right. And it's not as if somebody is likely to suffer lasting psychological damage from having one of their hooks disqualified. But regardless, I did indicate that such a system would probably need some kind of quick-review appeal process to ensure fairness. Being a "noob" at DYK could be one possible consideration. Gatoclass (talk) 17:01, 11 May 2020 (UTC)

Gatoclass, one of their 50 hooks? No. Their first hook? They might never come back. —valereee (talk) 17:04, 11 May 2020 (UTC)

But it wouldn't be their first hook, we don't even require a QPQ for the first five nominations. If you think people might need more time before being held to account, fine, let them have ten hooks before they can be subject to disqualification. Again, there are any number of ways to fine-tune such a system. Gatoclass (talk) 17:13, 11 May 2020 (UTC)

Gatoclass, we can't be perfectionists here. The fact none of these is 'sufficient' to solve the problem doesn't mean they won't help. Totally open to nd stay at two per day until we reach Y number of hooks. The disqualifications idea to me seems extremely complicated and hard on new reviewers. I'd be willing to try a coordinator position who nominates surplus articles to be voted off the island, but not if that disproportionately favors DYK regulars instead of newbs. —valereee (talk) 17:03, 11 May 2020 (UTC)

Not "extremely complicated", at all. And I've long thought that we need more accountability for reviewers, sloppy reviewing has been a perennial problem at DYK - why do we have to do quality control at all? I've actually had this idea at the back of my mind for a long time but never bothered to propose it, but since you have persisted in asking for solutions to the issue of too many nominations, I thought it's worth throwing it into the mix. Gatoclass (talk) 17:23, 11 May 2020 (UTC)

I have, on occasion, disallowed a QPQ when it was inadequate, and required the nominator to provide a new, better review. This sometimes happened after tracing a problematic review back to the nomination where it was being claimed. I would be in favor of this happening more often, and while the penalty of disqualifying an otherwise perfectly good nomination due to a problematic QPQ feels harsh to me, if a nominator's QPQs come up short in this way too often, then that might be the way to go. Of course, there's the keeping track of problematic QPQs by reviewer in some central place, which gets to be a chore, but it could ultimately be a useful one. Regardless, Gatoclass's point is one I agree with: we need more accountability for reviewers.

Maile, while I appreciate the compliment in thinking I would make a good director, I have no interest at all in being a nomination hatchetman, deciding which ones get the axe because we have exceeded a certain number of noms, even with some criteria as a basis. I'm not even sure I'd want to be a part of a DYK that did that.

The third rail appears to be hook interest: some articles just don't have the ingredients to make a good hook, yet the nominations get passed anyway. Back when I was nominating, a number of articles I was involved in were never nominated because there just wasn't a sufficiently interesting fact to build a hook around, but rarely is a nomination failed on that basis. BlueMoonset (talk) 18:44, 11 May 2020 (UTC)

I think one factor for that is because the "hook interest" criterion is controversial in itself and different editors have their own interpretations of it, with some favoring a looser interpretation or doing away with it altogether and others preferring to use it more strictly. There's also disagreement of what makes an "interesting" hook in the first place, and it's not uncommon for one reviewer to think a hook fails it but another to say it passes it or vice-versa. Perhaps eventually we may need to have an RfC on what to do with that criterion as several nominations have stalled due to differing views on it, but it might be for another discussion separate from this. Narutolovehinata5 ^tccsdnew 00:54, 12 May 2020 (UTC)

Okay, I think we've banged out the three original suggestions into final form. Please take a look, even if you haven't so far. I mage them big above to hopefully let people know we're nearing the end of the discussion.—valereee (talk) 17:36, 12 May 2020 (UTC)starting new subsection

And those 3 would be .... what? There's a lot of yadda yadda yadda above, more than one set of which is numbered. Are they the ones in bold way, way up yonder? Please list here, in as short as possible, what those three would be. Will there be DYK user consensus required, or does it all rest on the 3 of you deciding? — Maile (talk) 02:58, 13 May 2020 (UTC)

subsectioning to make it easier to see

We're doing the best we can, here. I understand that the discussion has been absurdly long and that no one can keep up. No, no one is trying to make a unilateral decision excluding others. Yes, we are now looking for some sort of DYK-talk-user consensus for the items that don't require an RfC. These are the small potentially helpful changes that those of us still plugging away have been able to more or less agree on.

1. Go to 7 queues and preps.
2. Go to 2-a-days any time we hit 120 approved nominations and stay at 2-a-days until we're under 60 approved nominations.
3. Do 2-a-day weekends when we have more than 60 approved nominations.

—valereee (talk) 12:11, 13 May 2020 (UTC)

Thank you !! — Maile (talk) 12:14, 13 May 2020 (UTC)

Sure thing! I think what we're looking for at this point is not further discussion about whether these are helpful enough or suggestions of better ideas. We're just looking for minor tweaks that would make these something people are okay with or "No, no way will I ever support anything like this." —valereee (talk) 12:37, 13 May 2020 (UTC)

7 queues and preps

The following discussion 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.

---

• Support - as a simple and practical move forward. The possible flaw here, is when we go to 2-a-day, and the prep builders are trying to keep track of which will appear when on special dates. Or not ... since we have that convenient Local update times chart. Awaiting feedback here from prep builders. — Maile (talk) 12:52, 13 May 2020 (UTC)
• Support This only makes sense --Guerillero | Parlez Moi 16:03, 13 May 2020 (UTC)
• Support Some benefit, in terms of increasing our holding capacity; no obvious downside. Advantage of matching number of days in the week, too. Vanamonde (Talk) 16:25, 13 May 2020 (UTC)
• Support. Practical and no flaw that I can see: prep builders should always use the Local update times chart. While I think the "matching number of days of the week" is going to be a marginal benefit—among other things, which prep goes with which day can change every time we go to two-a-day and come back out—having the extra queue and prep will reduce the frequency that we're all full up in queues or preps or both, and adding only one of each will keep the Queues page at a reasonable size without getting too long. BlueMoonset (talk) 18:13, 13 May 2020 (UTC)

Note: I would not be in favor of a requirement that we assign specific queues/preps to specific days and/or require that switches from one-a-day to two-a-day (and back) be restricted to certain days in order to maintain such a system. BlueMoonset (talk) 13:01, 21 May 2020 (UTC)

BlueMoonset, why's that? One of the benefits I see is that we'd always know that during 1-a-days, Q1 is always Sunday (or Monday, depending on which we decide should be DYK's first day of the week. —valereee (talk) 17:17, 23 May 2020 (UTC)

Because it ties our hands. We've had special situations where we run extra sets of hooks in a day but only for one day (the Frank Sinatra centenary, April Fools, etc.)—won't be possible without making us "off" from the day. We'd have to delay switching back to 1 or up to 2. It's also not useful: how often are we attempting to run a hook on a Monday or a Sunday without an attached date? Special requests are almost invariably for dates, not days of the week. What's the benefit here? Why is it helpful that Queue 1 is always run on a Sunday or Monday? It seems useful enough to know that Prep 1 will run a week after Queue 1. BlueMoonset (talk) 17:53, 23 May 2020 (UTC)

BlueMoonset, it probably does make it simpler. At this rate I'm despairing of ever going back to 1-a-days, though, and this minute change isn't going to do much to help in our current situation. Have you noticed how many noms came in May 10-17, the most recent completed week? It's averaging close to 30 a day. Even 3-a-days isn't enough right now. —valereee (talk) 15:51, 25 May 2020 (UTC)

• Support. And to make it easier to remember, the numbering convention should be either 1=Monday or 1=Sunday per Names of the days of the week#Numbered days of the week (sorry Swahili speakers). As a Chinese speaker I'm obviously biased towards the former, but a good rational case for 1=Monday is that it's compliant with ISO 8601. -- King of ♥ ♦ ♣ ♠ 23:13, 13 May 2020 (UTC)
• Comment I would prefer 8 myself, rather than 7, because when we're running two per day as now, you end up with the odd situation of it taking 3.5 days to complete a round and then having the individual queues flip flop from morning to afternoon. An even number looks easier to maintain.  — Amakuru (talk) 23:26, 13 May 2020 (UTC)

  I think we should hold off on implementing this change until we're back to one a day. Actually, you just reminded me of something. If we implement the second proposal below (automatic rate adjustment), then two-a-days are bound to pop up from time to time, disrupting the canonical mapping from numbers to days of the week (whatever we decide it to be). We'll need to come up with some way to restore the mapping in a seamless manner, or we'd be mapping arbitrary numbers between 1 and 7 to days of the week, which I do not consider to be an improvement over the current situation of 6 queues/preps. I am withdrawing my support until this issue is addressed. -- King of ♥ ♦ ♣ ♠ 23:46, 13 May 2020 (UTC)

  I thought about this again, and because 14 is divisible by 7, the canonical order can be maintained so long as handovers are only done at the same time every week (e.g. Monday at 00:00 UTC). So we can use the following algorithm: every Saturday at 00:00 UTC, check if the current backlog size has hit the threshold (whether up or down). If it has, give everyone 48-hour notice that the rate is about to switch. Then the set that shows up Monday at 00:00 UTC will always be from Queue 1. Reinstating my support. -- King of ♥ ♦ ♣ ♠ 20:11, 14 May 2020 (UTC)

• Support Amakuru maybe at some point we could talk about how to manage the queues by going up to 8 during 2-a-days, then managing the move back to 7 so that Q1 during 1-a-days is always Sunday or whatever. —valereee (talk) 14:53, 14 May 2020 (UTC)

  @Valereee: yes that's fine with me, there's probably a way to do that somehow. The above was only an idea, I recognise that others have been thinking about this more than I have!  — Amakuru (talk) 15:12, 14 May 2020 (UTC)

• Support 7 days of the week, 7 queues sounds easier. And the extra prep/queue should help a bit with reducing the number of approved but not promoted noms. Joseph2302 (talk) 15:19, 14 May 2020 (UTC)
• Support, seven queues and prep sets is logical. It works great for when one set per day is used. I also note that two set per day is just awkward no matter how many queues or prep sets there are, at least one per day will be easier. Flibirigit (talk) 02:04, 15 May 2020 (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.

2-a-day after 120 approved

The following discussion 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.

---

• Maybe - although, 120 seems pretty low to be promoting 2 a day. Would like input here from our regular prep builders. — Maile (talk) 12:52, 13 May 2020 (UTC)

I too would like to have some input from the regular set builders on appropriate trigger levels, both high and low. As I said above however, I don't think we should be going any lower than 120 for the high trigger point. Gatoclass (talk) 16:00, 13 May 2020 (UTC)

I want to point out that the 120 approved number (or any other) is not meant to count the number already in queues and preps. As I type this, there are 82 hooks promoted there. To me, 120 seems high, but workable. BlueMoonset (talk) 17:56, 13 May 2020 (UTC)

From my experience, anything over 100 approved hooks feels like a riches to choose from, anything under 40 starts to make achieving balance difficult. But we can easily change these trigger points at any point if it turns out we've chosen numbers that are too high or too low. :) —valereee (talk) 15:19, 14 May 2020 (UTC)

• Placing automatic triggers makes the most sense for me. No idea what that number should be --Guerillero | Parlez Moi 16:05, 13 May 2020 (UTC)
• Support. Would support going lower on this limit, but it makes sense; that way there's no repetitive discussion every time this issue comes up. Vanamonde (Talk) 16:26, 13 May 2020 (UTC)
• Support. My reasoning aligns with Vanamonde's. BlueMoonset (talk) 17:56, 13 May 2020 (UTC)
• Support general idea of an automatically floating rate, oppose specific proposed numbers. Let's contextualize them a bit. Suppose we start off with 1 set of 8 hooks a day and 60 in queue, stable at a rate of 8 in, 8 out. The rate increases to 10 hooks a day, so the net increase is 2 a day, taking 30 days to hit 120. At that point we start promoting 16 a day and net -6 a day, so we're back at 60 after just 10 days. This oscillation between 1 and 2 sets of 8 hooks is great for handling massive surges like right now, but not for when the level of new noms stays consistently near some value between 8 and 16 per day. We need more granularity. I propose an intermediate level of, say, 2 sets of 6. Here's an example of what I mean:

Current Rate	Go up if backlog >	Go down if backlog <
1 set of 8	100	N/A
2 sets of 6	150	50
2 sets of 8	N/A	100

The specific numbers are subject to tweaking, but this is the gist of what I'm suggesting. -- King of ♥ ♦ ♣ ♠ 23:39, 13 May 2020 (UTC)

King of Hearts, DYK is under certain constraints these days which prevents promoting sets of fewer than eight; while we used to run six back in the day, eight is what balances the increased size of ITN and OTD on the main page. There has been strong resistance to going above eight here at DYK, so eight is where we stand. Doing sets of six simply is not possible. BlueMoonset (talk) 00:00, 14 May 2020 (UTC)

Do you have a link to the discussion about 6 vs. 8? Anyways, if it absolutely has to be 8 hooks then I would make the intermediate step be a set of 8 hooks every 16 hours (so 3 sets per 2 days). I am just worried that the jump is too wide and will lead to too much oscillation - and it's not really a problem that can be solved simply by stretching the thresholds. -- King of ♥ ♦ ♣ ♠ 00:09, 14 May 2020 (UTC)

No, sorry. We periodically consult with folks like David Levy, and they let us know when we're not balancing the page. If it gets too bad, they start inserting previously run hooks to get our section to balance the rest of the page, which is far from ideal. BlueMoonset (talk) 00:24, 14 May 2020 (UTC)

• Support in principle, though I'm still not sure what the trigger points should be, and am inclined to agree with Maile66 that 120 may be too low. Regardless, whatever numbers we adopt, we can of course change later if necessary. Gatoclass (talk) 12:14, 14 May 2020 (UTC)
• Support Seems the best option. Cwmhiraeth (talk) 13:00, 14 May 2020 (UTC)
• Support King of Hearts I see going back to 1-a-days after only 10 days (in cases like the one you describe) as an intended feature of these set trigger points. I'd much prefer doing a couple/three weeks of 2-a-days followed by a week or two of 1-a-days rather than doing 1-a-days for two months then having to do 2-a-days for 4 months to get out from under a massive backlog. We can manage 2-a-days for a short period; we can see a light at the end of the tunnel. It's when we start with a huge backlog and even going to 2-a-days see it decreasing almost imperceptibly that it feels as if it'll never end. —valereee (talk) 14:58, 14 May 2020 (UTC)

  Suppose that the rate is fairly steady at 12 new hooks per day for a long period. Then we can either run 12 hooks per day, or keep bouncing around between 8 and 16. I definitely prefer the former; if we do the latter and it becomes a predictable pattern then we might end up with people gaming the system to get their own hooks 24 hours. As for implementing a rate of 12/day, if running 2 sets of 6 is not possible as BlueMoonset says, then we can do 1 set of 8 every 16 hours. Having three tiers minimizes the disruption of switching between them IMO. -- King of ♥ ♦ ♣ ♠ 17:47, 14 May 2020 (UTC)

  King of Hearts, 12 hooks a day (either 6x2 or 12x1) is a non-starter; 6 hooks is too short, 12 is too long. —valereee (talk) 19:21, 14 May 2020 (UTC)

  Again, as I've said: 1 set of 8 every 16 hours. -- King of ♥ ♦ ♣ ♠ 19:22, 14 May 2020 (UTC)

  King of Hearts, also a non-starter as confusing. When we're on 1-a-days, the switchover is at X o'clock, everyone working DYK knows to be alert just before and after that time. When it's 2-a-days, it's Xam and Xpm. If we go to sixteen, we're constantly thinking, "When's the next update?" —valereee (talk) 19:34, 14 May 2020 (UTC)

  OK, we can start with the proposed 8 and 16. If the right model is a consistent 8 (or fewer) per day with occasional surges, then this would work perfectly. If the long-term average ends up being closer to 12, then we would need to revisit. -- King of ♥ ♦ ♣ ♠ 19:56, 14 May 2020 (UTC)

  Totally, I completely expect this to be revisited over the next few switches from 1 to 2-a-day and back. The people setting preps and moving queues will undoubtedly soon be figuring out whether the switches are happening more quickly than is productive, the approved noms are getting too low, whatever. —valereee (talk) 20:11, 14 May 2020 (UTC)

• Support. I'd even go lower on the threshold to 100. Flibirigit (talk) 02:06, 15 May 2020 (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.

2-a-day weekends

The following discussion 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.

---

• Oppose - Iffy and dependent on someone being around to change the rotation schedule twice during a weekend. Even more, if it extends past the first weekend. IMO, this is the least desirable solution. — Maile (talk) 12:52, 13 May 2020 (UTC)
• Oppose as it will create two classes of users on a more-or-less permanent basis, with some getting 24 hours exposure for their hooks and "weekenders" only 12, and would be open to gaming as set builders could fill the weekend sets with other people's hooks, leaving their own for weekdays. Gatoclass (talk) 15:55, 13 May 2020 (UTC)
• Oppose We really need to be going for all-or-nothing on this. Either it's 1 24 hour set or 2 12 hour sets in the interest of fairness. The C of E God Save the Queen! (talk) 15:58, 13 May 2020 (UTC)
• Oppose. I think one method for dealing with the backlog is sufficient, and prefer the upper limit to switch over to two-a-day to this. It also adds complexity in terms of timing and special occasion placement, which makes it less useful. BlueMoonset (talk) 18:04, 13 May 2020 (UTC)
• Oppose as per Maile and BlueMoonset. Another factor is that fewer people read Wikipedia at the weekend, so it would be better to run 2-a-day on weekdays and 1-a-day at weekends. Cwmhiraeth (talk) 12:58, 14 May 2020 (UTC)
• Very weak support This is not a huge favorite of mine, either, because of the extra work for someone. I like the idea of regularly doing some catch-up work, and I'm not too concerned about people gaming the system, but we could literally end up doing this every weekend, and that much futzing about with the settings is likely to generate some snafu somewhere with no one around to fix it. —valereee (talk) 15:02, 14 May 2020 (UTC)
• Oppose mixing between 2 different setups will get confusing. Let's find the best single solution instead. Joseph2302 (talk) 15:06, 14 May 2020 (UTC)
• Oppose, this is a clusterfuck waiting to happen. Flibirigit (talk) 02:07, 15 May 2020 (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.

Time to close the three proposals?

The three proposals have been open for two weeks, and it's been 12 days since the most recent !vote was added. Should we get someone uninvolved to close them? As noted at the start, these aren't RfCs, so they don't need to run a full month as an RfC would. Once they are closed, we can move forward on whatever is deemed to have a green light. Thanks. BlueMoonset (talk) 15:10, 27 May 2020 (UTC)

+1 —valereee (talk) 11:26, 28 May 2020 (UTC)

Can someone please close this? It doesn't require an admin or even a completely non-involved editor as it's pretty straightforward, but I think I'm too involved. —valereee (talk) 18:05, 3 June 2020 (UTC)

 Done ——Serial ^# 11:58, 4 June 2020 (UTC)

Coffeeandcrumbs, would you be willing to close discussion? —valereee (talk) 11:30, 4 June 2020 (UTC)