Comments

Five himbas, two fatties (affectionate) and Dantsu Flame.

I thought I was looking at the doomerboy wojak lol

Pretty sure this and the child post are a reference to Darth Traya from KOTOR2, adding tags

Apathy is death.

Aether's wives?)))

rare serious Digitan moment

Agnes Digital's 2003 Yasuda Kinen win was pretty crazy
It's their 6th G1 win and set their second G1 race record, breaking Oguri Cap's 13 years record at 6 years old after recovered from stress fracture.
Undeniably one of the greatest JP horse.

Don't forget this silly goober is a descendant of none other than Secretariat himself.

Also happened to look like a miniature version of him too. (especially when compared to other Big Red descendants with uma counterparts)

NNescio said in comment #2584712:

Don't forget this silly goober is a descendant of none other than Secretariat himself.

Also happened to look like a miniature version of him too. (especially when compared to other Big Red descendants with uma counterparts)

Then there's Ebayan who, while isn't exactly looking like Big Red, is inbred to Secretariat as his name shows up on both sides of his pedigree

Jnglmpera said in comment #2584775:

Then there's Ebayan who, while isn't exactly looking like Big Red, is inbred to Secretariat as his name shows up on both sides of his pedigree

Ebayan is even bigger and taller than the Big Red.
He's straight up HishiBono sized but slightly shorter and stockier.

17 revisions is insane.

If absurd revision numbers should be pooled, then it should be in the wiki for revision. Though I don't think there would be any benefit.

ANON_TOKYO said in comment #2584872:

@hdk5 pool.

If this is because of the comments under post #10931745, there are much more productive ways to revive the pool vs. parent debate.

LQ said in comment #2584893:

If absurd revision numbers should be pooled, then it should be in the wiki for revision. Though I don't think there would be any benefit.

Help:post_relationships states the following:

When NOT to use Post Relationships

• Large collections of posts.

This seems to be the basis of the argument that posts with many revisions should be pooled instead of parented. However, it doesn't say how many is too many to parent. Personally, I don't see a problem with having around 10 children. I can see 8 to 12 in the thumbnail navigation bar, depending on their aspect ratios, without having to use the scroll bar. I guess that could be used as a limit since once there are enough images to activate the scroll bar, the navigational benefits of the bar are nullified for those later posts (though you could still navigate the earlier posts just fine).

Either way, we definitely need a thumbnail navigation bar for series pools as well. And maybe also a way to jump to the pool page a post is on instead of having to go to the first page each time you want to view the thumbnails on the pool page.

Truly a moment of all time. I'll ignore LQ's comment because of the environmental impact of AI.

Blank_User said in comment #2584903:

If this is because of the comments under post #10931745, there are much more productive ways to revive the pool vs. parent debate.

Not what's happening here.

Rulelawyering is pointless here. If a variant set of 10 posts gets pooled because that's a bitch to navigate because parent/child UI sucks, then 10 revisions doesn't suddenly make it not annoying to navigate. HDK also has a history of not pooling when he should (comment #2571588)

"Large collections of posts" is way too broad to be meaningful (does any set of relationships count as a collection?), especially if it conflicts directly with a "when to" reason (unless "when not" overrides "when to").

Ideally, "large" should be quantified, and the Danbooru code should place a smaller hard cap on new post relationships (deprecating large post relationship collections). So Danbooru could be changed to prevent updating a post to have more than 10 children. A software config limitation would stop the excess children and reduce the need to learn from the right wiki.

LQ said in comment #2585101:

"Large collections of posts" is way too broad to be meaningful (does set of relationships count as a collection?), especially if it conflicts directly with a "when to" reason (unless "when not" overrides "when to").

Ideally, "large" should be quantified, and the Danbooru code should place a smaller hard cap on new post relationships (deprecating large post relationship collections). So Danbooru could be changed to prevent updating a post to have more than 10 children. A software config limitation would stop the excess children and reduce the need to learn from the right wiki.

I think just updating the wiki would be better than setting hard limits, at least for now. The lack of clarity has, to summarize topic #34320, resulted in varying opinions on what should be pooled or parented. Each one has its own advantages and disadvantages, and I think making those clear will help users get a better sense of which one to use. If the wikis only explain how to pool/parent and don't explain why these guidelines are in place, then it's just more likely to devolve into rules lawyering. And while lowering the cap would solve this to some extent, it would also remove our ability to make exceptions for certain cases if it turns out a large number of children is somehow more beneficial.

Basically, this needs to be discussed in the forums instead of isolated skirmishes in the comments, and we need to start with softer measures such as coming to a consensus on which personal criteria should be adopted.

Awooga