Previous discussion: Forum:A new User Group?.
So recently the idea of having our custodian usergroup to delete files was brought up in S:C and a couple people favoured it so I thought I'd take the liberty of creating the forum as someone else said that they think it's not possible to do this without having them being able to delete from other namespaces too.
They're partly right about that, as the custodian group would need the whole
delete permission to be able to delete anything. However it's possible to restrict them to only be allowed to do this in the File namespace (and presumably file talk too).
Another wiki that I edit on, the MLP wiki, we have an equivalent of custodian usergroup called Image Control. They're able to rename/move files (like our custodians can) but they can also delete/restore files. They have the entire delete permission but we used implemented an abuse filter to restrict them to file and file talk namespaces only. For those who can't see that page, this is how it looks:
We could export that filter to this wiki (or change the one we have to match this if we already have this sort of filter in place), and change the namespaces to match ours and anything else necessary then contact Wikia to give the delete permission if this gets enough support, so custodians could delete/merge/restore files as well. Opinions on this? – Ozank Cx 09:44, March 26, 2014 (UTC)
Support - I think custodians should definitely have these rights, as bogus files are more than often added when no admins are around. Custodians can also manage files without keeping admins of whatever important thing they are doing.09:51, March 26, 2014 (UTC)
Question - Would it be possible to
make a new usergroup for this or overhaul the custodian usergroup? There are currently 65 custodians on the wiki, and any user can obtain custodianship so long as they have ≥400 edits in the mainspace and ≥150 edits in the file namespace. If this proposal is successful, I would like to see the requirements to obtain custodianship altered in some way. Temujin 09:52, March 26, 2014 (UTC)
- I don't think it's worthwhile to make a new usergroup for people who have more power over files in one aspect. But it's certainly possible, yes. My opinion is that custodians currently usually have a good overview of whats a good file and whats a bad file, so I personally don't think the requirements need buffing. – Ozank Cx 09:58, March 26, 2014 (UTC)
- In my opinion, per Temu, custodians should definitely have the requirements set a bit higher to make sure they deserve the tools they are going to be able to use. Custodians will have the power to wipe a lot of images, and this power should not be given to anyone with a decent editcount. 10:00, March 26, 2014 (UTC)
- I share your opinion of custodians, but I feel that the current requirements do not ensure that future custodians will have a good overview of what's a good file and what's a bad file. Temujin 10:01, March 26, 2014 (UTC)
Support, hmm - Giving custodians the ability to delete and restore files is a good idea, but I'd prefer if the requirements for custodians be set a bit higher since deletion tools are a big responsibility to handle. -- SpineTalk 10:46, March 26, 2014 (UTC)
Oppose - Per the reasons states here: You're pretty much summing up an administrator, however, only limited in the file space. If I trust you deleting, merging, or undeleting images, then I don't see why you can't just run for admin now (although then there's the case of maturity, responsibility, etc, which I would also judge on you equally becoming this new usergroup). Haidro (talk) 11:04, March 26, 2014 (UTC)
- The custodian right only allows users to move files; if they can be trusted to move them then why can't they delete them too? That's a tiny part of administrator that they're getting - and they already have one. I don't see why we should have to get an admin to merge files when people are capable of doing it themselves, and some of us don't want to run for fully-fledged adminship. – Ozank Cx 11:29, March 26, 2014 (UTC)
- Because there's a big difference between moving a file and deleting a file. You would be able to remove content from the wiki which I see only an administrator should be able to do. Moving a file basically does nothing except make it easier for people to add files to pages, and is something that we can trust on people who aren't able to become an admin but have a use for such tools. If you're capable of having the responsibility and maturity to delete stuff, then apply for admin. If you don't want to, then that's not my problem. Haidro (talk) 11:51, March 26, 2014 (UTC)
Oppose - Whilst this proposal has some merits, I disagree that granting it to every custodian we have is a good idea. There have been numerous breaches of 3RR in file uploads, and I doubt this is the only policy broken by custodians. Whether we admit it or not, we hold admins to a higher standard of behaviour because of the extra tools we grant them. Whilst this might seem like a trivial tool to some, it does imply a level of trust that I simply don't have in every custodian.
The other issue is the general lack of need for deletes by custodians. I know there are rare instances of speedy move, speedy deletions and merges building up, but I haven't seen either above 5 for a long time and I check them every day I'm on the wiki, often multiple times on the same day. User:Cqm/Signature
Neutral - While it would make things like merging files a LOT easier, I'm not sure. Custodian is not a group given by consensus - on the other hand, you have to apply for it and then an admin decides whether you should get it, and the admin is chosen by consensus. I'm not against the proposal per se, but I understand, and to some extent share, the want for more restrictions on custodianship. More than just a higher edit count than the current requirement. Oil4 Talk 12:46, March 26, 2014 (UTC)
Strong oppose - We are not your wiki Ozzy; the level of trust is different here than it is there. I'm surprised your version of custodians can delete anything considering only your admins are allowed to create redirects.
Files are just as much content as pages in the mainspace are. This thread is proposing we trust every custodian with the rights to delete files (read: content), when you can look at past RFA's of custodians to see the opposite is the case. Given how images and media are just as much content as articles, anyone whom you'd trust to be in the custodian usergroup, you'd trust to be in admin. If this is not the case, you have no reason to support this thread. If it is, then you're really just trying to create a redundant usergroup.
Moving files without leaving a redirect is very much different from deleting a file. The only point need be made is that the file will still exist. I trust most every custodian with this, and that's why I've even vouched for them to have the "requirements" ignored (some of whom have already commented here; e.g. Everystat13).
The ability to delete anything should not be based on quantified requirements. Just because you got a certain number of edits does not mean I trust you. If you look at many of the early RFAs, you'll see a number of nominators, supporters, and opposers alike who base their stance on editcount. You'll see just as well how many of them had that base corrected. Edits by quantity do not make you more trustworthy. The only reason the current "requirements" are there is as a deter for power hunger. As I've said before, I've vouched for plenty of current custodians to have them waived, and plenty of other admins have waived them as well. I especially don't trust most of the users who are already custodians to delete files just because they can already move them. Thus, we'd have to do this by consensus. In other words, we'd be creating a relabeled RFA.
This proposal itself (ignoring what I've already argued) isn't all that beneficial to us. If a file really is to be deleted, it'll have been removed from the pages it was on and tagged for deletion. No one who doesn't need to see it will likely see it, and it doesn't really matter when it gets deleted. The thought that it's a "waste of an admin's time" is ridiculous because that's why admins exist: to delete (amongst other tasks). Very few files are tagged regularly and with plenty of admins around (there is almost always at least 1 watching recent changes or otherwise contactable), what's the benefit? With how little we've seen file deletions required, I can only see this becoming a mostly stagnant usergroup. The main deleters would be a small handful of people. Custodianship would become a less accessible usergroup to the benefit of only a few people. I think this idea's proposed benefits aren't strong enough at all to warrant its implementation. MolMan 12:54, March 26, 2014 (UTC)
Oppose - Per pretty much everyone else, also Oil brings up a good point about becoming custodian through means other than consensus. The reason we painfully tried to work with Wikia to get a custodian usergroup is because regular users can move mainspace pages. If they can move mainspace pages, they should be able to move images too. Regular users can't delete mainspace pages. Likewise, why should they be able to delete images? Permanently deleting something off the wiki to the point where only admins can see what it used to be is completely different from moving files. If it is that important to you, run for adminship. User:Urbancowgurl777/Signature 15:04, March 26, 2014 (UTC)
Oppose - This is the same old rights creep that we had to deal with on Forum:Custodians and MediaWiki, where it was proposed that we allow custodians to edit MediaWiki pages. In that thread, as in this one, people proposed increasing the editcount requirement for the custodian group to compensate for the increase in rights. People are trying to turn the usergroup into a kind of admin-lite with greater responsibility but also higher barriers to entry. Even without looking at the merits of file deletion, I think that's a bad idea.
As for the actual proposal, no, I don't trust any of the custodians currently to delete files. Right now custodian is an informal usergroup that we tend to give to whoever is reasonably well-trusted and shows an interest in moving files. Allowing them to delete files is not just an issue of maturity, it's also dependent on knowing the relevant policies and being able to use them correctly. If you want to delete files, do an RfA. We have had exactly two in the last year. ʞooɔ 19:32, March 26, 2014 (UTC)
Oppose - Deletions and merges are rarely a matter of urgency. The extremely rare instance of an image that has to be deleted instantly (e.g. pornographic images) due to being visible on every page due to the side bar, is so infrequent that I can't remember the last time we had an upload like that. Any other deletion, or merge, can wait until a sysop is paying attention if they aren't at the time of the file's occurrence.
There are 10 sysops that I can think of, off the top of my head, that frequent [[Special:Chat]]. There's usually at least one of these in chat and paying attention (or pingable) to handle file issues. Why, then, is it necessary for custodians to do deletes or merges instead?19:40, March 26, 2014 (UTC)
(Slight) Oppose - Admins are usually/always on chat, and besides, talk pages are always useful, so there isn't much of a problem contacting them to delete an image. Trust shouldn't be much of a problem, but really, deleting images is an admin's job and isn't that necessary for a custodian to do. User:ChaoticShadow/SigReal
If this thread is successful, then I think that the requirements for a user to obtain custodianship should be raised to ≥1,200 edits in the mainspace and ≥450 edits in the file namespace. Temujin 10:58, March 26, 2014 (UTC)
Oppose - If this thread were to pass, this is not something I would like to see. Being able to delete something requires trust and experience, not an edit count. I would think something like a process similar to RfCM/RfA (perhaps running for a week) would suffice. Haidro (talk) 11:06, March 26, 2014 (UTC)
- I'm not opposed to such a system, but I feel that merely increasing the number of edits required to obtain custodianship would receive greater support. Temujin 11:15, March 26, 2014 (UTC)
- Haidro has a point. This needs a formalised process should it pass. User:Cqm/Signature
- I disagree with this statement. User:Urbancowgurl777/Signature 15:04, March 26, 2014 (UTC)
- How much immaturity could someone who deals with maintenance possibly get into? Isn't that what some people dinged you for? --LiquidTalk 15:09, March 26, 2014 (UTC)
- Apparently a lot since maintenance was what I was running on. I wouldn't trust a large portion of our custodians with the deletion tool due to their maturity issues (not acknowledging that I was immature at the time of my RfA). User:Urbancowgurl777/Signature 15:11, March 26, 2014 (UTC)
- Well I wouldn't trust just any random person with tools like deletion, blocking, giving out custodian etc. That does require some degree of maturity to properly handle. Oil4 Talk 15:39, March 26, 2014 (UTC)
- How much immaturity could someone who deals with maintenance possibly get into? Isn't that what some people dinged you for? --LiquidTalk 15:09, March 26, 2014 (UTC)
Oppose - This is not a well thought out idea. It may seem as though it would be advantageous at first, but practically speaking what is being proposed would do us no favours. The custodian userright in its current form is well suited to the people who request it without being added on to. Ronan Talk 23:06, March 26, 2014 (UTC)
Viewing undeleted files
Whilst I and several others have opposed giving custodians the delete right, I would support letting custodians view deleted files. It's more or less an extension to the viewing deleted history rights they have currently and the only reason they can't do it now is because it requires a hash of the filename (deleted files aren't named the same as normal files). When I was a custodian I often found myself requesting admins check if a file could be undeleted or requesting a link to the deleted file image. I think this requires the undelete right, but we can easily add an abusefilter to block any attempts to undelete any pages.
Support letting custodians view deleted files - User:Cqm/Signature
Support - I've been wondering why we couldn't view deleted files. It might be handy just to view them, and we can then always ask an admin to undelete it if really necessary. AmoVos 09:43, April 4, 2014 (UTC)
- It's purely down to mediawiki not separating out the permissions for viewing deleted files and undeleting them. Otherwise the request would have likely been tagged onto the forum giving custodians the rights for viewing deleted revisions. User:Cqm/Signature
Support - Per Oil.
Oil4 I made this 10:53, April 4, 2014 (UTC)
Neutral - This really doesn't matter at all. I mean, we can't (or at least shouldn't) really do anything with these files, there's also usually an admin around if we actually need it (not that looking at a deleted file is ever urgent). At the same time, it won't really affect anything. Though I do wonder if we can get a unique right that doesn't involve preventing undeletion with the abuse filter. An oddity I've noticed is that if a deleted file is then "super deleted" (as it were) with revisiondelete, us custodians can view the file. Hopefully Cam can abuse his tools just this once to create an example, as the only one I can give is some very nasty porn. MolMan 19:28, April 4, 2014 (UTC)
- I requested it dozens of times when I was adding transcripts, and whilst it's never urgent it handy to be able to do something yourself. The unique right isn't going to become available any time soon - it should be requested in core if you have any hope of it being added.
- As for the example file, I couldn't reproduce a custodian being able to delete it. If you want to have a go yourself, you can try at File:Cqm test.png. It's a DII of olive oil if anyone's interested. User:Cqm/Signature
Support - Per Oil. User:ChaoticShadow/SigReal
Support - I've often had the need for it and it can do no harm, AFAIC.07:48, April 5, 2014 (UTC)
Support - There's no reason why not, custodians can already view the file history, being unable to view the file itself is just annoying.09:29, April 5, 2014 (UTC)
Comment - I appear have hit a flaw in my brilliant idea: AbuseFilter doesn't support the undelete action. Unless someone better with AF than me can find a workaround, we may have to scrap this idea.
As for the revdel-deleted image bug Mol found, It looks like a bug in core mw, but it'll need verifying in 1.23 (the current dev version) and backporting, as wikia have a tendency to not fix core bugs and let the mw devs fix them instead. User:Cqm/Signature
- After looking for a workaround for a while, I was indeed unable to find any way to make an abusefilter for undeletion, so it looks like this idea is off the table too. JOEYTJE50TALK pull my finger 17:10, April 9, 2014 (UTC)
Comment - Since the third proposal is not possible to implement, I am going to close this thread tomorrow if nobody has anything left to say about the currently listed proposals. If you have yet another proposal though, please start a new thread instead of appending a section here. JOEYTJE50TALK pull my finger 17:10, April 9, 2014 (UTC)
Closed - For each of the proposals:
- As the custodian usergroup requires no community consensus, the deletion right is a too powerful right to add to this usergroup. If users feel like they would be able to make good use of this tool, they are free to request sysop tools.
- Aside from having no support from the community, this proposal also includes the prerequisite of the first proposal being successful, which it was not.
- As noted in Cam's comment, this is not technically possible to implement with the current AbuseFilter. Despite the general support for this idea, this proposal can't be implemented at this time. If a new version of the extension is released which does make this possible, this can be brought up again again.