Adding new pool categories

Currently, we only have Series pools and Collection pools, and the latter are gradually being phased out. Considering how many different things can be pooled, I think we should create more categories for easier searching.

Here are some of the categories I think we should have:

Comics
Exactly what it says on the tin. Comic series of all kinds, mainly the kind with panels.

Sequential variant sets
Your basic variant set with the characters in the same poses but with some minor change / different dialog in each image.

Artbook/magazine scans
Self-explanatory.

Game card art sets
Collections of game artwork, mainly the kind from gacha games. I know there is some debate on whether we should have these, but these collections can get very large and there's usually some ordering system for them, so having pools for these can make it easier to make sure we get them all.

Sprite/tachi-e sets
Collections of game sprites, usually with characters in the same pose with different expressions. Since we are discussing how to keep these from affecting tag searches in topic #36155, I figure we should have a way to filter these from pool searches as well.

Series/Misc.
We should keep the current category as a catch-all for anything that can't be easily categorized. If we phase out all of the Collection pools, we can change it to Misc. to make it clearer.

This sounds like it'd be a decent way to start work on hopefully improving the user experience for these things in the future. i.e. if we do ever want a better comic reader, having the pools marked as comics already would mean some of the work can already be done. There wouldn't have to be any UI changes until this is implemented, and if something non-pool-y is chosen to store these collections instead they can still easily be migrated automatically.

Tangentially related discussions: topic #33400, forum #306473

+1

Anything that improves the functionality of Pools has my support.
Variant set has always been intended as a stopgap measure until more robust site functionality gets implemented.
This is a big changeover so adding more categories would be a great way to lay down some groundwork.

Also going to shamelessly plug my own suggestion again to add functionality to search by pool size: poolsize:5 / poolsize:..6 / poolsize:7..

This combined with filtering on pooltype which we already can, but with the flexibility of more categories: pool:comic / pool:sequence / pool:magazine / pool:sprite

Imagine being able to search -(pool:sprite pool_size:6..)
The power of large variant set, but tuned to your specifications.

GabrielWB said in forum #443572:
Also going to shamelessly plug my own suggestion again to add functionality to search by pool size: poolsize:5 / poolsize:..6 / poolsize:7..

If poolsize was a "free" meta tag, it could also be a possible solution to the tachi-e spam. poolsize:<5, for example, would remove all of the large variant sets from a search.

poolsize would probably be expensive and thus not 'free'. Adding new pool categories would be pretty easy but it is up to evazion whether it's something we want or not.

Talulah said in forum #443575:

poolsize would probably be expensive and thus not 'free'.

Out of genuine curiosity, so please do correct me if I'm missing something obvious here:

But don't pools already track how many posts they contain through a pool_size property?
For example: https://danbooru.donmai.us/pools/16322.json with at the end there "post_count":1537

In a similar vein posts already track how many tags they have been tagged with.
For example: https://danbooru.donmai.us/posts/4730647.json with "tag_count":40 and those are already searchable though the free metatag tagcount:

Making post_count searchable looks fairly straightforward and cheap from my "I read the MySQL Wikipedia page once" point of view.

GabrielWB said in forum #443595:

it's not just checking pool size, it's also that every post needs to be checked for membership in a pool, which involves a lot of reading across database tables (assuming posts don't have that information saved on themselves somewhere, am not familiar with danbooru's database schema. but even then you'd have to look up the pool itself to see how large it is). tagcount: is simple because all you need to do there is check the length of the tag array, which is already available on that post.

as an aside, there's also the question of which pool gets picked to be queried for the metatag in cases of posts that are members of multiple pools.

GabrielWB said in forum #443595:

Out of genuine curiosity, so please do correct me if I'm missing something obvious here:

But don't pools already track how many posts they contain through a pool_size property?
For example: https://danbooru.donmai.us/pools/16322.json with at the end there "post_count":1537

In a similar vein posts already track how many tags they have been tagged with.
For example: https://danbooru.donmai.us/posts/4730647.json with "tag_count":40 and those are already searchable though the free metatag tagcount:

Making post_count searchable looks fairly straightforward and cheap from my "I read the MySQL Wikipedia page once" point of view.

tldr is it's basically a query like this

SELECT * FROM posts WHERE id NOT IN (
  SELECT UNNEST(post_ids) FROM pools WHERE CARDINALITY(post_ids) > 6 AND category = 'sprite'
);

which is rather slow. This query is similar to what pool:series does already, which is a fairly slow search. Try scrolling a few pages through blue_archive pool:series.

edit: I should also say that "post count" isn't a real property, it's computed in Ruby by the post_ids array length. tag_count is quick enough since it's an index scan, but since posts can be in multiple pools we can't do something similar.

I'm not gonna comment on the tachi-e spam right now, and instead say that the idea of different pool categories like this is a wonderful idea. Especially in regard to game card art, which I semi-routinely upload.

Now to figure out how to kill Collection pools that people can't figure out how else to deal with...

Should probably just be "Card Art Sets" instead of "Game Card Art Sets". There's card sets that don't come from games, as well as card sets that aren't designed to be a game and are just collectible artwork.

PersonalFowl said in forum #443635:

Should probably just be "Card Art Sets" instead of "Game Card Art Sets". There's card sets that don't come from games, as well as card sets that aren't designed to be a game and are just collectible artwork.

The names are not meant to be final. They're just a way to describe what kind of categories we could have.

We could have just one category for all "collectible" art, but since gacha art is likely the most common kind of this art on the site, some users might prefer having non-gacha stuff like scans of physical cards in a separate category so they're easier to find.

Knowledge_Seeker said in forum #443617:

Now to figure out how to kill Collection pools that people can't figure out how else to deal with...

It's worth pointing out that we don't need to kill all collection pools, because what collection pools we'll have left, the ones too subjective to be tags, will be converted to votable tags (issue #6002) - forum #402803 and forum #419963 - or whatever the concept will end up being called in the end, since I imagine it would be confusing to have regular and votable tags.

It's all about figuring out which remaining collection pools will get that treatment, which ones should be nuked in general, and which ones should be turned into regular tags.

Damian0358 said in forum #443646:

It's worth pointing out that we don't need to kill all collection pools, because what collection pools we'll have left, the ones too subjective to be tags, will be converted to votable tags (issue #6002) - forum #402803 and forum #419963 - or whatever the concept will end up being called in the end, since I imagine it would be confusing to have regular and votable tags.

It's all about figuring out which remaining collection pools will get that treatment, which ones should be nuked in general, and which ones should be turned into regular tags.

The issue is we don't fully know the extent of what votable tags, or whatever it evolves into, will be. It was spoken about on the discord for a bit but more about the theorisation of the concept than what it will concretely turn out to be.

If Evazion ends up reading this he can correct me paraphrasing him but from my understanding of what he said then votable tags would end up being like user added pixiv tags or "thinking of them more like discord reactions rather than votable tags". Basically if someone tags it #funny and somebody else agrees, then they can also tag it #funny. You wouldn't be able to remove another person's "reaction". He mentioned them being mostly unmoderated aside from slurs. I'm left unsure on how converting pools to votable tags would actually work.

There's still 472 collection pools to be sorted, with a lot of these being probably too subjective for tags imo. I don't know to what state we need to get collection pools to but I fear there's still a lot of work to do before we can have some fancy new pool features if collection pools are blocking the development path.

Damian0358 said in forum #443646:

It's worth pointing out that we don't need to kill all collection pools, because what collection pools we'll have left, the ones too subjective to be tags, will be converted to votable tags (issue #6002) - forum #402803 and forum #419963 - or whatever the concept will end up being called in the end, since I imagine it would be confusing to have regular and votable tags.

It's all about figuring out which remaining collection pools will get that treatment, which ones should be nuked in general, and which ones should be turned into regular tags.

Alright, since votable tags are gonna become a thing, I suppose it is up to us to figure out which ones to sort into what category. Might be worth creating some kind of document to keep track of general conclusions or what not for the remaining Collection pools.

NiceLittleDan said in forum #443649:

I'm left unsure on how converting pools to votable tags would actually work.

my assumption is there would be a bur command or script that simply creates an initial "vote" by @DanbooruBot for each post in the pool.

if you mean how to decide which pools get converted, that's easy. i can name a few collection pools off the top of my head right now that sit right at the edge between "too subjective to be a tag, too taggable to be nuked". pool:Disgustingly_Adorable, pool:Beautiful_Smile, pool:Female_Gaze_Hetero, etc.