Based on your current proposal, we could put it to a vote as I do see this proposal is committed to time protection. In case you're willing to reconsider elements of your proposal, I'm going to mention a few things on the latest implementation specifications:
The Initial Cull:
a. Remove all fragments from the pool that are more than 3 weeks old and have a True Score in the bottom 95%.
If we take score as the method for culling, preserving 3 of the latest rounds of fragments doesn't make sense - they've achieved their true score at the end of each week. All this does is bias culling to preserve recent rounds worth of fragments in the to-be fragment pool, rather than actually using the scoring system as intended.
Ongoing Cull:
a. At the end of each voting period, remove the 350 fragments with the lowest True Score that have been around for more than 3 weeks.
If we have a fragment pool of +-1350 fragments, we're in actuality committing to culling the oldest fragments. This is because we'd be 'time protecting' the latest 3 rounds worth of fragments (1050 pieces, or 3x350 - you state 'more than 3 weeks old'). Have I misunderstood something here? Clarification would be highly appreciated so I don't misunderstand what's being proposed. Irrespective of this, culling (be it initial/ongoing) by true score makes sense and is consistent with current system implementation.
In terms of culling 95% of fragments, we'd be looking at an even smaller pool than initially stipulated in your proposal - I believe your original proposal stated 80%. The current pool size (including the round that's just started) is 6808. If we deem the latest round (Round 21, 03 March 2021) of fragments untouchable, we'd be looking at (0.2*6458)+350 ~= 1642 fragments. Ultimately I'm not sure whether this difference is negligible but I'd err on the side of caution with culling too much! While I believe the 'sweet spot' for pool size is ultimately an arbitrary number, cutting it too aggressively might negatively impact voting experience in terms of frequency of pieces (we already experienced this in the earlier weeks of Botto, even after a bugfix). We should also be mindful that this isn't a simple case of voters cycling through fragments until they've seen every piece.
Combined with the 3 round time protection element, we'd also be retroactively culling many fragments that already have normalized true scores (because there's ample voting data on them) for the sake of protecting fragments that have lower, more volatile true scores. The current trend with more recent round fragments is that their (current) true scores will further normalize at lower values, as seen with older fragments from earlier rounds. A simple reason for this would be that some 'get tired' of seeing the old crowd favorites, so they vote on newer fragments. Between the lines, that means we'll be preserving newer fragments that are already 'deemed' ugly by the community.
Alternatively put, older fragments that we can dub 'crowd favorites' have normalized scores at lower values relative to newer fragments, meaning newer fragments with fresher true high scores are prioritized in being shown 80% of the time. This means older fragments have their 'backs against the wall', while newer fragments have initially higher true scores that are volatile and more susceptible to normalizing at lower values anyway (unless they are deemed incredible fragments and have a very high appreciation rate over an extended period of time).
Looking at 3 week/round time protection in isolation: This discredits the scoring system we've used for 20+ weeks where the clear noticeable issue is that we are taking too long to score the most recent fragments, not that the system doesn't work. The current system already has time protection baked into it: Newer fragments from each week are scored by default at 100, meaning their visibility is high prioritized at 80% throughout the earlier stages of the week. This in itself is time protection: we want to give newer fragments a 'fair' chance at being reviewed by the community in and through their votes. Even then, when true scores of the latest fragments are eventually attributed, they are likely to be higher relative to older fragments (see previous argument). This means that without the time protection you've proposed, the system will cull an old fragment anyway - unless there is clearly something worse from the newer batch of fragments to take its place.
I apologize if this post comes across as convoluted, I'm happy to try clarify what I've written (also wrote this pretty quickly so I hope it doesn't read as gibberish). My TL;DR here is we should not commit to other measures of time protection as the system does accommodate for it already.
