@lb- is there a particular direction you had in mind?

@aayushman-singh I have updated the description, something like that should be good I think, including a clean up of the existing settings.

We probably should use delay not debounce for the setting name, we may also update this on the controller also.

What do you think?

Makes sense, thanks for the improved description. I'll get started after the .js PR, let me know if we want to use delay instead of debouce for the controller.

I'd question whether we really need a configuration setting for this. What kind of situation do you envisage where a user wouldn't find the current hard-coded limit or debounce delay acceptable? They might have a personal preference for some other value, but there are any number of other equally minor details about the Wagtail admin UI that aren't currently customisable (like, say, the ordering and layout of forms in the Settings area). At some point, it's more sensible (and arguably a better developer experience) for Wagtail to just make appropriate choices and stick with them, rather than presenting endless options for customisation that make it harder for developers to find the specific settings that they are interested in.

You make a valid point. This issue originally arose because someone found the lack of control over this configuration frustrating, which led to the hardcoding of smaller values. It might be better to have this flexibility available, even if it's not always needed. However, we can change this approach to whatever suits Wagtail dev experience better.

I may have missed some of the earlier discussion, but did their frustration come from the lack of control over the setting, or more that Wagtail originally had badly-chosen values for these limits (or rather: didn't set a limit at all), leading to performance issues and poor user experience? If it's the latter, then the current solution of setting better values is enough.

One reason I don't like introducing new config settings is that it introduces "action at a distance" - you end up with one part of the code (namely, the settings file) having control over many aspects of the application that are very far removed from that location. If we feel that configurability is important here, I'd like to look for approaches that are "closer" to where the feature is being used. For example, maybe it could be a parameter on the form widget, so that when you're defining a page model with a tag field on it, you would write:

FieldPanel("tags", widget=TagWidget(limit=20))

But that will introduce more "moving parts", and I think we should only go ahead with it if there's a demonstrated need for it.

Makes sense, we can update the issue to simply adding an alias for the other non-Taggit settings, if that is preferable.

Thanks @gasman - good call on this.

@aayushman-singh are you able to update your PR to just cover the renaming of the current Wagtail tag settings only?
I will update this issue accordingly but add some notes for future, if there's a demand/need for more control over these it can be raised as a separate issue.

@lb- , @gasman thanks for the guidance, I've updated the PR accordingly.