Page MenuHomePhabricator

Restrict changetags user right to sysops and bots on de.wikipedia
Closed, DeclinedPublic

Description

  • 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.

Could you get open a short discussion to get some consensus somewhere on de. to restrict this right on de.wikipedia?

If so, and according the duration you wish for the discussion, we can deploy a config change disabling it locally next week anytime between Monday and Thursday evening.

Event Timeline

Dereckson raised the priority of this task from to High.
Dereckson updated the task description. (Show Details)
Dereckson added subscribers: Dereckson, PerfektesChaos.
This comment has been deleted.

No consensus need to switch it on, but consensus needed to switch it off. Simply a joke.

Allow me to be very clear here: This feature was added as a commit to MediaWiki, it was not a new extension. Such things which are deployed automatically on the MW train (i.e. changes to MediaWiki defaults) do not need consensus from $MY_FAVOURITE_WIKI, because otherwise we'd have Wikimedia wikis dictating MediaWiki development and affecting non-Wikimedia sites. Rights changes for specific wikis generally do.

[ Temporarily adding back Community-consensus-needed project pending a task edit with the URL of such consensus discussion. ]

No consensus need to switch it on, but consensus needed to switch it off. Simply a joke.

Allow me to be very clear here: This feature was added as a commit to MediaWiki, it was not a new extension. Such things which are deployed automatically on the MW train (i.e. changes to MediaWiki defaults) do not need consensus from $MY_FAVOURITE_WIKI, because otherwise we'd have Wikimedia wikis dictating MediaWiki development and affecting non-Wikimedia sites. Rights changes for specific wikis generally do.

Sorry, but that is nonsense. There would be no problem to ship MediaWiki with a disabled default; and it would also no problem to disable this feature as default in the Wikimedia-Wikis (if MediaWiki REALLY needs this feature as default on).

No consensus need to switch it on, but consensus needed to switch it off. Simply a joke.

Allow me to be very clear here: This feature was added as a commit to MediaWiki, it was not a new extension. Such things which are deployed automatically on the MW train (i.e. changes to MediaWiki defaults) do not need consensus from $MY_FAVOURITE_WIKI, because otherwise we'd have Wikimedia wikis dictating MediaWiki development and affecting non-Wikimedia sites. Rights changes for specific wikis generally do.

Sorry, but that is nonsense. There would be no problem to ship MediaWiki with a disabled default; and it would also no problem to disable this feature as default in the Wikimedia-Wikis (if MediaWiki REALLY needs this feature as default on).

It's no problem for MediaWiki to ship stuff to default off, but there's also nothing wrong in general with MediaWiki shipping with things default on.

Sure @Krenair, but why do we need a community-consensus to disable something, but not one to enable something?
And if MediaWiki really have something enabled on default because somewhere in the internet someone COULD use a feature: Why not disable it in the Wikimedia-config globaly and ASK first who (=which of our wikis) could need it?

Sure @Krenair, but why do we need a community-consensus to disable something, but not one to enable something?

Because you want wiki-specific config changes (i.e. specific sysadmin intervention), whereas the feature appeared on your wikis via the routine "train" deploys that simply bring the newest (or very close to newest) version of MediaWiki to Wikimedia's sites every week or so.

And if MediaWiki really have something enabled on default because somewhere in the internet someone COULD use a feature: Why not disable it in the Wikimedia-config globaly and ASK first who (=which of our wikis) could need it?

Why not have it enabled by default if it's a good feature that can be used productively by many people? New default-on things obvious to users aren't entirely forbidden, just quite rare.

Status: If not used = switched off (fixed in a other patch). Closing this bugreport?

Because you want wiki-specific config changes (i.e. specific sysadmin intervention), whereas the feature appeared on your wikis via the routine "train" deploys that simply bring the newest (or very close to newest) version of MediaWiki to Wikimedia's sites every week or so.

Maybe you should look at the https://en.wikipedia.org/wiki/User:Jimbo_Wales/Statement_of_principles :-)

Because you want wiki-specific config changes (i.e. specific sysadmin intervention), whereas the feature appeared on your wikis via the routine "train" deploys that simply bring the newest (or very close to newest) version of MediaWiki to Wikimedia's sites every week or so.

Maybe you should look at the https://en.wikipedia.org/wiki/User:Jimbo_Wales/Statement_of_principles :-)

Anything specific there you feel is relevant?

Because you want wiki-specific config changes (i.e. specific sysadmin intervention), whereas the feature appeared on your wikis via the routine "train" deploys that simply bring the newest (or very close to newest) version of MediaWiki to Wikimedia's sites every week or so.

Maybe you should look at the https://en.wikipedia.org/wiki/User:Jimbo_Wales/Statement_of_principles :-)

Anything specific there you feel is relevant?

Is this a rhetorical question?

Luke081515 lowered the priority of this task from High to Lowest.Oct 11 2015, 8:41 PM

At the moment, there is no custom tag, so this feature is not shown to users, so I don't think, that this feature is a problem at the moment.

Dereckson claimed this task.

Local community has never moved to launch a discussion since May, so isn't interested by this.