@Cenarium is this a new right?

If nope, we could discuss it on the Wikimedia forum on meta.

It's a new right, see https://lists.wikimedia.org/pipermail/wikitech-ambassadors/2015-April/001162.html.
For enwiki, the request was for bots to add them, and admins to remove them. So admins and bots can be given changetags (it's the same userright for adding/removing).
As a default for WMF, I think we should at least restrict to autoconfirmed at first, and have a discussion at meta to see if we should restrict further.

This announcement offered "Both of these rights are granted to all logged-in users by default." and an invitation to request another configuration if needed.

To restrict these rights means we can't offer to every user scripts and gadgets to properly tag revisions. That doesn't point in favour of such restriction.

There are two separate rights at play here: applychangetags allows the user to apply tags as they make edits, and changetags allows the user to add or remove tags from any revision or log entry on the wiki. There is no need to restrict the applychangetags right at present; however I wouldn't be opposed to changetags being restricted to sysops by default on the WMF cluster (although some individual sites might like to assign it to a "patroller"-type group).

In fact, I wonder if we should restrict changetags to sysops in the default MediaWiki config - I imagine the vast majority of users of MW sites will never use this functionality, so it will just clutter their history and log pages. @Anomie, what do you think?

Bots should also have it, so that for example anti-vandalism bots like ClueBot can tag edits it identifies as probable vandalism, but with not a high enough likelihood for rollback, or a bot that detects possible copyright violations, etc.

In T97013#1237335, @TTO wrote:

@Anomie, what do you think?

I pointed people at the mailing list to discuss it because I really don't have any idea what might be best. But since it's likely to be most useful for bots, not giving it to bots seems like an odd choice.

The feature seems deployed now, I find it very weird that just normal users can do stuff like this.

• Users on German Wikipedia are bothered by this feature and suppress it via CSS to make the page history useful again, avoiding misclicks in confusing checkbox rather than radio.
• There are no plans to introduce project-defined tags on German Wikipedia, but might happen somewhen in future. If any, it would not be desirable that everyone could add or remove tags from former edits; automatic user scripts might make use of applychangetags for the same edit, but later removal of tags is a bot task and would be done on project scale, not for a single edit of a single page. A sysop might correct a few wrong assignments.
• Currently the feature was deployed to nearly 1000 wikis, but only one has detailed plans to use project-defined tags. Rather than asking 1000 wikis to blacklist them and to apply for opt-out and therefore hold 1000 consensus polls to get rid of this unrequested feature, those wikis which want to use it should ask for it (Opt-In).
• By default, changetags should be limited to bot accounts and sysops, while applychangetags might be used by anyone who knows how to, including anonymous users utilizing Greasemonkey and default site gadgets. If any wiki likes to assign that to other groups they might apply individually.
• BTW: The mailing list is stone age and just a global annoouncement, but no platform for discussions. The platform for discussions is a Phabricator task like this one.

I'll upload a WMF-wide config patch in a few hours.

Change 208088 had a related patch set uploaded (by TTO):
Restrict changetags right to sysops and bots only

https://gerrit.wikimedia.org/r/208088

As said on Gerrit change 208088 comment, this change of rights occur very soon.

We could wait June to get more feedback. It could potentially be interesting for scripts and gadgets to use this.

@Dereckson – you have opposed on the gerrit page.

Please note that by applychangetags any user script may apply tags on the same edit. This is not affected by the change under discussion, as I mentioned already a couple of hours ago.

What we are discussing here is the ability to remove or add tags on the history page on older revisions of a particular page.

Regular users are not supposed to add or remove tags for former revisions. If there is a need to remove some tags under certain conditions, this will be done by bots on project wide scale. The bot master might also want to remove misplaced tags recently disseminated by his own bot.

Currently every history page on 1000 wikis is filled with a pile of meaningless checkboxes, while nobody has any tag to be managed, nor is any user supposed to add or remove any tag manually. But that’s what changetags is for.

I agree with @PerfektesChaos

Apart from that: This function was deployed without consensus, why we need consensus to switch it of. Is this a joke?

(See also T97766 and T97752)

In T97013#1251799, @PerfektesChaos wrote:

@Dereckson – you have opposed on the gerrit page.

Please note that by applychangetags any user script may apply tags on the same edit. This is not affected by the change under discussion, as I mentioned already a couple of hours ago.

What we are discussing here is the ability to remove or add tags on the history page on older revisions of a particular page.

Regular users are not supposed to add or remove tags for former revisions. If there is a need to remove some tags under certain conditions, this will be done by bots on project wide scale. The bot master might also want to remove misplaced tags recently disseminated by his own bot.

Yes they are.

If you use a script to perform an action A with a tag ActionA, but then there were somewhere a glitch or an error and it were ActionB, this could be useful to avoid to flood specialized recent changes lists.

In T97013#1251813, @Steinsplitter wrote:

I agree with @PerfektesChaos

Apart from that: This function was deployed without consensus, why we need consensus to switch it of. Is this a joke?

(See also T97766 and T97752)

April 16th 2015 [[ https://www.mail-archive.com/wikitech-ambassadors@lists.wikimedia.org/msg01134.html

Both of these rights are granted to
all logged-in users by default.

If the default assignment of these rights is a concern for the community of
any WMF-hosted wiki, please follow the procedure at
https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes to
request the necessary configuration change.

I don't see any difficulty to process like this. But I see a lot of difficulties to say something April 16 and something else in May. To accept your request without any further input or discussion from the community would mean you're making these announcements unstrustable.

Please stop arguing. No deployment is going to be reverted. And as I said in Gerrit:

No consensus is needed for the MediaWiki software to be updated every week, as it is on all WMF wikis. This new MediaWiki feature has become available on all wikis as a result of these progressive updates.

On the other hand, there are solutions available. I think, in spite of Dereckson's suggestions, there is little chance that users will be using the features that belongs to the changetags right in the near future. Certainly, on most wikis, it will never be used. That is why I suggest to change the default rights assignment to bot and sysop only. If individual projects have successfully started using api.php?action=edit&tags=, and require users to be able to clean up these tag assignments, then we can revisit this at a later time and look at changing the assignment of the changetags right.

You're simply wrong @Steinsplitter. Not every single software change needs consensus for every wiki it gets deployed to.

If you can't understand this, then please do not participate in Wikimedia-Site-requests tickets.

One useful thing did come out of the complaining here: the comments that some wikis have no plans to create any user-editable tags made me realize T97773: Only show edit-change-tags UI if editable change tags are defined would be a good idea.

Using these tags in German Wikipedia is discussed at the moment. I think it would be really suboptimal to cange the rights assignment right now.

(Coming back from vacation.)
First, at least the wide visibility had the benefit of "advertising" the feature and the immediate concerns have been addressed by T97773. I think we'll need a discussion at meta on the WMF default as suggested earlier.
With regard to the link between the two user rights made in T97013#1251820, I believe it would be a relatively rare occurrence that could be handled by just asking a user with the permission, much like a user creating a page with a misspelled title would ask a sysop to move without redirect to the correct title.
Restricting further changetags is logical since, as with page moves without redirect, it allows to break many established things while having a very limited use case.
I think we should at least restrict to autoconfirmed by default on WMF, without waiting for the results of a meta discussion, since at the moment any user can remove tags that are no longer defined, even though they may still be useful to some.

Retitled to en.wikipedia since the consensus is clear there. See the original feature request at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29/Archive_117#Bot_tagging_of_edits and the recent discussion at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Edit_Tags.

In T97013#1272353, @Cenarium wrote:

Retitled to en.wikipedia since the consensus is clear there.

I'm not seeing anything like clear consensus there. Samwalton9 was initially concerned but then stated that his concerns were unfounded after reading the announcement email. Others seem to have been as much complaining about T97773 (keyword is "clutter") before that was fixed, and the conversation as a whole has rather low participation.

In T97013#1272407, @Anomie wrote:

In T97013#1272353, @Cenarium wrote:

Retitled to en.wikipedia since the consensus is clear there.

I'm not seeing anything like clear consensus there. Samwalton9 was initially concerned but then stated that his concerns were unfounded after reading the announcement email. Others seem to have been as much complaining about T97773 (keyword is "clutter") before that was fixed, and the conversation as a whole has rather low participation.

Well, the consensus from the original request still stands. And the concern about clutter will reemerge once we'll have tags for bots or scripts.

Started discussion at meta : https://meta.wikimedia.org/wiki/Wikimedia_Forum#New_userright_related_to_change_tagging_:_which_usergroups_should_have_it_by_default_.3F.

Changed back to global default since it seems a couple more specialized groups might be given this at enwiki so we'll need a specific request anyway.

There seems to be consensus at enwiki for removing changetags from users and granting it to admins, bots and edit filter managers, but not to template editors. See village pump discussion

At meta, there's been little replies. At frwiki where the system is already used, some js is used to prevent displaying the tags in the UI. We should probably go with a global restriction to autoconfirmed.

Change 218353 had a related patch set uploaded (by Cenarium):
Enwiki: remove changetags from user and add it to sysop, bot and abusefilter groups

https://gerrit.wikimedia.org/r/218353

Change 218353 merged by jenkins-bot:
Enwiki: remove changetags from user and add it to sysop, bot and abusefilter groups

https://gerrit.wikimedia.org/r/218353

Change 208088 abandoned by TTO:
Restrict changetags right to sysops and bots only

Reason:
Seems to have been handled in other ways in the past 6 months. In particular, the associated task is marked "resolved".

https://gerrit.wikimedia.org/r/208088