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.
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.
"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.
Leave a comment