Greetings!

Long story short, we have a bunch of pending alias and implication requests that have been languishing in limbo forever, and are sometimes interfering with new requests. In order to help get rid of them as well as more easily make new requests we've decided to cut the fat, so to speak, and mass reject all old ones.

What will this impact? Only the aliases and implications themselves, anything rejected can be requested again as is, or with changes to fit other things that have been implemented since the initial request.
Forum posts and all discussion surrounding any requests are not affected, and will persist in the forum.

If you have any requests you would still like to have discussed for approval you can either bump the corresponding forum thread and give a reason why it should be approved, or if you miss the deadline just remake it.

The current plan is to hit the button on everything requested in 2016 or earlier on the first of June.

We will also slowly be working our way through to 2022, with one year per month, meaning the next thread like this for 2017 will be opened in June.

Will this be a continual occurrence once the 2016-2022 requests are wiped clean? For example, will there be an automatic rejection timeline of future requests similar to how post approval works?
If so will there be any problems with some requests being being in a continual state of creation/rejection due to never being reviewed (presumably because alias/implication approvals could be low on the priority list)?

We currently don't have any plans for automatic rejections in the future, and we're hoping with more people joining staff we can keep on top of future requests. Though if it ever becomes a problem we might do similar again.

Although I'd hate to see many valid requests become deleted (for me, they'd at least have a combover before they go,) I think this is a great idea!

socklover5 said:
Although I'd hate to see many valid requests become deleted (for me, they'd at least have a combover before they go,) I think this is a great idea!

I have to agree with socklover5 here. It'd be a good idea to give valid requests at least a combover before rejecting them outright.

Here are the implications affected by this move.
https://e621.net/tag_implications?search[order]=created_at&search[status]=Pending&search[created_at]=2010-1-1..2017-1-1
There are no pending aliases from 2016 left.

If you believe that any of these are still valuable, please bump their respective threads.

bitwolfy said:
Here are the implications affected by this move.
https://e621.net/tag_implications?search[order]=created_at&search[status]=Pending&search[created_at]=2010-1-1..2017-1-1
There are no pending aliases from 2016 left.

If you believe that any of these are still valuable, please bump their respective threads.

Awesome, I'd love to help out!

transistorprevadity said:
I have to agree with socklover5 here. It'd be a good idea to give valid requests at least a combover before rejecting them outright.

Thank you, TransistorPrevadity! I'm glad we agree on this.

kora_viridian said:
Suggestion: when the thread for June is made, covering aliases and implications proposed in 2017, include search links like this in the initial thread post. That will make it easier for people to see which items are on the chopping block.

Question: Was the up/down/meh vote system introduced before 2016? I kind of think it was, from looking at the earliest ones on the 2016-and-before list - they all have at least a few votes like that. (I was wondering if explaining the previous "+1 on the first line of your reply" system would be required.)

I think the voting buttons were implemented with the site redesign/overhaul in March 2020. Prior to that, everyone just commented to vote, often saying "+1" or "-1" to indicate their vote.

crocogator said:
I think the voting buttons were implemented with the site redesign/overhaul in March 2020. Prior to that, everyone just commented to vote, often saying "+1" or "-1" to indicate their vote.

Oh wow... that sounds like it was a really awful and annoying voting system, especially for the mods who had to count the votes.

All pending implications from 2016 have now been rejected.

arist bebebebebe usually signs his art as INAX. should this be changed?

starshiptrooper797 said:
arist bebebebebe usually signs his art as INAX. should this be changed?

You'd be better off making a new thread for asking this so it can be better seen.

Okay so this is crazy,
but has anyone considered consolidating all the names?

Like, some instances of names shared by characters.

I recently saved Kimiko Fivetails while I could. That's her name. Not Kimiko_(Fortnite)

The trend of Name(property) was original reserved for artists who have a character that is a the same name as their handle, not every single instance of media a character name might appear in.
It was supposed to be Name(artist) so you could have Artist, Copyright and Character(artist) together without interfering with another artist drawing that character.

Big example.

Foxy.

You don't need Foxy_(FNAF), Foxy_(Drawn_Together), Foxy_(SkunkFu).

If you want to find the separate character you would type "Foxy FNAF" "Foxy Drawn_Together" Foxy Skunkfu)

Foxy_Love actually has a last name and it's in her tag, but my point remains. Character(media) is redundant for all instances of a name when you can just type the copyright tag to find the correct character.

The only reason I'm bringing it up here is because, like
This is kind of a monumental change. It's a tag trend that's gotten out of control. It's WAY too many tags to poke at myself.

tanookicatoon said:
Okay so this is crazy,
but has anyone considered consolidating all the names?

Like, some instances of names shared by characters.

I recently saved Kimiko Fivetails while I could. That's her name. Not Kimiko_(Fortnite)

The trend of Name(property) was original reserved for artists who have a character that is a the same name as their handle, not every single instance of media a character name might appear in.
It was supposed to be Name(artist) so you could have Artist, Copyright and Character(artist) together without interfering with another artist drawing that character.

Big example.

Foxy.

You don't need Foxy_(FNAF), Foxy_(Drawn_Together), Foxy_(SkunkFu).

If you want to find the separate character you would type "Foxy FNAF" "Foxy Drawn_Together" Foxy Skunkfu)

Foxy_Love actually has a last name and it's in her tag, but my point remains. Character(media) is redundant for all instances of a name when you can just type the copyright tag to find the correct character.

The only reason I'm bringing it up here is because, like
This is kind of a monumental change. It's a tag trend that's gotten out of control. It's WAY too many tags to poke at myself.

I'm not sure why you would specifically want to search for characters that share the same name, but this is possible using a wildcard search.

Foxy* or foxy_*.

Searching name + copyright sounds a reasonable idea in theory, but in practice if it was done this way the copyright tags probably won't even be on the post because everybody relies so much on the implications - which couldn't automatically be added from a vague tag like foxy. It would also be a mess when characters don't belong to a copyright - would they be impossible to search for or would they still get a unique tag?

Well I'm glad that my Stirrup BUR wasn't made around that time. I would have panicked at the thought of setting it up again...

faucet said:
I'm not sure why you would specifically want to search for characters that share the same name, but this is possible using a wildcard search.

Foxy* or foxy_*.

Searching name + copyright sounds a reasonable idea in theory, but in practice if it was done this way the copyright tags probably won't even be on the post because everybody relies so much on the implications - which couldn't automatically be added from a vague tag like foxy. It would also be a mess when characters don't belong to a copyright - would they be impossible to search for or would they still get a unique tag?

Again I'm mostly just talking about characters that share the same name.

Obviously you would search the name and the copyright together.
The character associated with the copyright will pop up instead of the other one.
That's how tags work. Name(Media source) is redundant.
Especially so when characters get the (media) suffix, even when they're the FIRST character of that name, or ONLY character to have that name ever.
Where else is that character going to be from? lol

tanookicatoon said:
Okay so this is crazy,
but has anyone considered consolidating all the names?

Like, some instances of names shared by characters.

I recently saved Kimiko Fivetails while I could. That's her name. Not Kimiko_(Fortnite)

The trend of Name(property) was original reserved for artists who have a character that is a the same name as their handle, not every single instance of media a character name might appear in.
It was supposed to be Name(artist) so you could have Artist, Copyright and Character(artist) together without interfering with another artist drawing that character.

Big example.

Foxy.

You don't need Foxy_(FNAF), Foxy_(Drawn_Together), Foxy_(SkunkFu).

If you want to find the separate character you would type "Foxy FNAF" "Foxy Drawn_Together" Foxy Skunkfu)

Foxy_Love actually has a last name and it's in her tag, but my point remains. Character(media) is redundant for all instances of a name when you can just type the copyright tag to find the correct character.

The only reason I'm bringing it up here is because, like
This is kind of a monumental change. It's a tag trend that's gotten out of control. It's WAY too many tags to poke at myself.

reasons against this:
- character bios on wiki pages
- characters with multiple iterations in the same series
- tag counts not showing a character's popularity
- clicking from the tag list will show multiple characters
- less info is provided to the user when viewing the tag list
- it solves no problems
- why?

tanookicatoon said:
Again I'm mostly just talking about characters that share the same name.

Obviously you would search the name and the copyright together.
The character associated with the copyright will pop up instead of the other one.
That's how tags work. Name(Media source) is redundant.
Especially so when characters get the (media) suffix, even when they're the FIRST character of that name, or ONLY character to have that name ever.
Where else is that character going to be from? lol

We don't tag character owners, so if a normal plain jane furry had a character named Foxy too, there would be no way to search for or blacklist that one. Having some characters named Foxy without a suffix and some with would be confusing, as the ones that should have a suffix due to no associated copyright will likely be tagged without a suffix since the name matches and thus have no owner info. In the same vein, a word like "foxy" has other meanings, being sly or sexy, so there's no way to tell if the tag was used meaning that or not.

Additionally, there's no way to associate two tags together. For example if you search for foxy fnaf, that would also catch instances where you have Foxy from SkunkFu with Freddy Fazbear from FNAF, creating false positives.

Since the e621 news thing on all pages ("May 15th: We're planning to do some housekeeping with old, still pending aliases and implications. If you have any old requests still pending have a look at this thread for the details.")
links to this thread (38484),

the sequel thread (for housekeeping of aliases & implications of 2017) is at: topic #38731