Requested feature overview description.
To avoid improper use of parent/child chains, e621 should somehow make them harder to apply to new and existing posts.

Some uploaders and taggers use parent/child correctly. However, some of them seem to think that parent/child is how you tag a comic or series on e621. This causes extra work for others, to convert a parent/child chain into a pool. Here are some of the ones I've fixed over the past several months.

I kind of think that some uploaders to e621 think the parent/child feature is equal to FA's "Comic Navigation" feature, where if you put the submission IDs of the pages of a comic in the description field of an FA post, in the format [123, 456, 789], FA turns that into <Previous | Current | Next> links in the description. The correct feature match is e621's pools, but for whatever reason, some uploaders don't realize that.

There's a small chance that automation tools like PostyBirb are incorrectly creating parent/child relationships on e621 when they should be creating pools. I don't think any of the posts I've fixed have been like that, but it's a possibility. If that's happening, the action is probably for e621 to educate the tool authors on the difference between parent/child and pool, so the tool authors can modify their tools accordingly.

Here are some ideas, approximately in increasing order of intrusiveness and implementation work:

1. Add some help text next to the "Parent Post ID" box on both the upload and post-edit pages. The minimum thing it should say is "Don't use this for pages of a comic, use a pool instead". It might also link to a wiki page explaining the differences between parent/child and pool.

This is probably the easiest to implement - just some static text on a couple of pages.

2. Refuse to allow more than X posts in a parent/child chain. X is probably somewhere between 3 and 5. There are some image sets that large that really are similar enough to qualify as parent/child images - pants, no pants, no pants + boner, no pants + boner + cum - but anything past that, I feel, is someone trying to use parent/child for a series or a comic.

This is a little harder to implement, because the site would need to do a few database dips to "run the chain" of all the parent and child images in the string, before making a decision.

3. If someone tries to mark a post as having a parent, e621 should run a similarity check on both images, and disallow the change if the posts aren't (say) 80% or more similar.

If both of the posts have already been uploaded, the site should already have the similarity information for both of them, and can do a simple comparison. If one of the posts is new, though, the site would have to spend time computing the similarity data for the new post before doing the comparison. Maybe the action is that the site lets the new post be uploaded with the parent set, *then* does the check, and then either removes the parent ID from the child post, or applies a tag like "parent_child_review_needed".

4. Restrict adding a parent ID to a post to users with some level of privilege.

I'm not sure how hard this would be to implement, but it creates a greater workload for the volunteers.

Why would it be useful?
It would keep e621 users from manually having to convert parent/child chains to pools, when someone has tagged a comic or series with parent/child relationships.

For submissions that really are comics or series, it gives each image the "< prev next >" nav bar at the top, which is much easier to use than expanding the "child" link and clicking on the child post under the image.

The help-text idea, at least, would raise awareness of the pool functionality. Even when a user is uploading a single image, it puts it in their mind that there's a way to link multiple related images together, if they choose to upload images like that in the future.

What part(s) of the site page(s) are affected?
At least the upload page and the post-edit page, which are probably the leading places where someone can set a parent post ID. Any other pages where a parent post ID can be set would be affected too.

I strongly agree with 1, and somewhat with 2. I see way too many pools where the posts are all parent/child chained as well.
3 wouldn't work too well, as multiple versions of an image aren't necessarily algorithmically similar (sketch and colored versions, for instance). 4 just seems like an overreaction; post relationships are still quite useful, and restricting to privileged users would nearly entirely remove the feature.
A related feature that would make this much less of an issue would be something like automatically remove a parent if it links to the previous page in a pool. That way simply creating a pool would remove the unnecessary chaining. Perhaps that should be its own feature request, actually.

scth said:
A related feature that would make this much less of an issue would be something like automatically remove a parent if it links to the previous page in a pool. That way simply creating a pool would remove the unnecessary chaining. Perhaps that should be its own feature request, actually.

I don't know if I've suggested it in the forum, but one thing I've thought of is to have a button that converts a parent-child chain to a pool.

You find a post that has a parent or child and click the "make pool" button. The site runs the chain up and down, gathers all the post IDs in the chain, and then gives you a "new pool" form with the IDs already filled in, in what the site thinks is the correct order. You fill in the title and (optionally) the description, and maybe rearrange the order of the post IDs if the site didn't guess right. (It'd be helpful for the site to provide thumbnails on the new-pool form for this.) When you're all done, you hit "save"; the new pool is created and the parent-ID fields are blanked in all the posts concerned.

I wouldn't want this until after some of the stuff in my original post had been implemented - the idea is that the "make pool" button would be for cleaning up existing parent-child chains, and not as a way to undo newly-created ones. Also, the automation wouldn't always get it right. I know I've seen at least one pool that has 8 images in a sequence, but one of them also has a child (it has a dialogue and a dialogue-less version), so it's legit for there to still be one parent/child in the middle of the pool. The automation would probably just put all 9 images in a pool, in order, leaving the one parent/child to be manually reinstated later.

scth said:
4 just seems like an overreaction; post relationships are still quite useful, and restricting to privileged users would nearly entirely remove the feature.

They said, a user with a specific privilege, not a privileged user. Although I reckon it's an overreaction as much.

I actually wish it was easier to upload with parent/child relation lol, like bulk upload that can share source urls but maybe I am crazy...

Hmm, a great big red "yo, do you really intend to have more than one parent in this chain?" box that requires you to click just the one checkbox that has "yes" pointing at it, then confirm button? :P

Another thing is that it shouldn't be possible to create a post loop. In the 2023-07-10 db export there were 175 of them, of which I've fixed 18 so far.

scth said:
Another thing is that it shouldn't be possible to create a post loop. In the 2023-07-10 db export there were 175 of them, of which I've fixed 18 so far.

I wonder HTH you'd even find that without a database tool.

I don't really think it should be made harder. Unnecessary parent/child chains are annoying, but mostly inconsequential and easy enough to fix when noticed.

Somebody not adding a post as a parent when it should be is more harmful IMO. If you didn't know there's supposed to be a parent post, you're not going to look for it so you can add it as the post's parent.

kora_viridian said:
1. Add some help text next to the "Parent Post ID" box on both the upload and post-edit pages. The minimum thing it should say is "Don't use this for pages of a comic, use a pool instead". It might also link to a wiki page explaining the differences between parent/child and pool.

Something along the lines of this would be good, I'd like that, though people never really seem to actually read anything. It doesn't help with third-party upload tools either.

kora_viridian said:
2. Refuse to allow more than X posts in a parent/child chain. X is probably somewhere between 3 and 5.

I don't think outright refusing them is a good idea because there's somehow always exceptions. It would probably be a lot of work to implement this, like you said, with little reward.

kora_viridian said:
3. If someone tries to mark a post as having a parent, e621 should run a similarity check on both images, and disallow the change if the posts aren't (say) 80% or more similar.

I don't think this is a good idea, a post can easily have a low similarity % despite being a variant of the same image.

It's also valid to use parent/child relations for related images/sequences that are too small to be worth making a pool for:
post #4085561 post #4085563

kora_viridian said:
4. Restrict adding a parent ID to a post to users with some level of privilege.

This will almost surely create a larger workload for privileged users than having to clean up the occasional post that uses parent/child relations incorrectly. While not ideal, it would be much less time consuming to scan the DB Exports for incorrectly applied parents than having to trawl through everything posted and see if anything should be parented.