Topic: [APPROVED] Tunic Implications

Posted under Tag Alias and Implication Suggestions

The bulk update request #5629 is active.

create implication black_tunic (7) -> black_shirt (13907)
create implication blue_tunic (62) -> blue_shirt (9641)
create implication brown_tunic (50) -> brown_shirt (1293)
create implication green_tunic (163) -> green_shirt (6816)
create implication grey_tunic (13) -> grey_shirt (3510)
create implication orange_tunic (36) -> orange_shirt (2016)
create implication pink_tunic (1) -> pink_shirt (4648)
create implication purple_tunic (39) -> purple_shirt (3106)
create implication red_tunic (32) -> red_shirt (7598)
create implication tan_tunic (3) -> tan_shirt (661)
create implication white_tunic (21) -> white_shirt (18489)
create implication yellow_tunic (12) -> yellow_shirt (3031)
create implication black_tunic (7) -> tunic (2844)
create implication blue_tunic (62) -> tunic (2844)
create implication brown_tunic (50) -> tunic (2844)
create implication green_tunic (163) -> tunic (2844)
create implication grey_tunic (13) -> tunic (2844)
create implication orange_tunic (36) -> tunic (2844)
create implication pink_tunic (1) -> tunic (2844)
create implication purple_tunic (39) -> tunic (2844)
create implication red_tunic (32) -> tunic (2844)
create implication tan_tunic (3) -> tunic (2844)
create implication white_tunic (21) -> tunic (2844)
create implication yellow_tunic (12) -> tunic (2844)
create implication tunic (2844) -> shirt (326956)

Reason: topic #40620 and topic #40624.

Also so that I don't have to manually tag these later.

EDIT: The bulk update request #5629 (forum #378141) has been approved by @Rainbow_Dash.

Updated by auto moderator

wolfmanfur said:
Thought this was gonna be about the game called Tunic. This could be a problem later.

how?

what are you suggesting, that we add a disambiguation parenthetical to the tunic tag because there's a game named after it? if there was a semi-popular furry game that was named "sex" should we change the sex tag to sex_(act)?

Updated

sipothac said:
how?

what are you suggesting, that we add a disambiguation parenthetical to the tunic tag because there's a game named after it? if there was a semi-popular furry game that was named "sex" should we change the sex tag to sex_(act)?

Bad comparison, sex has nearly 900 hundred posts, Tunic is only 2000 posts and each color variant of the tag have fewer than 50 posts under their belt. Tunic, the video game, is far more popular than this tag outside of e621 and when folks are talking about Tunic I'm thinking of the game, not the clothes. How high are the odds it has been 'mistagged', I do say that lightly because the character in Tunic wears a tunic, but then the actual copyright tag for the game goes untagged.

wolfmanfur said:
Bad comparison, sex has nearly 900 hundred posts, Tunic is only 2000 posts and each color variant of the tag have fewer than 50 posts under their belt. Tunic, the video game, is far more popular than this tag outside of e621 and when folks are talking about Tunic I'm thinking of the game, not the clothes. How high are the odds it has been 'mistagged', I do say that lightly because the character in Tunic wears a tunic, but then the actual copyright tag for the game goes untagged.

if there was a game called "sex" and it had 1k, 100k, or a fucking million posts, it wouldn't matter, we shouldn't have to disambiguate sex.

I don't think it's a reasonable stance to hold that we ought to rename a general tag every time a property that uses an item as its title comes out. handling tags that way would be a sisyphean task in pretty much the most literal sense.

cloudpie said:
The game should be tagged tunic_(game) :P

it already is, or well tunic_(video_game), which is how it should be.

the argument above is about whether we should change the normal tunic general tag in order to avoid some potential confusion between it, the garment that has existed for around 1600 years, well known to be worn by one of the most famous video game characters of all time, and some isometric indie Zelda-like that has around 100 posts over the year an a half it's been out (and over 5 years since it was revealed) with a few hundred people playing it on steam per day.

sipothac said:
it already is, or well tunic_(video_game), which is how it should be.

the argument above is about whether we should change the normal tunic general tag in order to avoid some potential confusion between it, the garment that has existed for around 1600 years, well known to be worn by one of the most famous video game characters of all time, and some isometric indie Zelda-like that has around 100 posts over the year an a half it's been out (and over 5 years since it was revealed) with a few hundred people playing it on steam per day.

Glad to see some reasonable arguments on here.

So uhh... when the mods gonna approve? It's been a month and I'm still waiting for this to get a response.

hazey-dazey said:
So uhh... when the mods gonna approve? It's been a month and I'm still waiting for this to get a response.

there's currently no one on staff whose main responsibility is dealing with implications, aliases, and BURs, so general tag implications tend to sit around for quite a while before being approved.

juansanchez said:
there's currently no one on staff whose main responsibility is dealing with implications, aliases, and BURs, so general tag implications tend to sit around for quite a while before being approved.

Pain

hazey-dazey said:
Glad to see some reasonable arguments on here.

I'm a bit confused here concerning what problems this now causes, but I added to the tunic wiki page See also section a link to tunic_(video_game). Took less than a minute, even when filling in the wiki change description with "Crosslink tunic_(video_game)".

juansanchez said:
there's currently no one on staff whose main responsibility is dealing with implications, aliases, and BURs, so general tag implications tend to sit around for quite a while before being approved.

Was going to ask, didn't a new admin get added for exactly that purpose? Then I checked and nope, they were demoted to janitor yesterday.

juansanchez said:
there's currently no one on staff whose main responsibility is dealing with implications, aliases, and BURs, so general tag implications tend to sit around for quite a while before being approved.

Why is there no one on staff whose responsibility is dealing with implications, aliases and BURs? Can someone not be hired for this?

hjfduitloxtrds said:
Why is there no one on staff whose responsibility is dealing with implications, aliases and BURs? Can someone not be hired for this?

Every time somebody dedicates their time to it they end up getting burnt out and eventually resigning, for related or unrelated reasons. I think there's also a lot of fear around promoting anybody to do it because doing certain actions can cause a lot of damage that's hard to reverse, or bulk jobs that are too big can result in crashing the site.

No current staff want to tackle it, and nobody wants to promote anybody either. If you account for the resignations, the number of staff actually hasn't changed since the last recruitment drive.

hjfduitloxtrds said:
Why is there no one on staff whose responsibility is dealing with implications, aliases and BURs? Can someone not be hired for this?

I asked the same question I don't really understand the reluctance to have people on the staff team whose specific job it is to handle this and do nothing else. It clearly needs a dedicated team since, as it was said, none of the current staff want to handle it and we have stuff going all the way back to 2017 that is usually a simple yes or no question whether or not to accept it or not, it's kinda not fair to the users of the site that the main reason behind them not getting done is just reluctance to make a team dedicated to it out of fear they might try to vandalize the site (which any mod/admin could do, yet staff are still added...) Not to mention e6 doesn't exactly have good security, it's not like there's 2FA, while I would expect most of the staff team have good passwords, if somehow a password is leaked, there's literally nothing in the way of them getting on the account and doing damage. Though I would say the chances of that happening are negligible anyways... Just like I'd say the chances of a small team handling aliases/implications/BURs vandalizing the site is also low. Obviously the position will need trust, but so does mod, the lowest tier currently that can accept these changes. But the added necessities of the mod "job" make it so much easier to burn out of menial tasks like clicking "approve" or "reject" on an alias/implication/BUR... But again, reluctance to even have the conversation, make the permission changes, and then find the people for the team.

faucet said:
Every time somebody dedicates their time to it they end up getting burnt out and eventually resigning, for related or unrelated reasons.

it's honestly amazing how BitWolfy handled the job of like four people during his 3-year tenure and didn't entirely desolve into a pile of cosmic dust after leaving staff like everyone else seems to.

definitelynotafurry4 said:
I asked the same question I don't really understand the reluctance to have people on the staff team whose specific job it is to handle this and do nothing else. It clearly needs a dedicated team since, as it was said, none of the current staff want to handle it and we have stuff going all the way back to 2017 that is usually a simple yes or no question whether or not to accept it or not, it's kinda not fair to the users of the site that the main reason behind them not getting done is just reluctance to make a team dedicated to it out of fear they might try to vandalize the site (which any mod/admin could do, yet staff are still added...) Not to mention e6 doesn't exactly have good security, it's not like there's 2FA, while I would expect most of the staff team have good passwords, if somehow a password is leaked, there's literally nothing in the way of them getting on the account and doing damage. Though I would say the chances of that happening are negligible anyways... Just like I'd say the chances of a small team handling aliases/implications/BURs vandalizing the site is also low. Obviously the position will need trust, but so does mod, the lowest tier currently that can accept these changes. But the added necessities of the mod "job" make it so much easier to burn out of menial tasks like clicking "approve" or "reject" on an alias/implication/BUR... But again, reluctance to even have the conversation, make the permission changes, and then find the people for the team.

That's the whole problem. There aren't enough mods to do what needs done now. How bad will it get in the future, if e621 keeps growing. There's way too much work for way too few people to handle. More people= fewer tasks each= less burnout.

hjfduitloxtrds said:
Why is there no one on staff whose responsibility is dealing with implications, aliases and BURs? Can someone not be hired for this?

AFAIK, the only one that actually works here as a job is NotMeNotYou, everyone else is an unpaid volunteer. Aliases and implications are a sensitive field that relies on a good deal of trust for someone to work on, since accepting the wrong requests has the potential to do a lot of damage to the site. So you not only need enough trust to be considered for a moderator role, and be further trusted enough to not be careless with the requests, such a moderator has to be able to dedicate enough free time to the site too, which makes for a very small pool of potential candidates.

wat8548 said:
Was going to ask, didn't a new admin get added for exactly that purpose? Then I checked and nope, they were demoted to janitor yesterday.

And gattonero2001 became a janitor, one of the admins that did work on aiburs in the past

definitelynotafurry4 said:
I asked the same question I don't really understand the reluctance to have people on the staff team whose specific job it is to handle this and do nothing else. It clearly needs a dedicated team since, as it was said, none of the current staff want to handle it and we have stuff going all the way back to 2017 that is usually a simple yes or no question whether or not to accept it or not, it's kinda not fair to the users of the site that the main reason behind them not getting done is just reluctance to make a team dedicated to it out of fear they might try to vandalize the site (which any mod/admin could do, yet staff are still added...) Not to mention e6 doesn't exactly have good security, it's not like there's 2FA, while I would expect most of the staff team have good passwords, if somehow a password is leaked, there's literally nothing in the way of them getting on the account and doing damage. Though I would say the chances of that happening are negligible anyways... Just like I'd say the chances of a small team handling aliases/implications/BURs vandalizing the site is also low. Obviously the position will need trust, but so does mod, the lowest tier currently that can accept these changes. But the added necessities of the mod "job" make it so much easier to burn out of menial tasks like clicking "approve" or "reject" on an alias/implication/BUR... But again, reluctance to even have the conversation, make the permission changes, and then find the people for the team.

It is not about trust in them not vandalizing the site, it's about trust in their competence to structure our tags in a way that won't make things worse. Dice (the admin at the time) did a lot of AIBUR work but most of it was questionable at best for usefulness. Aliases are totally irreversible and BURs have the capacity to crash the site if not done properly.

We simply don't have enough people to take on the AIBUR queue. I used to handle it for about 5-6 years, and I totally burnt out from it. It really is quite draining after even a short while.

rainbow_dash said:
It is not about trust in them not vandalizing the site, it's about trust in their competence to structure our tags in a way that won't make things worse. Dice (the admin at the time) did a lot of AIBUR work but most of it was questionable at best for usefulness. Aliases are totally irreversible and BURs have the capacity to crash the site if not done properly.

We simply don't have enough people to take on the AIBUR queue. I used to handle it for about 5-6 years, and I totally burnt out from it. It really is quite draining after even a short while.

Thank you for trying anyways.

snpthecat said:
And gattonero2001 became a janitor, one of the admins that did work on aiburs in the past

That was the very admin to whom I was referring.

rainbow_dash said:
We simply don't have enough people to take on the AIBUR queue.

Alright, who's gonna be first to volunteer to point out the obvious?

wat8548 said:
Alright, who's gonna be first to volunteer to point out the obvious?

the problem is you need to bring on someone who's both enthusiastic and also competent... or there needs to be some way to emergency stop before a bad alias goes through that might cause problems or an undo button for afterwards.

rainbow_dash said:
It is not about trust in them not vandalizing the site, it's about trust in their competence to structure our tags in a way that won't make things worse. Dice (the admin at the time) did a lot of AIBUR work but most of it was questionable at best for usefulness. Aliases are totally irreversible and BURs have the capacity to crash the site if not done properly.

We simply don't have enough people to take on the AIBUR queue. I used to handle it for about 5-6 years, and I totally burnt out from it. It really is quite draining after even a short while.

This is what I said already. There aren't enough people to handle the current workload, let alone the likely future increase as more and more users join e621. It'll inevitably get worse over time if nothing is done to recruit more.

Also why are aliases irreversible? This sounds like an extremely bad idea. Humans can and will make mistakes. Therefore, it's probably in the best interests to make everything completely reversible or able to revert back to previous versions.

hjfduitloxtrds said:
This is what I said already. There aren't enough people to handle the current workload, let alone the likely future increase as more and more users join e621. It'll inevitably get worse over time if nothing is done to recruit more.

Also why are aliases irreversible? This sounds like an extremely bad idea. Humans can and will make mistakes. Therefore, it's probably in the best interests to make everything completely reversible or able to revert back to previous versions.

By aliases being irreversible it means that if you alias, you can't undo things to before the alias. You can remove the alias but the damage has already been done.

rainbow_dash said:
Aliases are totally irreversible and BURs have the capacity to crash the site if not done properly.

two things about this.
would it be feasible to, just before an alias goes through, have a set created automatically that contained the posts that populated the old tag? that way if the undo needed to happen all of those posts were still around, and if that isn't necessary we could just delete the set.
alternately, what do we think about having a delay of 24-48 hours on request approvals? that way we have a short period for everyone to do a once-over on the tag(s) to do a final cleanup or (if ever necessary) a staff member could abort the approval if a major flaw is realized.

Updated

juansanchez said:
two things about this.
would it be feasible to, just before an alias goes through, have a set created automatically that contained the posts that populated the old tag? that way if the undo needed to happen all of those posts were still around, and if that isn't necessary we could just delete the set.

You should contact Earlopain about this - I'm not a dev but it sounds like a really good idea!

juansanchez said:
two things about this.
would it be feasible to, just before an alias goes through, have a set created automatically that contained the posts that populated the old tag? that way if the undo needed to happen all of those posts were still around, and if that isn't necessary we could just delete the set.
alternately, what do we think about having a delay of 24-48 hours on request approvals? that way we have a short period for everyone to do a once-over on the tag(s) to do a final cleanup or (if ever necessary) a staff member could abort the approval if a major flaw is realized.

Could do something similar for implications, where the set contains the difference of the antecedent and consequent tags.

cloudpie said:
You should contact Earlopain about this - I'm not a dev but it sounds like a really good idea!

On the subject of contacting Earlopain, the thing about it being possible for BURs to crash the site sounds like a problem with the software, not its users. By "crash the site" are we referring to things like that time when pokemon_(species) got split up into generations and all tag searches stopped updating for a while, or an actual hard crash? Either way, it should be fixable with a little bit of effort by implementing a priority queue system for pending tag updates. It wouldn't be the end of the world if a large BUR took 24 hours to fully complete.

wat8548 said:
By "crash the site" are we referring to things like that time when pokemon_(species) got split up into generations and all tag searches stopped updating for a while, or an actual hard crash?

I imagine they mean locking the database up, or corrupting it (BURs weren't intended to be a publicly accessible feature, it was an internal moderator tool; one of the reasons it took so long to let users make BURs was because it took time to add safety checks to prevent the most obvious problems). The search issue was a result of the database being overwhelmed and taking time to apply. Changes to posts aren't instantaneous, the more posts that need to be changed at once, the more time it takes for the database to actually update them all (followed by any caches and internal associations being updated). Which actually makes the suggestion:

juansanchez said:
would it be feasible to, just before an alias goes through, have a set created automatically that contained the posts that populated the old tag?

... a problem, because then the site has to first do that for every post before applying the request. Tags wouldn't need to be as populated as pokemon is to start seeing requests cause delays in the search reflecting recent changes.

This would still also have the problem of posts tagged after the request was accepted and before it was reverted, or if it already had both tags to start with. There's no way to know whether a given post's use of a tag was intentional or a result of the faulty alias or implication after the fact. And as we've noticed, it can sometimes take a while before a bad alias or implication is spotted.

watsit said:
... a problem, because then the site has to first do that for every post before applying the request. Tags wouldn't need to be as populated as pokemon is to start seeing requests cause delays in the search reflecting recent changes.

yeah, that's what I was kinda thinking about after I posted that, it'd just add another operation to the process which would essentially just double the load on the DB.

watsit said:
This would still also have the problem of posts tagged after the request was accepted and before it was reverted, or if it already had both tags to start with. There's no way to know whether a given post's use of a tag was intentional or a result of the faulty alias or implication after the fact. And as we've noticed, it can sometimes take a while before a bad alias or implication is spotted.

this was kinda why I was leaning more towards the delayed approval option, giving everyone a sort of "speak now or forever hold your peace" period. I feel like some of the times I see bad alias/implication requests go through it's requests that are pretty old and hadn't had much recent discussion or didn't have much discussion at all, or in other cases they were requests that seemed kind of innocuous. having a ticking clock would kind of pressure everyone to really consider if it's actually a good idea.

juansanchez said:
this was kinda why I was leaning more towards the delayed approval option, giving everyone a sort of "speak now or forever hold your peace" period. I feel like some of the times I see bad alias/implication requests go through it's requests that are pretty old and hadn't had much recent discussion or didn't have much discussion at all, or in other cases they were requests that seemed kind of innocuous. having a ticking clock would kind of pressure everyone to really consider if it's actually a good idea.

I imagine anyone that has a strong opinion on a request would already give that opinion when they see it. The problem is, there aren't many people that even look at the forums, let alone visit the site/forums every day, and they don't always have strong opinions. Pressuring people to give opinions right away may even have the opposite effect than desired; causing people to make more snap judgments and making it seem like a request is more controversial than it actually is, causing the admins more pause, or making it seem more unanimous when people don't actually care that much, causing the admins to more readily approve/deny it without as much thought.

To me it seems the biggest issues relating to bad aliases and implications come down to two things: 1) changing opinions on what's good and bad to tag (e.g. tail, x_verbing_y) or how to deal with bad tags (e.g. alias to invalid_tag, the closest "good enough" tag, a _(disambiguation)), where it sometimes seems the admins disagree among themselves, and 2) not realizing how non-specific a tag actually is (e.g. cat and dog being so widely used for a variety of non-domestic felids and canids) or not realizing a tag has other meanings that will see a fair bit of use (e.g. dock), until the number of "mistags" becomes readily apparent months or years later. Sometimes an alias or implication is requested with the hopes that people will adjust their use of a tag when they notice it aliased to or implicating another tag, which they don't always do.

watsit said:
I imagine anyone that has a strong opinion on a request would already give that opinion when they see it. The problem is, there aren't many people that even look at the forums, let alone visit the site/forums every day, and they don't always have strong opinions. Pressuring people to give opinions right away may even have the opposite effect than desired; causing people to make more snap judgments and making it seem like a request is more controversial than it actually is, causing the admins more pause, or making it seem more unanimous when people don't actually care that much, causing the admins to more readily approve/deny it without as much thought.

I mean, maybe? but the inverse is that we're stuck with an existential uncertainty and nothing ever gets done, with requests sitting for over half a decade now. I think everyone around here wants to see requests actually go through, but it seems like no one with the power to actually wants to push the button. if the responsibility of having that press go through could be distributed a bit across the userbase of the forums there might be less hesitancy.

additionally, I'm not sure if it's necessarily a bad thing that there aren't that many people that visit the forums. most of the people that do hang around here are pretty well-versed in tagging with 4/5-digit edit counts and, in general, are pretty reasonable folk. and even though we're certainly not going to totally representitive of the wider e6 userbase, I think we've still all have a fairly wide range of intrests of the content hosted here, or, failing that, are at least pretty considerate. I'm not sure any of us would try to halt an alias without thinking that it's for sure a bad idea.

I don't think the problem is really bad aliases/implications themselves, as much as it is the fear of aliases/implications being bad.

watsit said:
Changes to posts aren't instantaneous, the more posts that need to be changed at once, the more time it takes for the database to actually update them all (followed by any caches and internal associations being updated).

That was the point I was making: there's no need for a BUR to be applied as quickly as possible, especially if it compromises more important features of the site. If it took a week to tag a thousand posts, it would still be preferable to the existing system of effectively demanding some poor sod do it manually because no BURs get approved any more.

Users have to abide by a rate limit when using the API to prevent this kind of problem. BURs apparently don't.

  • 1