Gerrit change 181958[1] was recently merged, which allows (among other things) the ability for sysops to irrecoverably delete change tags. Since irrecoverable deletion of anything from on-wiki is rather unprecedented, I think we should stop granting it to all sysops in DefaultSettings.php, so that wikis have to "opt-in" for this feature to be enabled. Thoughts?
On 5 February 2015 at 13:13, Jackmcbarn jackmcbarn@gmail.com wrote:
Gerrit change 181958[1] was recently merged, which allows (among other things) the ability for sysops to irrecoverably delete change tags. Since irrecoverable deletion of anything from on-wiki is rather unprecedented, I think we should stop granting it to all sysops in DefaultSettings.php, so that wikis have to "opt-in" for this feature to be enabled. Thoughts?
I would go further and suggest that this right is not granted on WMF wikis. We deliberately don't let anyone do irrevocable deletions. This isn't MW 1.4 any more. :-)
J.
Note the deletions aren't intended to be "irrevocable". Once phase 2 of this project is done someone could go through and re-add the tag to each thing it was removed from. Kind of like with Special:Nuke, someone could go through and undelete everything that was deleted.
The one roadblock there is that it doesn't currently log every item that the tag got deleted from. Besides log flooding, though, there's no reason it *couldn't* do that.
On Thu, Feb 5, 2015 at 4:41 PM, James Forrester jforrester@wikimedia.org wrote:
I would go further and suggest that this right is not granted on WMF wikis.
I don't think people would be all that happy if T20670 were closed as "we fixed this, but you can't use it on WMF wikis". Let's fix things rather than jump to non-solution solutions.
We deliberately don't let anyone do irrevocable deletions.
move-over-redirect is an irrevocable deletion ;)
On Thu, Feb 5, 2015 at 5:17 PM, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
Note the deletions aren't intended to be "irrevocable". Once phase 2 of this project is done someone could go through and re-add the tag to each thing it was removed from. Kind of like with Special:Nuke, someone could go through and undelete everything that was deleted.
The one roadblock there is that it doesn't currently log every item that the tag got deleted from. Besides log flooding, though, there's no reason it *couldn't* do that.
If we could find a way to do this without a log flooding problem, I'd be fine with deleting tags.
move-over-redirect is an irrevocable deletion ;)
Well, technically the revision goes away, but the log entries contain enough information to determine exactly what was in it, sufficient to reconstruct it.
On Thu, Feb 5, 2015 at 9:04 PM, Jackmcbarn jackmcbarn@gmail.com wrote:
Well, technically the revision goes away, but the log entries contain enough information to determine exactly what was in it, sufficient to reconstruct it.
It'll tell you where it redirected to, but not whatever additional content (if any) was on the page besides the redirect.
On Fri, Feb 6, 2015 at 3:31 AM, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
On Thu, Feb 5, 2015 at 9:04 PM, Jackmcbarn jackmcbarn@gmail.com wrote:
Well, technically the revision goes away, but the log entries contain enough information to determine exactly what was in it, sufficient to reconstruct it.
It'll tell you where it redirected to, but not whatever additional content (if any) was on the page besides the redirect.
And who created the redirect and when. (But I guess this is off-topic here. Is there a Phabricator bug for this?)
-- [[cs:User:Mormegil | Petr Kadlec]]
I would suggest that the potential "danger" of such a right is mitigated by the following:
* It is not possible to delete change tags defined by an extension unless the extension specifically allows it (which none currently do). That means that active AbuseFilter tags, tags like `visualeditor`, etc. cannot be deleted. The exception to this is OAuth, which should really be fixed not to allow its tags to be deleted.
* The feature is currently limited to deleting tags used by <= 5,000 revisions. (This may change in the future.)
On enwiki, this would allow old, inactive AbuseFilter tags to be cleaned up (like "michael jackson"). These tags are in most cases applied to old revisions, and seeing as the intention of tags is to help patrolling of recent edits, I don't think this is a big enough deal to require logging every single revision to which the tag was (in many cases, probably erroneously) applied.
TTO
"Jackmcbarn" wrote in message news:CAOx5P=+gAkH_-k3uUAFF4fCTy16BQH9ibihV57t56x=h4QB=BA@mail.gmail.com...
Gerrit change 181958[1] was recently merged, which allows (among other things) the ability for sysops to irrecoverably delete change tags. Since irrecoverable deletion of anything from on-wiki is rather unprecedented, I think we should stop granting it to all sysops in DefaultSettings.php, so that wikis have to "opt-in" for this feature to be enabled. Thoughts?
[1]https://gerrit.wikimedia.org/r/#/c/181958/ _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 5 February 2015 at 15:43, This, that and the other at.light@live.com.au wrote:
I would suggest that the potential "danger" of such a right is mitigated by the following:
- It is not possible to delete change tags defined by an extension unless
the extension specifically allows it (which none currently do). That means that active AbuseFilter tags, tags like `visualeditor`, etc. cannot be deleted. The exception to this is OAuth, which should really be fixed not to allow its tags to be deleted.
Fair.
- The feature is currently limited to deleting tags used by <= 5,000
revisions. (This may change in the future.)
On enwiki, this would allow old, inactive AbuseFilter tags to be cleaned up (like "michael jackson"). These tags are in most cases applied to old revisions, and seeing as the intention of tags is to help patrolling of recent edits,
{{cn}}
I know for one that they're frequently used for analytical purposes to track behaviour and performance. The AF ones aren't, but AbuseFilter's use of tags is (numerically) niche. Maybe we should first have a conversation about what we want tags to be, before rushing around making potentially regrettable changes?
J.
On Thu, Feb 5, 2015 at 6:53 PM, James Forrester jforrester@wikimedia.org wrote:
I know for one that they're frequently used for analytical purposes to track behaviour and performance. The AF ones aren't, but AbuseFilter's use of tags is (numerically) niche.
I don't know that I'd call 3410388 out of 9051234 (37.68%) on enwiki "numerically niche". And if we exclude the 2330952 HHVM tags from the total, it's up to 50.57%. Other wikis, perhaps, have less AF use and more VE.
But as long as whatever "analytical purpose" that added the tag continues to respond to the ListDefinedTags hook, the tag can't be deleted by this mechanism unless it's explicitly allowed by the ChangeTagCanDelete hook. So excessive concern over those being deleted seems like it's just that, excessive.
On Thu, Feb 5, 2015 at 6:43 PM, This, that and the other < at.light@live.com.au> wrote:
The exception to this is OAuth, which should really be fixed not to allow its tags to be deleted.
https://gerrit.wikimedia.org/r/#/c/187624/
wikitech-l@lists.wikimedia.org