User talk:ChristianKl/Draft:ProposeDeletion

Rollbackers are not legitimated by a community vote

I find it highly problematic to allow rollbackers to place this tag. Rollback rights have been assigned by admins per request to users basically based on their counter-vandalism activities, not whether they are able to assess notability. Furthermore, there was no community vote to legitimate their "deletion capabilities" in case they could add this tag. I think we should not even consider to take this path. —MisterSynergy (talk) 12:56, 3 December 2020 (UTC)

• I believe that this right should not be available to every autoconfirmed users. At the same time I believe that it would be benefitial if non-admins can do part of the work. We could also create a new right for this function. ChristianKl ❪✉❫ 14:49, 3 December 2020 (UTC)
  • Deletion rights need a community vote, and thus effectively admin rights. I do not think that there is a need for an "admin-light" groupy that only allows to nominate items for deletion. —MisterSynergy (talk) 18:44, 3 December 2020 (UTC)
    • I think the prime reason why direct deletion rights need a community vote is because it's about trust to engage in actions that the community can't review. In this case nothing happens when the tag gets removed and we have an automatic process that happens to evaluate the quality of the deletion vote. In the deletion discussions it's easy to see when a user nominates items that are notable and then the user can be stripped of the right. ChristianKl ❪✉❫ 18:57, 3 December 2020 (UTC)
• I was once told that deletion is a "extremely schematic process that in most cases does not require any community input" and that deleting things incorrectly is no big deal because the "undeletion process is similarly unbureaucratic". So I don't think we need to worry. BrokenSegue (talk) 19:07, 3 December 2020 (UTC)
  • I don't think "undeletion process is similarly unbureaucratic" until we have a clear process about how undeletion requests are proceeded. I have raised this point before (see Special:WhatLinksHere/Q22959230).--GZWDer (talk) 17:28, 4 December 2020 (UTC)
    • Yeah sorry that was meant to be somewhat cheeky (I was quoting MisterSynergy). BrokenSegue (talk) 19:21, 4 December 2020 (UTC)

Do not mix meta stuff into items

Claims in items describe the entity, not the item itself. I would prefer to keep this separation and not use any properties or so in main or lexeme namespace to manage such a scheme. If at all, it should be done using templates on the item talk page only; categories could be used to manage and oversee the nominated items. —MisterSynergy (talk) 12:56, 3 December 2020 (UTC)

• Adding a statement to the item has the advantage that it shows up on watchlists for the item and is also within reach of SPARQL. Being able to use it with QuickStatements is also advantagous. ChristianKl ❪✉❫ 15:14, 3 December 2020 (UTC)
  • Yeah, but you effectively propose to abandon important principals for mere convenience. The main namespace becomes more and more messi this way. That said, template transclusions and categories can be queried using Petscan, thus accessibility is not an issue. Item talk page edits of watched items also show up on watchlists. Using QS here does not seem to be desirable at all. —MisterSynergy (talk) 18:46, 3 December 2020 (UTC)

• I don't think principals should stand in the way of convenience here. I argue maintained by WikiProject (P6104) and maybe on focus list of Wikimedia project (P5008) already violates the principle since they are about the item itself more than the concept. We could even phrase the property to make it about the concept if we squinted. I don't see any harm done by violating the principle here. BrokenSegue (talk) 19:02, 3 December 2020 (UTC)
• I do support adding metadata about the item themselves if the data is clearly differentiated and the usage is limited. I have created Wikidata property about Wikidata entities themselves (Q103824108) for such usage.--GZWDer (talk) 17:34, 4 December 2020 (UTC)
• I've been using Wikimedia duplicated page (Q17362920) on some items that cannot be deleted because they have links to a project that rhymes with cebwiki. I'm not neccessarily convinced of the wisdom of that practice, but it's similar and should probably be aligned with whatever practice is ultimately adopted here. --Matthias Winkelmann (talk) 23:47, 4 December 2020 (UTC)

Deletion bot

The proposal states that the item should be "automatically deleted" if no editor opposed within five days. We need to consider situations were someone forgot to remove the tag, but has edited the item, or placed a backlink, or put it into use in some remote Wikimedia project. This would result in "structural need" which is not directly obvious. The deletion bot would need to be relatively sophisticated in order not to delete items which meet the notability requirements. Since notability is a technical concept here, this is possible without doubt, but the bot script is going to be relatively complex and the operator needs to devote substantial resources for bot operations. —MisterSynergy (talk) 12:56, 3 December 2020 (UTC)

• I don't get the difficulty here. All the bot needs to consider is "is it linked from another item / wiki" (optimally a few other things like is it used as a wiki citation). Does wikibase even let you delete items that are linked from other items? When you say "substantial resources" do you mean compute? Or coding time? I would imagine this would run on wikimedia infrastructure. BrokenSegue (talk) 18:58, 3 December 2020 (UTC)
  • Admins can delete every page, the only limitation to my knowledge is some upper number of revisions just as in Wikipedia (500 or 5000? not exactly sure). Whether there are backlinks or use in Wikimedia projects or existing sitelinks does not matter.
    The bot operator needs to code something in the beginning, improve the code until most possible edge cases are considered, and then deal with all the hassle that come with such a task. The difficulty is that the bot needs to correctly process whatever item is thrown at it, since the bot operator is not feeding the bot with input by themselves. In other words: operating this bot eats the operator's time. —MisterSynergy (talk) 19:23, 3 December 2020 (UTC)
    • I would propose that during the authoring process the bot be written to just list pages it "would have deleted" somewhere. In this transition period admins can sweep through the page daily to ensure no errors have been made. Once it has run for some time without error we switch it to actually deleting. In the event the bot is never authored or is abandoned approving this RFC will have had minimal negative effect. BrokenSegue (talk)

Responsibilities

In case an item is eventually deleted based on such a scheme, who is considered to be responsible for the deletion? The bot operator or the editor who tagged the item? Both sides can potentially make mistakes here, neither wants to be held responsible for mistakes of the other party. —MisterSynergy (talk) 12:56, 3 December 2020 (UTC)

• The person who tags items this way is responsible for the act of tagging whether or not the item gets deleted. If an editor adds a significant amount of proposed deletions items that were notable at the point where they add the tag, they should lose the right to propose deletions whether or not this results in actual deletions.

The bot operator is responsible for the bot behaving as laid out in the policy. ChristianKl ❪✉❫ 15:09, 3 December 2020 (UTC)

Can the deletion bot be blocked or have admin rights removed? What happens when the operator disappears?

So this needs a deletion bot that fulfills a job which is proposed to be cast into a policy. What if the admin bot does not do its job appropriately or the operator disappears/resigns? The deletion workflow has a relatively high workload, and I do not think that we can afford periods without a functioning deletion process. Yet, a replacement bot would probably not be available within a short time. —MisterSynergy (talk) 12:56, 3 December 2020 (UTC)

• In lessons from KrBot whose blocking disrupted our merge workflow, we should likely specify that the bot is a single purpose bot.

We could specify that the bots code should be published on Github. Once the bot is working a few users could fork it to have the code for replacement situations. ChristianKl ❪✉❫ 15:19, 3 December 2020 (UTC)

• I would offer to author/run such a bot. The code should have to be open source and easy to deploy anywhere. In the event the bot disappears worst case in the weeks before a replacement is ready admins could go through the listing of pages tagged with the property manually which doesn't seem much harder than looking at RfD listings. Or else the policy could be reverted to its current state and we are no worse off for having tried this. BrokenSegue (talk) 18:55, 3 December 2020 (UTC)

Opt-out from a notification scheme

There are quite a lot of users who create a substantial amount of items which later get deleted (usual scenario: import unconnected Wikipedia pages which are later being deleted). I am 100% sure that many of them do not want to be notified of the proposed deletion. We thus need at least an opt-out of the notification scheme. —MisterSynergy (talk) 12:56, 3 December 2020 (UTC)

• While having an opt-out of notification makes the implementation more complex it's easily doable. ChristianKl ❪✉❫ 18:58, 3 December 2020 (UTC)
• It seems to me that the burden on a user of receiving deletion notifications is less than the burden on the rest of the community from having someone create items that need to be deleted. Bovlb (talk) 03:21, 5 December 2020 (UTC)

Workload in general

We delete roughly 500 items per day, and there is a substantial amount of items that would require an assessment as well, but slip through due to a severe shortage of admin resources. Furthermore, around 90% of the deletions are being carried out by only 10 admins, one of them is an admin-bot. Do we have any idea how much this proposed scheme would increase the workload necessary to manage the deletions? Apparently it does not really lower the workload, as one would have to assess an item's notability in order to propose it for deletion. —MisterSynergy (talk) 12:56, 3 December 2020 (UTC)

• The workload for non-contested deletions stays the same. Given regular users of RfD the right to use this process allows the workload to be spread over more people given that the right is less sensitive then other admin rights.

Users contesting certain deletions creates additional workload but it will result in some items being brought up to our standards and users learning about what makes items notable. ChristianKl ❪✉❫ 14:59, 3 December 2020 (UTC)

• I don't see how this would possibly increase the per-admin workload unless it increases the total number of deletions which is probably a good thing. We want to devolve more decisions to non-admins like myself and only bother admins when there's a conflict. Currently if I accidentally make an item or see some clear nonsense I have to bother an admin to deal with it. BrokenSegue (talk) 18:51, 3 December 2020 (UTC)
  • Most deletion are about "empty items" and I proposed some types of them may be handled via a Wikidata:Speedy deletion. (I does not expect all; if a local article is deleted for lack of notability, its Wikidata item should still be handled by PROD. Speedy deletion only applies if the item can not refers to any valid potential topic.)--GZWDer (talk) 17:41, 4 December 2020 (UTC)

Comments

Man seems like someone really dislikes this idea... Anyways I generally like this proposal. I would offer a few amendments:

• If the item cannot be deleted (e.g. because it is linked) the bot should list the item on RfD
• I anticipate people saying that they have made too many items and do not want to be pinged. Opting out of these should be doable by adding a template to their user page.
• If people are worried about abuse I would suggest not allowing "proposed deletion" of items beyond some age or with more than some number of non-bot edits. Or else not allowing proposed deletion of pages made by certain classes of users.
• If a user nominates their own item and they are the only editor it should skip the waiting period.

BrokenSegue (talk) 18:48, 3 December 2020 (UTC)

• There are spam pages that get created on other Wikis. The relevant Wikidata item can only be deleted once all the Wikipedia pages get deleted. In those cases it's not useful to have an entry on RfD that's not actionable. Items should only go to RfD when they need attention from users of Wikidata.

Instead of making preventive bureaucratic rules about age/number of non-bot edits/user classes of items that shouldn't be subject to this procedure, I think it's better to trust users to use the procedure and make rules against abuse if we witness specific abuse that needs to be fought.

I don't think we should think of items as owned. There are multiple scenario's where users want to delete their items but there are reasons against it. The item might be a doublicate that should rather be merged. ChristianKl ❪✉❫ 00:37, 4 December 2020 (UTC)

NoPingOnProposedDeletion

Re. Special:Diff/1317355052: A "NoPingOnProposedDeletion" template does not work for global user pages from metawiki. —MisterSynergy (talk) 19:15, 3 December 2020 (UTC)

why not? the bot could just also check the user's metawiki page? i assume it's possible to map wikidata usernames to metawiki ones (I'm not sure if they are always the same). BrokenSegue (talk)

You cannot transclude the template from meta, and it is also meaningless for all other projects where the global user pages is displayed. —MisterSynergy (talk) 19:30, 3 December 2020 (UTC)

Just make the template on meta. And it'll have meaning because the bot will look for it. No? It could be invisible. BrokenSegue (talk) 19:32, 3 December 2020 (UTC)

If a person doesn't want to get the pings they can create a Wikidata user page. I don't see why that's too much effort for users who don't want to get pinged. ChristianKl ❪✉❫ 19:25, 3 December 2020 (UTC)

Well, the Wikidata user page overwrites the global user page and this is clearly not desirable. It is the purpose of these global user pages that they look the same everywhere. —MisterSynergy (talk) 19:30, 3 December 2020 (UTC)

Okay, then we change the solution so that there's a page on Wikidata where everyone who wants to opt-out of notifications via this mechanism can add their username. ChristianKl ❪✉❫ 20:13, 3 December 2020 (UTC)

Speedy deletion

I will support it but I will not support without a Wikidata:Speedy deletion. Things like test and vandalism should be deleted immediately. (Note here I intentionally exclude spams, for the potential usage in Wikivoyage).--GZWDer (talk) 17:38, 4 December 2020 (UTC)

@GZWDer: Can you elaborate on why you see speedy deletion as a requisite for this policy? What would happen if we had one but not the other. I would add that some admins already seem to interpret currency policy to mean that the current RfD policy is basically a speedy deletion system with no required discussion or waiting period. It's just not speedy because of a lack of admins. BrokenSegue (talk) 17:48, 4 December 2020 (UTC)

• @GZWDer: at the moment I don't propose having a rule that bans admins from using their existing deletion powers. I think a first RfC should establish this as a new principle that admins are encouraged to use over direct deletion for a majority of deletions but no rule that bans any existing processes. If the new process works well in practice a new RfC could put limits on admins deleting items directly.

To the extend that this policy allows non-admins to nominate items for deletion, those items shouldn't immediately be removed without admin oversight. If a non-admin nominates a page as being a test creation, an admin might have a listeria list that shows him the items and delete them manually, but there's no rule forcing that. ChristianKl ❪✉❫ 17:56, 4 December 2020 (UTC)

@BrokenSegue: In Wikidata:Project_chat#Q59318277_seems_to_have_disappeared, I proposed to introduce a mandatory 7-day period in RfD. Therefore, in my opinion:

1. Items that is speedy deletable may still be deleted immediately. This speedy deletion policy is intentionally to be very narrow. (For example, Someone created a item for a local restaurant with only some contact information. This seems like spam, but it is of the scope of Wikivoyage. Many companies are described in many sources too.)
2. Rollbackers (or other eligible users) may PROD an item 5-day process. (Optionally I also proposed a (not-yet-written) endorsement process, such that some kinds of pages endorsed by administrators may be deleted after three, instead of five, days.)
3. Other deletion via RfD - 7-day process (Unlike English Wikipedia, pages in RfD are still Prodable as long as there are no oppose in RfD).

@ChristianKl: I proposed that admins can delete an item without discussion if it meets the speedy deletion policy. Charlotte Gerson (Q22959230) was deleted (with a RfD) even if this item is salvageable. Instead, an admin-endorsed Prod may be handled in two or three, instead of five, days.

--GZWDer (talk) 18:05, 4 December 2020 (UTC)

While I agree your three pronged system is better than what we have today (and a good goal state) I personally wouldn't want to risk further opposition to reform by linking them together into a bigger proposal. BrokenSegue (talk) 18:15, 4 December 2020 (UTC)

This proposal is currently worded in a way that items which are are RfD aren't automatically removed given that they are "used by another Wikimedia page". For non-admins that might seem a bit strange but currently when deleting an item from RfD Wikidata shows "Warning: Other pages link to or transclude the page you are about to delete." given that the item is used in RfD.

I think both an explicit speedy deletion policy and a change of RfD that makes it a 7 day process have merit but solving those issues when creating the PROD policy creates unneccesary complexity. ChristianKl ❪✉❫ 18:29, 4 December 2020 (UTC)

Prod by non-rollbacker

As another idea of mine, I proposed that non-rollbacker can still Prod an item but for a Prod to be valid they must be endorsed by a rollbacker. A bot will list all Prods by non-rollbackers to review and ideally this should not cause a large backlog.--GZWDer (talk) 18:23, 4 December 2020 (UTC)

• Okay, I think we can deprecate the PRODs by users without right to PROD instead of removing it. ChristianKl ❪✉❫ 18:31, 4 December 2020 (UTC)

Requirements for adding PROD

I would like a system where a decision whether or not to add PROD can be made by looking at the item in question. For that reason I wouldn't put requirements that are about what happens outside of the item in the usage category. In any case where there's disagreement, items shouldn't be automatically deleted by the PROD process but via an automatically created request for deletion discussion.

Automated processes that remove PROD from items that have been already proposed for deletion are better then rules forbidding PROD to be added to those. This means that users who had PROD don't have to worry about possible losing their right to PROD because they used it a bunch of times for items that are proposed for deletion.

The process should be as unbureaucratic as possible. Users who's items get deleted should generally be allowed to have a conversation about the removal. If a user created an item that's not notable, they should be allowed to remove PROD and get a hearing for their item in Request for Deletions where they can learn the problems that make the item fail the notability criteria. ChristianKl ❪✉❫ 20:56, 4 December 2020 (UTC)

Creating a new right instead of reusing rollbackers

Given that we give out the rollbacker right to users who have experience with the rollbacker right in other Wikiprojects but not necessarily a strong understanding of Wikipedia it seems better to have a special right for this functionality that's based on a users interaction with our Request for Deletion process. ChristianKl ❪✉❫ 13:08, 5 December 2020 (UTC)

Should this group have the right to delete pages directly? In my opinion once Wikidata:Speedy deletion is a thing and admins can not immediately delete arbitrary pages it would be useful for this group to have the right to directly delete pages. So that they can also close RfD (but not one the user is involved). Note what Legal really concern is the access of deleted content, not the deletion themselves (see phab:T113109#1691843).--GZWDer (talk) 17:54, 5 December 2020 (UTC)

No, it's a lot harder to detect when a user deletes pages directly in a problematic way then when they propose items for deletion in a problematic way. If a user with this right proposes a bunch of deletions for notable items it's easy for other users to remove the proposed deletion with results in Request for Deletions. Questionable request for deletions are then quite visible to users who browse Request for Deletions regularly. ChristianKl ❪✉❫ 20:57, 5 December 2020 (UTC)

Is making a new right easy? Does it require dev effort? BrokenSegue (talk) 22:45, 5 December 2020 (UTC)

https://www.mediawiki.org/wiki/Manual:User_rights suggests that MediaWiki supports adding user groups, so I expect that a Bureaucrat can do it without dev effort. As far as MediaWiki is concerned this is a new user group without special rights.ChristianKl ❪✉❫ 12:33, 6 December 2020 (UTC)

To create a new user group a Phabricator task is required. Alternatively the list of members may be maintained in a protected page like w:Wikipedia:AutoWikiBrowser/CheckPage, but it will not be helpful if we want to introduce AbuseFilter about this workflow.--GZWDer (talk) 14:23, 6 December 2020 (UTC)

@GZWDer: would a AbuseFilter that forbids users outside of the group from adding the tag but allows them to remove it be possible? ChristianKl ❪✉❫ 15:09, 6 December 2020 (UTC)

It is possible, but given how we handle this at User:ChristianKl/Draft:ProposeDeletion#Detecting_new_propose_deletion_for_reason_by_a_ineligible_user, we should only record them and let the bot handle the rest. Note rollbacks seem completely bypassing AbuseFilter.--GZWDer (talk) 15:11, 6 December 2020 (UTC)

What happened?

@ChristianKl: What became of this draft? Do you plan to move forward? Did you think the feedback was too negative? BrokenSegue (talk) 04:31, 19 January 2021 (UTC)