Requested feature overview description.
Currently, posts deleted as inferior inherit their favourites to the new, superior post. For consistency and other reasons, they should also inherit their upvotes and downvotes to the superior post as well.

Why would it be useful?
Upvotes affect user opinion in a way, even more than favourites. a green bolded number representing upvotes definitely changes the initial opinion of a piece over a normal number for favourites, which is useful for users who have never seen a piece, since while scrolling down, a big upvote count always says to a user; 'Stop and come look at me!'.

In relevancy to the current tumblr situation we have, lots of old posts are being reuploaded for superior versions, and I think therefore it is at least a little reasonable to assume that most longtime users would just skip past posts they've already seen, which could mean lost upvotes for reuploaded pieces, causing an image to not reach the same kind of success with new viewers as before.

And there is the issue of the use of order:score which arranges posts in terms of upvotes in a descending order. Without inheriting the upvotes, and assuming the above statements are actually true; posts that would have been seen more in these kinds of searches are just filtered to the bottom while objectively worse (in terms of upvotes) posts are filtered to the top. And as a side note to that, it also means that the same posts can't be found in the same spots using order:score, which may be a small problem with consistency.

With those factors in mind, it might be worth it to consider bringing upvotes over from posts deleted for inferiority. As it could have a real impact on how users engage with these old images that were potentially highly upvoted.

What part(s) of the site page(s) are affected?
Searching and viewing posts.

EDIT: https://e621.net/post/index/1/order:score%20bvats%20status:deleted%20ischild:true

using this search, you can see some posts that have high upvote counts don't get as many upvotes the second time around.

Oh yay, another one of these... give me a moment, let me link how many times this has been brought up.

Siral_Exan said:
Oh yay, another one of these... give me a moment, let me link how many times this has been brought up.

I searched for it, didn't find anything :S

https://e621.net/forum/show/216197

Here is one. Probably the most important, too. Specifically, from this comment down.

(Doubleposting because trololo)

The biggest problem, IMO, is that if this system excludes downvotes then it is unnecessary as vanity (whereas favorites serves a function), and if it includes downvotes then innocent posts can be inappropriately "downvoted" via luggage from an older post, or an inferior newer post.

A good leeway is to carry over votes, period, if said voting user also favorited the post. Votes and favorites are treated differently, after all, so if users are using them for the same intention then it is no harm to have them carry over.

If only upvotes are transferred, something like post #6268 would suddenly have a high score upon replacement.

Siral_Exan said:
https://e621.net/forum/show/216197

Here is one. Probably the most important, too. Specifically, from this comment down.

I can see the arguments for and against this feature. I can see that you believe that the image of the child should not be judged to the same standard as the parent, and I agree with that statement, but it is only really true in some circumstances that you mentioned. For example, a post may be downvoted to hell if it's like a 540x480 post with artifacts. It could be good, but the quality dictated it got downvoted. If the upvotes transferred to a bigger post where it is actually good due to the better resolution, it wouldn't be good for the new post. In this case, the system is flawed.

However, in the context of this tumblr incident, that argument doesn't always apply to every image. Most posts that get reposted are actually good sizes and qualities, but have found a slightly bigger image, maybe something released from patreon, or in a new trick to find a higher resolution. In this case, the system would actually benefit the new post, and keep it in its rightful place in the score listings.

However, I do feel like your point made here is actually kind of flawed. According to the uploading guidelines:

Low quality submissions: Highly visible artifacts, scribbles, low-quality photographs of traditional media (invest into a scanner, people!), 1000h in MSPaint images, computer generated mosaics, cropped images, anatomical diagrams, bad edits, screenshots, artificial upscales, etc. etc.

the chosen medium (image, video, flash) needs to be of a high quality

Therefore, we can see that the kind of image that would be downvoted for being low quality is literally not allowed on this site, and should be deleted for lack of quality standards. Therefore, the amount of occurrences where a post does not benefit from an improved system should theoretically be very small. I'm not saying it won't happen, but it is very likely that it will not happen.

That being said, I think there needs to be more discussion about this feature.

BlueDingo said:
If only upvotes are transferred, something like post #6268 would suddenly have a high score upon replacement.

I knew the grater would be used as an example... I wonder how many upvotes 69/11 has.

BlueDingo said:
If only upvotes are transferred, something like post #6268 would suddenly have a high score upon replacement.

Blacklists really can't save me from this kind of stuff...

On topic, would it be feasible to have the upvotes/downvotes be transferred with some sort of toggle?

Pendraggon said:
*snip*

And I've went from 0 to irritated in record time. Don't quote me for my old arguments[/b]. I am not them, especially when I say new things.

Siral_Exan said:
I knew the grater would be used as an example... I wonder how many upvotes 69/11 has.

239. Cheese grater only has 202.

Siral_Exan said:
And I've went from 0 to irritated in record time. Don't quote me for my old arguments[/b]. I am not them, especially when I say new things.

OK? Our opinions align, I think all votes should be transferred over. I didn't argue against that, Please be a bit more sensible, dude.

I think the only situation in which a post is downvoted because of something that has to do with the quality of the image (and with quality, guidelines prevent such bad images from appearing, so it's not that much of an argument) is in the case of censorship, a la post #929517 for example. I think there must be a better way to implement this feature for allowing improved pictures in situations like this.

Until this feature is implemented, you can reapply your own upvotes by searching votedup:whatever status:deleted and checking the posts for superior versions.

Pendraggon said:
OK? Our opinions align, I think all votes should be transferred over. I didn't argue against that, Please be a bit more sensible, dude.

...Really? I don't think you got any preaching rights for sensibility, you couldn't disconcern my argument from yours.

But to treat this seriously, I am not insensible for saying don't quote me from back then. Furthermore, listing the rules and guidelines does not favor your argument, you ignored the context they were written in to make such an argument. Far from being done, you ignored something I wrote and instead believe we're on same terms (we're not), and it's frankly bullshit for you to believe that.

But what I'm trying to say is: don't quote me if I'm saying new stuff. Pointing out official statements of any sort does not benefit any argument, I would argue to them instead of you. And I don't think you read me clearly, I disagree heavily on any stance of catering to upvotes or downvotes, unless under sincere (or, nice & logical) stipulations that are feasible and easy to perform.

Pendraggon said:
I think the only situation in which a post is downvoted because of something that has to do with the quality of the image () is in the case of censorship, a la post #929517 for example.

Censored/uncensored versions should not be merged. Just like clothes/no-clothes versions. So no-issue really.

The cases when something gets downvoted because of image quality only, and then a better version gets posted, are exceedingly rare. Some Google searches sometimes produce images 500x500 or less (such posts likely get unknown_artist as well), and there may be some human work involved, like somebody's scaled the image for whatever reasons and the original source is gone.

Pendraggon said:
I searched for it, didn't find anything

Don't worry, they all got closed as duplicates of a thread with irrelevant title and mostly irrelevant discussion for the first 10 posts or so.

Siral_Exan said:
A good leeway is to carry over votes, period, if said voting user also favorited the post. Votes and favorites are treated differently, after all, so if users are using them for the same intention then it is no harm to have them carry over.

I think that reasoning is based on faulty assumptions, it does not make sense, and that proposal would in no way come close to fixing the issue. Votes don't mirror favorites. They can't because votes have three states (e.g., up, neutral, down) but favorites only have two (e.g., "bookmark", neutral). Voting on and fav'ing the same post is a weak case for identical intent, and the intent of users' votes should be an irrelevant consideration anyway. Votes are points, not a survey.

BlueDingo said:
If only upvotes are transferred, something like post #6268 would suddenly have a high score upon replacement.

That's why it would be better to set a reupload's score to zero (i.e., ignore all old votes) if the inferior post was scored negatively. That would not be a functional change from the current system, where a higher res version of the cheese grater post would start anew at zero score. In the other thread, I had proposed that negative score be symbolically carried over but added as zero, like Score: 0(-15) + 20.

Give bad posts (i.e., negative score) the chance to be seen as bad again upon reupload, but allow good posts the dignity of carrying over their good score. Controversial posts (i.e., significant upvotes and downvotes)... well, if their score was positive then they would carry over all their votes, and if their score was negative then everyone sees if a turd can be polished.

The best that can be done for users who would flip-flop their score for a reupload would be to alert everyone who voted on an inferior post that a reupload has been posted and then ask them if they would like to change their vote, a feature which seems pointless for most.

Siral_Exan said:
And I don't think you read me clearly, I disagree heavily on any stance of catering to upvotes or downvotes, unless under sincere (or, nice & logical) stipulations that are feasible and easy to perform.

It seems disingenuous to oppose any new system that "caters" in either direction when the current system ostensibly discards the positive score from the overwhelming majority of deleted, inferior posts. The current system is a gargantuan net negative from that perspective.

For reference, we can look up the scores of deleted, inferior posts using delreason:inferior order:score, which will link to their superior counterparts.

hslugs said:
Censored/uncensored versions should not be merged. Just like clothes/no-clothes versions. So no-issue really.

I would still want most censored posts deleted, if not merged, when their uncensored counterpart surfaces, because the censored posts then cease to add value. Convenient_censorship is an obvious exception.

Well, I'm willing to make a bet: you all, the collective first party, will not make any effort in coding your perfect solution (and I invite you to prove me wrong). And, as your proposed solution is vanity and not immediately benefiting to the site, the higher powers are not focusing on making your solution. Why not actually do something about it than continue this hate-boner fest against the people who disagree with you.

So, make it yourself. I have (had) a foot in coding, enough to know my solution, albeit obviously half-assed, is simpler and more productive on a grander scale than your "problem" 's solution. I mean, is it really so hard to edit in a second action that operates off the first flag, being that favorited posts carry over.

And, if neither of ours gets any grace from anyone whatsoever, at least we can say we did something with our time. All this arguing in a circle will literally change nothing, we (both the collective first party and I) will still be hinging too much on the lack of action that'll occur.

Or in layman's terms, all I've seen out of this is users displaying fervor for something that they're all bark and no bite for. Please, prove me wrong...

Siral_Exan said:
Well, I'm willing to make a bet: you all, the collective first party, will not make any effort in coding your perfect solution (and I invite you to prove me wrong). And, as your proposed solution is vanity and not immediately benefiting to the site, the higher powers are not focusing on making your solution. Why not actually do something about it than continue this hate-boner fest against the people who disagree with you.

So, make it yourself. I have (had) a foot in coding, enough to know my solution, albeit obviously half-assed, is simpler and more productive on a grander scale than your "problem" 's solution. I mean, is it really so hard to edit in a second action that operates off the first flag, being that favorited posts carry over.

And, if neither of ours gets any grace from anyone whatsoever, at least we can say we did something with our time. All this arguing in a circle will literally change nothing, we (both the collective first party and I) will still be hinging too much on the lack of action that'll occur.

Or in layman's terms, all I've seen out of this is users displaying fervor for something that they're all bark and no bite for. Please, prove me wrong...

Do we need to know how to code to make suggestions?

Strikerman said:
Do we need to know how to code to make suggestions?

I can't tell you no... but I can say that you (all) don't know how to code (or similar), yet manage to provide an solution, I would drop any argument I may have and clap for them. I'm a man who recognizes determination.

Siral_Exan said:
Well, I'm willing to make a bet: you all, the collective first party, will not make any effort in coding your perfect solution (and I invite you to prove me wrong). And, as your proposed solution is vanity and not immediately benefiting to the site, the higher powers are not focusing on making your solution. Why not actually do something about it than continue this hate-boner fest against the people who disagree with you.

So, make it yourself. I have (had) a foot in coding, enough to know my solution, albeit obviously half-assed, is simpler and more productive on a grander scale than your "problem" 's solution. I mean, is it really so hard to edit in a second action that operates off the first flag, being that favorited posts carry over.

And, if neither of ours gets any grace from anyone whatsoever, at least we can say we did something with our time. All this arguing in a circle will literally change nothing, we (both the collective first party and I) will still be hinging too much on the lack of action that'll occur.

Or in layman's terms, all I've seen out of this is users displaying fervor for something that they're all bark and no bite for. Please, prove me wrong...

I don't know a thing about coding. I haven't even given much thought to the subject of this thread.

What I do know, however, is how to treat our users with respect, something you are failing to demonstrate here.

You are in no position to tell users what "the higher powers" are focusing on and are certainly in no position to use that assumption as leverage in an argument. At this point I'm questioning whether you are arguing to find out the right course of action, or are simply arguing to prove yourself correct.

How does one link to an old thread saying "This is important" then get upset when another user quotes your original stance? Really? Rather than clarify, your first instinct was to jump at their throat. All this "arguing in a circle" was not only started by you, it is being perpetuated by you.

Either tone your comments down or take a break to learn how. I'm beginning to get annoyed by these stalemated discussions that - without a doubt - give casual users the impression that the e621 forum crowd is a gated community.

EDIT: and don't DMail or message me anywhere about this. I am in no mood.

Knotty_Curls said:
I don't know a thing about coding. I haven't even given much thought to the subject of this thread.

What I do know, however, is how to treat our users with respect, something you are failing to demonstrate here.

You are in no position to tell users what "the higher powers" are focusing on and are certainly in no position to use that assumption as leverage in an argument. At this point I'm questioning whether you are arguing to find out the right course of action, or are simply arguing to prove yourself correct.

How does one link to an old thread saying "This is important" then get upset when another user quotes your original stance? Really? Rather than clarify, your first instinct was to jump at their throat. All this "arguing in a circle" was not only started by you, it is being perpetuated by you.

Either tone your comments down or take a break to learn how. I'm beginning to get annoyed by these stalemated discussions that - without a doubt - give casual users the impression that the e621 forum crowd is a gated community.

EDIT: and don't DMail or message me anywhere about this. I am in no mood.

Are you only referring to me?

Siral_Exan said:
Are you only referring to me?

Yes, because every other tone in this thread differs drastically in comparison to yours. Look up some interpersonal communication advice or something. This thread will go nowhere with this "us vs them" atmosphere that you, in particular, are creating.

This is not a suggestion. Take a break from this thread and take some time to think about how your posts affect other users.

And this goes for everybody: if anybody takes this opportunity to gloat, I will be exceptionally disappointed. Remember we are here to argue over what is right, not who is right.

Strikerman said:
On topic, would it be feasible to have the upvotes/downvotes be transferred with some sort of toggle?

Strikerman said:
Would it be feasible to have the upvotes/downvotes be transferred with some sort of toggle?

If yes, you'd wanna make it a staff only feature to prevent misuse.

BlueDingo said:
If yes, you'd wanna make it a staff only feature to prevent misuse.

Of course. I imagined that whoever was deleting the post would have the selectable option of transferring the votes.

Strikerman said:
Of course. I imagined that whoever was deleting the post would have the selectable option of transferring the votes.

I could see the misuse by staff, playing favorites, at the very least tons of complaints from users (and artists) coming in when they see some submissions getting bumped up and others not.

If this feature is implemented then itl have to be fully, not selectively, also considering the OP used the transfer of favorites as the basis of their argument which are implemented fully, not selectively.

Ruku said:
I could see the misuse by staff, playing favorites, at the very least tons of complaints from users (and artists) coming in when they see some submissions getting bumped up and others not.

If this feature is implemented then itl have to be fully, not selectively, also considering the OP used the transfer of favorites as the basis of their argument which are implemented fully, not selectively.

We have a function to not transfer favorites on deletion already. How often has that been abused in the past 4 years? The abuse potential is also completely negated by the fact that it would be a 4 clicks fix.
Restore submission, delete again, transfer this time. Boom, done.

Besides that there are a couple legit scenarios where it's beneficial to have the ability to turn it off. Most famous example would be deleting a crude edit of an image that turned a female into a dickgirl, the image is different enough that a transfer of votes and favorites is not optimal, but the parent child relation should not be removed.

NotMeNotYou said:
We have a function to not transfer favorites on deletion already. How often has that been abused in the past 4 years? The abuse potential is also completely negated by the fact that it would be a 4 clicks fix.
Restore submission, delete again, transfer this time. Boom, done.

Besides that there are a couple legit scenarios where it's beneficial to have the ability to turn it off. Most famous example would be deleting a crude edit of an image that turned a female into a dickgirl, the image is different enough that a transfer of votes and favorites is not optimal, but the parent child relation should not be removed.

How come favorites and not votes transfer in the first place anyway?

Pendraggon said:
How come favorites and not votes transfer in the first place anyway?

Because people look at their favourites?

BlueDingo said:
Because people look at their favourites?

Don't you use votes instead of favorites?

UnusualParadox said:
Don't you use votes instead of favorites?

Yeah, but I've already fix that issue. Too bad you can't unvote deleted images.

Pendraggon said:
How come favorites and not votes transfer in the first place anyway?

No idea, I assume because we're a very old danbooru fork. On the other hand, even the favorites transfer caused a lot of issues not too long ago with completely failing to run when a lot of faves where present, or even crashed the app server at times.
So while you guys may think it's a simple change in the code, it's much more complex.

BlueDingo said:

Pendraggon said:
How come favorites and not votes transfer in the first place anyway?

Because people look at their favourites?

Searching with order:score is pretty common afaik.
Resetting score on re-uploads prevents good posts from being discovered this way.

NotMeNotYou said:
So while you guys may think it's a simple change in the code, it's much more complex.

Some of us think it's unnecessary complex for no good reason.

BlueDingo said:
Because people look at their favourites?

Ah, sorry, I meant like, why don't they both transfer, rather than picking favourites over votes. Favourites should definitely transfer over, simply because it's a lot more personal than votes, people use their favourites for browsing so it's good that each picture can stay consistently in there.

hslugs said:
Some of us think it's unnecessary complex for no good reason.

It's not complex by choice, it's complex because it's required for it to function properly and ensure the server stays working for everybody at all times.

If we wanted to we could prevent input to the server on every single deletion and let it work in peace without anything else happening. With 700 deletions every day and 7 seconds per deletion on average for transferring favorites, and another 7 for votes (which is not realistic because votes are more complex thanks to 2 possible states per vote that need to be transferred) we'd be looking at 2 hours and 43 minutes of downtime daily.

Remember, we have to handle and synchronize multiple databases. A deletion of a post is far more complex on our server than just moving it to the trash can on your computer.

Edit: Just to be clear, I'm not talking about the complexity of outlining the task. Take all votes from the old post and apply them to the new one, if a user already voted on the new post discard the old vote. Implementing this task on the server so it doesn't fall over itself is far more complex than just flipping a switch or two.

hslugs said:
Searching with order:score is pretty common afaik.
Resetting score on re-uploads prevents good posts from being discovered this way.

What about the many good pre-existing images that have low scores (some examples here) and already go undiscovered because of it? The ones with high scores shouldn't be given special treatment over those ones and if they were good enough to get a high score in the first place, they will very likely end up with a high score again. And even if they don't, it's not much of a loss.

hslugs said:
Some of us think it's unnecessary complex for no good reason.

I'm guessing it's not a simple matter of setting the score to a predetermined number. Transferring all the votes across is probably the equivalent of every user who ever voted on that particular post clicking upvote/downvote at the same time, which could be hundreds.

NotMeNotYou said:
If we wanted to we could prevent input to the server on every single deletion and let it work in peace without anything else happening. With 700 deletions every day and 7 seconds per deletion on average for transferring favorites, and another 7 for votes (which is not happening because votes are more complex thanks to 2 possible states per vote that needs to be transferred) we'd be looking at 2 hours and 43 minutes of downtime daily.

Do not delete them. That's the point. Update the post instead of deleting it. Keep the id, keep all votes, keep everything in place except for the bare minimum that must be updated (like the image itself). It takes exactly 0 seconds to not-transfer the faves, and exactly 0 seconds to not-transfer the votes regardless of how many states there are, totaling 0 seconds of downtime daily.

IMO you are making your own lives difficult and doing damage to the site just because you are stuck at the wrong scope. It's not about how to transfer anything, the very need to do transfers is a consequence of a bad choice made earlier. The real problem is how to enable BV uploads. The way it is handled now, upload new and delete old, is only one of many possible solutions. And it's a crappy one. I've no idea why this choice was made, but maybe it's time to take a step back and re-think it. At this point I think it will be easier than trying to cling to this deleted as inferior nonsense.

Avoid having to delete long-lived posts. If posts must be deleted, it should be arranged so that the posts designated for deletion are short-lived and marked/flagged from the start whenever possible to deter users from tagging, faving or upvoting them.

hslugs said:
IMO you are making your own lives difficult and doing damage to the site just because you are stuck at the wrong scope. It's not about how to transfer anything, the very need to do transfers is a consequence of a bad choice made earlier. The real problem is how to enable BV uploads. The way it is handled now, upload new and delete old, is only one of many possible solutions. And it's a crappy one. I've no idea why this choice was made, but maybe it's time to take a step back and re-think it. At this point I think it will be easier than trying to cling to this deleted as inferior nonsense.

Do you honestly think we haven't already internally talked about options like that?

Updating submissions is unsupported and creating the support would require us to change almost every part of the software that deals with submissions. I've asked Kira about a functionality like this last year and the response was that it's not possible on our current back end.

NotMeNotYou said:
Updating submissions is unsupported and creating the support would require us to change almost every part of the software that deals with submissions.

Sounds really strange, Rails are sorta made to make it easy. So sure since it's not implemented I assumed it wasn't discussed.

Well alright. Time to dig into Danbooru sources then, and maybe post something more substantial than just suggestions.

hslugs said:
Sounds really strange, Rails are sorta made to make it easy. So sure since it's not implemented I assumed it wasn't discussed.

Well alright. Time to dig into Danbooru sources then, and maybe post something more substantial than just suggestions.

To clarify, it is easy to do something as simple as update the internal image a post points to. That's all fine, it takes a few lines of code. What doesn't exist is the supporting framework that was discussed. Where images have pending replacements, a history of replacements and other supporting features that formalize replacing images with newer versions. The scope expanded pretty heavily. It isn't that it's not possible, just that it is a big big project, and other technical debt makes it questionable as a first choice. Transferring properties between posts is easier on scope, as there are already systems in place for transferring properties between posts on the delete action. Expanding it to support more properties isn't out of the question. It's then a question of exactly how conflicts are resolved, which is a social debate as much as a technical one. It's also debatable if this is shooting ourselves in the foot or not, which is why I've stayed out of this feature discussion so far. One takes a lot of time to build and test and then arrange for migrations, the other is probably the wrong direction but resolves the issue for the time being. I'm anything but infallible and have limited time, so I simply haven't decided yet how to tackle it.

A lot of the nuance of these discussions tends to get lost when they are summarized. Rarely is the answer just "It's not possible."

KiraNoot said:
What doesn't exist is the supporting framework that was discussed. Where images have pending replacements, a history of replacements and other supporting features that formalize replacing images with newer versions.

Yeah a separate queue for updates would be a great solution but that's just too much work. There's an idea which I think is simple enough to be feasible:

forum #235492

No new tables, no migrations, just exchanging the links between two Posts. The post being deleted serves as undo buffer this way, so it's reversible. And it stays completely on the admin side.

hslugs said:
Yeah a separate queue for updates would be a great solution but that's just too much work. There's an idea which I think is simple enough to be feasible:

forum #235492

No new tables, no migrations, just exchanging the links between two Posts. The post being deleted serves as undo buffer this way, so it's reversible. And it stays completely on the admin side.

It is worth investigating, but I can't guarantee that this will be a good solution. It also doesn't solve the problem of merging new and old favorites/votes/comments. It just favors the old content instead of the new content. There is also potential problems with uniqueness and race conditions during the swap that absolutely have to be resolved and accounted for.

KiraNoot said:
It also doesn't solve the problem of merging new and old favorites/votes/comments. It just favors the old content instead of the new content.

Yeah the point is to make it so that the new post has no faves/votes/comments worth merging. The better version gets posted, flagged immediately and deleted (after exchanging the links) within days with any votes it managed to get. Supposedly the users will be smart enough to not fave or upvote flagged posts, and would go straight to the parent post instead.

Races definitely need some thinking, though I guess it shouldn't be much different from two users editing the same post at the same time.