Danbooru

Creating a tag for large variant sets

Posted under Tags

BUR #31088 has been approved by @nonamethanks.

mass update favgroup:35578 -> meta:large_variant_set
mass update favgroup:35579 -> large_variant_set
create implication large_variant_set -> variant_set

The variant_set tag is currently useless for hiding large sets of similar images, as users are adding it to any image with even a single alternate version. As such, a new tag that will actually serve this purpose is warranted. The name large_variant_set is fairly simple, and will apply to all sets with at least 6 variants. I chose 6 since the default amount of posts per page is 20, meaning it's the point where a single variant set would make up over a quarter of the posts on a single page.

The two favgroups in the BUR contain all variant_set posts that are grouped using the parent/child function and have at least 6 posts in the set. Special thanks to I_Copy_Gex from the Discord server, who helped automate that process while also accounting for things like duplicates, or post #8124447 (5 child posts, but the set is only 4 posts strong).

I'm aware that a number of variant sets, especially larger ones, are pooled rather than parented, but because they don't use the parent/child function they're more difficult to find and therefore tag. I imagine they will have to be added manually, so if you remember any and this BUR is approved, feel free to tag them.

ANON_TOKYO said:

I'm personally not opposed to having the normal variant set exclude 2-post and maybe even 3-post sets, but any higher number would feel weird. Aren't these tags a bit of a bandaid solution to something that could/should be implemented in the site itself though?

We already have child_count:>3 etc, but it's so slow that it's unusable due to timeout at the moment.

nonamethanks said:

We already have child_count:>3 etc, but it's so slow that it's unusable due to timeout at the moment.

FWIW the ugly script I wrote can easily be repurposed to change how the tag is currently used. For the favgroups in BUR #31088 it just did a search for variant_set children:>4 and then filtered out all posts that didnt have 5 or more children tagged variant set. It still leaves untagged posts but this is difficult to automate.

BUR #31276 has been rejected.

mass update variant_set -favgroup:35578 -favgroup:35579 -> -variant_set
mass update favgroup:35578 -> variant_set
mass update favgroup:35579 -> variant_set

AngryZapdos said:

BUR #31088 has been approved by @nonamethanks.

mass update favgroup:35578 -> meta:large_variant_set
mass update favgroup:35579 -> large_variant_set
create implication large_variant_set -> variant_set

The variant_set tag is currently useless for hiding large sets of similar images, as users are adding it to any image with even a single alternate version. As such, a new tag that will actually serve this purpose is warranted. The name large_variant_set is fairly simple, and will apply to all sets with at least 6 variants. I chose 6 since the default amount of posts per page is 20, meaning it's the point where a single variant set would make up over a quarter of the posts on a single page.

The two favgroups in the BUR contain all variant_set posts that are grouped using the parent/child function and have at least 6 posts in the set. Special thanks to I_Copy_Gex from the Discord server, who helped automate that process while also accounting for things like duplicates, or post #8124447 (5 child posts, but the set is only 4 posts strong).

I'm aware that a number of variant sets, especially larger ones, are pooled rather than parented, but because they don't use the parent/child function they're more difficult to find and therefore tag. I imagine they will have to be added manually, so if you remember any and this BUR is approved, feel free to tag them.

Six is a very low number. Seems more that the existing variant set tag should be cleaned up and perhaps large variant set should be used for things with 20+ variants. I hope this works right.

In its current form, I agree that variant set is starting to become useless.
So I support the creation of large variant set or alternatively slimming down variant set and updating its definition, with a light preference for the second one.

However the reason I created this tag to begin with was the imho bigger underlying issue and that is the overuse of the parenting system.
I've ranted spoken about this before in topic #22621 which also has the previous discussion about this tag, but eh... it's a friday, so here we go:


Current situation

The parenting system is at the moment used to keep a track of a lot of things:

The problem

post #8102062

Unbreakable said:

This image is supposed to be second but someone uploaded them out of order.

The order of the children of a parent is determined by the upload time of a post. The newer the image, the further it is shifted to the right.
At the moment, the guideline is to make the first image the parent, all later images become children, and add branch children for each variation.

Making adjustments to an existing collection or adding new/better images is outright impossible without screwing things up.
Thankfully, we already have a solution for collections of related images that are in a specific order. Quite an old one actually: Pools.

My proposal for the long(er) term
  • Create a third pool category besides Series and Collection. Let's call it Variants for now. This way these posts become a category on their own and become searchable just like Series and Collections now. pool:variants
  • Add functionality to search by pool size. pool_size:5 / pool_size:..6 / pool_size:7..
  • (Bonus Credit) For better UX: Add a thumbnail view to the Pool header on post pages just like parent/child posts have now. This should make browing pools even easier.

All variant sets that are three posts or larger (because at this point the order cannot be controlled anymore with the parenting system) should go into a Variants Pool.

  • This would give space for the other usecases for the parent/child system without immediately breaking a collection the moment a duplicate is uploaded.
  • This would make variant set far more searchable than with a tag.
  • This would solve AngryZapdos' usecase for wanting to limit variant set visibility. -(pool:variants pool_size:6..) You can even change the limit on the fly!
  • This would solve my usecase of wanting to occasionaly hide all variant sets while searching. -pool:variants
  • And most importantly: This would help in nonamethanks' noble quest of eliminating superfluous metatags by making variant set redundant and eligibile for a deprecation.
TL;DR

Trimming down variant set should be done, but we need something done for the longer term. See proposal above.

ANON_TOKYO said:

Aren't these tags a bit of a bandaid solution to something that could/should be implemented in the site itself though?

say it again for the people in the back

GabrielWB said:

In its current form, I agree that variant set is starting to become useless.
So I support the creation of large variant set or alternatively slimming down variant set and updating its definition, with a light preference for the second one.

... snip ...

TL;DR

Trimming down variant set should be done, but we need something done for the longer term. See proposal above.

say it again for the people in the back

Do you have solution for where you only want one or 2 of the images from a large variant set to come through? Because sometimes these gigantic ones drown out the search completely

Changli said:

Is it reasonable for us to garden out posts tagged variant set with only 2 images so we can avoid another tag and then establish policy about how the tag should be used in the tag's wiki instead? variant_set is:parent child_count:<=1 is 144 pages (5745 results) which I believe includes all pair posts (only 2) that are using variant set. Gardening this leaves only posts with 3 in a set having variant set.

If we're proposing a new tag for larger ones, I don't think we should remove the old tag from smaller ones. Ideally, something gets implemented in the site, in which case these tags can also be used to automatically garden a bunch of posts.

1