Danbooru

[Feature Idea] Manage aliases/implications based upon usage

Posted under Bugs & Features

Pinging @albert as this topic touches upon database loads.

This issue is presumptive on the notion that more aliases/implications == additional load on the server and increased query time overall.

The question has been brought up before about how much a strain the current set of aliases/implications have on the system? How much more can be added before there is a significant degradation, i.e. the red zone?

Mitigation ideas

All of the following ideas would use the user base as a resource instead of relying on automatic tagging by the server.

1. Psuedo aliases/implications

These would follow much the same idea as the alias/implication system (voted on by members and approved by Admins), but would not be part of the actual alias/implication table, thus shouldn't degrade the system. Users could check some kind of index that would show how many posts require tagging for each alias/implication. Reportbooru could also be used for this, instead of using the resources on Danbooru.

Since this is a different system than aliases/implications, mass updates could also be incorporated into it so that implications that are impossible to do, such as the mass update as part of BUR 957, could also be done. However, this option would require the most amount of code development.

2. Retirement system for aliases/implications

When aliases/implications no longer meet a certain utilization threshold they could be retired, either automatically or manually. Just to give an example of how little some implications are used, the following are some of the velocity metrics for the past year.

Q1: 3 posts
Q2: 31 posts
Q3: 202 posts

804/5717 implication antecedents have had 0 utilization for the last year.

The benefit of this is that it uses most of the current system that exists. However, it would not be able to support mass updates (like BUR 957) that also need regular gardening. Also, if they are still in the same table but no longer active, would the server load/strain be the same or would it be less?

3. Forum topic used to track regular gardening tasks

Instead of having official support for this, a topic could be used to list all of these gardening tasks. Having things like the post search, and what tags to add for that search. These should be no-brainers, i.e. if you run this search and posts show up, then add such and such tags until posts no longer show up.

The benefit to this approach is that everything needed is already available. The difficulty lies with how best to present it, how to update it, and how to authenticate it.

As they are forum posts, there would be limited ways to show the post count, so users would have to follow each post search link which would be laborious. One way around that would be to have a bot update the post count, but that would require that the bot owner either be the OP or a Moderator. I say OP because I believe that for the best presentation everything should go in the OP.

Authentication might be the most difficult aspect of this approach though, i.e. how to determine what gets put into the list, and who gets to put it there, along with any other coordination that might be required.

Thoughts?

Even if the size of the alias/implication table is not an issue (???), there is still the problem of what do do with BURs like #957, or others that are considered to small to alias/implicate. If anyone has other ideas, please feel free to share.

Edit:

Created issue #3740.

Updated

I wouldn't worry too much about the performance impact of having too many aliases, but there definitely is some sort of cognitive burden of keeping track of everything. I like the idea of retiring older relations as they see less use. It's fairly easy to track usage.

1