Requested feature overview description.

Eliminating users' ability to request aliases/implications without using Bulk Update Requests.

Why would it be useful?

• Aliases and implications requested before a BUR may block the addition of certain lines to the BUR's script.

• Aliases and implications requested after a BUR may cause the BUR to fail.

BURs require much more effort and care than standalone alias or implication requests, so they are less likely to be written by inexperienced users who may misunderstand the tagging system and create invalid requests. The latter two also cannot be modified or rejected by the original poster, and therefore may be a hindrance to BUR writing until they are rejected by an admin, which may take a long time. If all tag relationship modifications are requested through BURs, errors can be avoided and changes can be effected more quickly.

What part(s) of the site page(s) are affected?

Alias/Implication Requests.

It seems awkward to use a BUR for single requests, but it's not really "wrong" by any means, so I'll voice my support for this.

BURs are still a bit rough around the edges. BURs don't warn/error when other BURs have incompatible requests, but they do when it conflicts with Alias/Implication Requests (I also wonder/worry if two conflicting BURs both try to be applied, if some combination of attempted changes can throw the tag system out of whack). BURs can also be edited after someone votes on it without the voter being aware, even if the voter would want to change their vote as a result of the edit. They're also less straight-forward to make if you're not already familiar with making them.

A new user, or someone new to making alias/implication requests, should probably stick to making simple single alias or implication requests, and only once they get serious about doing more significant requests, they can learn how to use BURs. If BURs had more robust error checking against other BURs, I could see the alias/implication request form generating a single-line BUR instead of the old-style requests, but pushing new users to use the full Request BUR form for simple requests seems a bit drastic.

watsit said:
(…)

Those are all valid points and I did consider them before writing the feature request. However, all things considered, I still believe that getting rid of aliases and implications would be a net improvement. The majority of them come from people who never visited the forum before and probably never will again.

It's a bit tiring constantly checking that none of my BURs will break because someone tried to alias something and requested an implication instead, or filled the to -> from fields the other way around, et cetera.

At the current state of tag relationships, it is more likely that any new random single request will break something rather than fixing anything.

watsit said:
A new user, or someone new to making alias/implication requests, should probably stick to making simple single alias or implication requests, and only once they get serious about doing more significant requests, they can learn how to use BURs.

This is a feature, not a bug. One of the main problems with the "simple" requests is the amount of disruption they are causing in the hands of inexperienced users, so maybe a bit of gatekeeping is in order.

Ok and there is me ... not a new user by any means, but I still need ages for my alias request and I just now that I did one I see your request and think ... You can do a BUR request now? ... Well fuck!
It is ages ago I did the last request and I had to figure it out on my own, back then.
Sometimes I wish there would be a simple YouTube tutorial for these things, but the amount of stuff you need to know to do it proper.
I still think I don't know how to do this properly.

But back to your request, I think if you block for the normal user the ability to do aliases and implications, most people will just quit doing it and only the experienced users will remain.
I don't know if that would be a good thing, I mean sure good for your BUR requests, I guess.

But couldn't just another BUR request intervene with your request in the same way a simple alias can do? Would you really gain so much in the end if someone inexperienced instead of an alias uses a BUR in a bad way?
Don't underestimate stupidity.

I think it would be worth a try if you also create a tutorial for new users on how to do the BURs in that case, otherwise the level of entry will be a little to high for normal people with just an idea and wanted to participate.

wat8548 said:
This is a feature, not a bug. One of the main problems with the "simple" requests is the amount of disruption they are causing in the hands of inexperienced users, so maybe a bit of gatekeeping is in order.

Unfortunately I think removing the simple alias/implication form and leaving only BURs will filter out the wrong group. People who are cautious about doing it right could look at the BUR form, not understand it and realize they probably shouldn't touch it before learning about it, and thus not make a simple, reasonable request. Whereas someone who's a bit more reckless could look at the BUR form, and put in something that looks right to them but they have no idea what they're actually doing, and end up making an incorrect BUR with more wild ideas. While it would reduce the overall number of requests from inexperienced users on both sides, I foresee a higher percentage of disruptive/bad BURs from the inexperienced users that still manage to make requests.

The way it looks to me, the main problem with the simple alias/implication requests isn't the requests themselves, but they're left for so long that they sink to the depths where they're never seen again, and because they're actually checked against other requests for incompatibilities, cause errors with future requests and require that old request to be found and handled first. However, not having that incompatibility checking would cause its own set of problems, such as users unknowingly supporting incompatible BURs, which is only realized when an admin gets the time to apply some and tries to apply the second (which can then require debating and changes and maybe deciding to undo some of what the first BUR did), further delaying and making a mess of things until an admin gets more time for BURs.

I agree that there are benefits to using BURs for simple requests, with being able to self-cancel and edit/fix them, and with a bit of work I could see them replacing old-style requests. But as they are, with the complete lack of inter-BUR error checking and generally being unwieldy for new users wanting to make simple requests, and that one of its benefits comes with drawbacks (being able to edit them at any time), it just seems a bit premature to do before those issues are addressed.

watsit said:
(...)

Old forgotten aliases/implications are of course an issue, but aliases/implications requested AFTER a BUR can cause it to fail as well, and it is even worse in this case because there is no warning at all.

An incorrect BUR is actually much harder to write than a correct one, because they have all sorts of checks that aliases/implications are not subjected to. That kind of person you mention would certainly receive several different error messages before being able to submit any even slightly disruptive script. Compare it to the current situation, in which carefully constructed BURs are made to fail because of an inexperienced user requesting an alias/implication months after the original.

OK, I managed to do my first BUR in addition to my alias
At first, I was not aware you can add a BUR to an existing forum topic. (nice to know)
Luckily I managed to find a suitable example in another post, this would have been quite confusing without an example.
I kind of guessed that it might work like that ...the help text under Bulk Update Requests Help sure is useful, but really minimalistic.
(Is there a wiki page like Bulk Update Requests for Dummies?)

unalias aaa -> bbb
unimply aaa -> bbb
alias aaa -> bbb
imply aaa -> bbb
update aaa -> bbb
category tag_name -> category_name

But I would not be quite sure without the example.(thx Clawstripe)
That is the problem I have with a lot of things here, from the beginning you always need to search stuff extensively or just make a wild guess if you are not a native pc programmer nerd that already knows such things.

Would it be so problematic to have a little description or an example in the help text that says A = flower will be implied to B = plants or something?
Sure those are kind of obvious, but for someone doing it the first time it gives more confidence knowing you are not fucking it up.
I'm still not quite sure what update or the category thing does. I have a guess what it might do, but I will not try it out for sure without consulting someone to explain it to me first or searching about an hour for a suitable example to figure it out.
Likewise, I'm quite too aware of the shitstorm I would receive if something goes wrong ... let's say the first time I tried an alias request didn't go so smooth as anticipated.

Sorry for the rant, but maybe you can see now how the first time user experience here looks like. :P
Sincerely Prokura

prokura said:
(…)

I understand how you feel. Soon after I created an account, I committed a few alias/implication faux pas. However, while the BUR system may seem intimidating at first, in my experience it is quite easy to get used to it.

Let me give you examples of update and category:

• The script update a -> b means that the tag a will be changed to the tag b in all posts that are tagged a when the BUR is approved. However, tag relationships are not affected: future uses of a will not be changed to b.

• The script category a -> invalid means that the tag a will have its category changed to invalid. It can be used for any category, such as general, character, copyright, species, artist, meta or lore. However, it is normally only used for invalid, meta or lore, since tags can be changed to other categories manually unless they have more than 100 posts.

You will find practical examples of both scripts in topic #30532.

gattonero2001 said:
I understand how you feel. Soon after I created an account, I committed a few alias/implication faux pas. However, while the BUR system may seem intimidating at first, in my experience it is quite easy to get used to it.

Let me give you examples of update and category:

• The script update a -> b means that the tag a will be changed to the tag b in all posts that are tagged a when the BUR is approved. However, tag relationships are not affected: future uses of a will not be changed to b.

• The script category a -> invalid means that the tag a will have its category changed to invalid. It can be used for any category, such as general, character, species, artist, meta or lore. However, it is normally only used for invalid, meta or lore, since tags can be changed to other categories manually unless they have more than 100 posts.

You will find practical examples of both scripts in topic #30532.

Thanks a lot ... it is not that per se difficult after doing it at least once, but it would be nice to have a dedicated help post with examples like the one you did there to visualize the process.

At least for me, well I do this not that often after some weeks/months I forget some details like things with the Dtext.
It is always good to have links like dtext or cheatsheet to help out.

Other question, is it wise to do an update (refresh) after doing an alias or imply to effect all the old posts as well?
Otherwise, only new posts will be effected by the change, or will the alias / imply do that update on its own in that one instance it gets implemented?

prokura said:
(...)

If you alias a to b, updating a to b would be redundant and therefore unnecessary. If you imply a to b, updating a to b would simply remove a from all posts, which would be catastrophic. Updates have specific use cases that do not overlap with aliases/implications. All of those affect old posts.

gattonero2001 said:
If you alias a to b, updating a to b would be redundant and therefore unnecessary. If you imply a to b, updating a to b would simply remove a from all posts, which would be catastrophic. Updates have specific use cases that do not overlap with aliases/implications. All of those affect old posts.

thanks

Sure, I didn't mean to do an update after an imply (silly me)
that would be ok if you could only update b without a (I bet that would crash the server)
... but thinking about that kind of happen when I add a tag on an old post, that's the point when the
imply get triggered, and I see them automatically changed in the tag history