Commons:Village pump/Proposals/Archive/2024/04

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Creating a WikiProject

Hi. I'm interesting in creating a WikiProject to better coordinate and keep track of things related to "post." For instance postage stamps, postal covers, images of post offices, Etc. Etc. There's currently a category for Category:WikiProject Philately but it seems to be dead and doesn't really cover the same areas I want the project to related to anyway. There's also Category:WikiProject Postcards, which is certainly active, but it's to specific and I don't want to tromp on their territory anyway. Unfortunately Commons:WikiProject doesn't seem to give any guidance of how to create a WikiProject in the meantime. Except that it can be discussed here. So what exactly is the process to create a WikiProject? Can I just create one if I want to or do I have to go through some kind of formal proposal process? Adamant1 (talk) 00:10, 6 April 2024 (UTC)

You might do better to revive WikiProject Philately (even with a broader scope) rather than start something new. - Jmabel ! talk 01:00, 6 April 2024 (UTC)
That's actually not a bad idea now that you mention it. Am I correct to assume I can do it without much ceremony? --Adamant1 (talk) 01:23, 6 April 2024 (UTC)
Correct. Frankly, it doesn't look like this project was ever really active - there's no substance to it beyond that one empty category page! - so you can go right ahead and make it your own. Omphalographer (talk) 04:02, 6 April 2024 (UTC)
Sweet. I'll probably just do that then. --Adamant1 (talk) 04:19, 6 April 2024 (UTC)

Discussion about new tool for detecting logos

We're having a discussion at the Technical Village Pump about a new tool for detecting logos. Our intention is for you to discuss if it could be of use for the community and then, if consensus is reached, to integrate the tool in UploadWizard, in a way that would be beneficial for moderation workflow. If you're interested in the topic, please have your say! Sannita (WMF) (talk) 10:20, 9 April 2024 (UTC)

If integrated into the MediaWiki Upload Wizard, how would it work? Would it prevent the uploading of a PD-textlogo or would it detect if an incompatible license or attribution is present? Or would it simply add them to a daily page for community evaluation, akin to "User:Minorax/PD textlogo/2020 June 6"? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:00, 9 April 2024 (UTC) My bad, I replied in the wrong village pump. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:00, 9 April 2024 (UTC)

Deprecate PD reviewers

Hello, this is a long overdue request to deprecate Commons:PD files/reviewers and Commons:PD files. This procedure has received little attention in the last 10 years compared to license reviewers. It's time to deprecate and move all files in Category:PD files for review to Category:License review needed. —Matrix(!) {user - talk? - contributions} 16:00, 2 April 2024 (UTC)

  •  Support The purpose of license review is to record that a trusted user has examined the licensing of a copyrighted file and determined that it has a valid free license as of the date of the review, so that in the future, if that evidence were to disappear, we could continue to retain the file relying solely on the word of the trusted user. On the other hand, PD status is determined primarily by review of evidence that is widely available, so recording the opinion of one trusted user that a file is PD on the file description seems a bit too much to me; their opinion has no more weight than a "keep" !vote at DR. -- King of ♥ ♦ ♣ ♠ 18:16, 2 April 2024 (UTC)
 Support, both PD/review and LicenseReview are nearly similar to each other, conducting reviews of the licensing. Tags like {{PD-old-expired}} are still considered as license tags. Two categories must he merged into one. JWilz12345 (Talk|Contrib's.) 18:52, 2 April 2024 (UTC)
 Oppose "move all files in Category:PD files for review to Category:License review needed". RZuo (talk) 07:35, 4 April 2024 (UTC)
Can we ask why? - Chris.sherlock2 (talk) 04:24, 6 April 2024 (UTC)
Category:PD files for review is already a subcategory of Category:License review needed. Moving files from one category to the other would generate a lot of unnecessary edit "noise"; we're probably better off focusing on reviewing the files instead of shuffling them around. Omphalographer (talk) 04:45, 6 April 2024 (UTC)
HotCat makes it particularly easy, though. --SHB2000 (talk) 07:59, 6 April 2024 (UTC)
There are already many subcategories of Category:License review needed. What's wrong with this one? The files in there are already in License review needed by virtue of being a subcat. Carl Lindberg (talk) 20:25, 6 April 2024 (UTC)
 Support. Both processes rely on the image-reviewer group, and perform very similar tasks; treating PD review as a type of license review seems like the logical solution. Omphalographer (talk) 04:43, 6 April 2024 (UTC)
 Neutral Commons:PD files should stay. That is a help page. The review section could change, though many of the tags could still be used. I can see merging the reviewers lists as it's pretty much the same need and many of the same people/copyright knowledge needed. One review process is fine, though the PD stuff can just be subcats of files needing review, such as there are already many breakdowns in subcategories as it is. I would keep the review templates, maybe just to subcategorize, but just mention them on the main license review page as options. Category:PD files for review is already a subcat so I don't see any reason to do anything with that. But I could see merging the review process pages, and the reviewer lists themselves. Carl Lindberg (talk) 22:38, 6 April 2024 (UTC)

Implementation

Hello, after this discussion and consensus I deprecated Commons:PD files/reviewers and Commons talk:PD files/reviewers. I also deprecated {{PDr}} and {{PDreview}} for any future uses. However due to opposition, I didn't touch any files in Category:PD files for review, instead I just recommended reviewers use {{subst:lrw}}. Are there any suggestions for any better implementations? —Matrix(!) {user - talk? - uselesscontributions} 20:36, 14 April 2024 (UTC)

Introduction of a new role

(This proposal is an improved version of this proposal where the issues suggested by users are addressed)

In this proposal, instead of bifurcating the role of sysop, I suggest introducing a new role known as "deletion administrators" where this group of users would be able to delete and undelete media (along with roles like renaming files, sending a message to multiple users at once, deleting and undeleting specific log entries and revisions of pages, merging the history of pages, and using higher limits in API queries). This proposal addresses two key problems highlighted by users in the previous proposal; first, the concern over the "presence of a common administrator," as blocking users and performing deletions naturally coincide when dealing with abuse. With deletion administrators, administrators would still be available to address vandalism promptly. Second, the issue of "productivity" is mitigated as users who are less familiar with tasks such as blocking and unblocking users, or adding user groups, can focus on resolving the COM:DR backlog.

In the prior proposal, Rodhullandemu noted that "Admins are expected to be conversant with all policies, but most will take on work most suitable to their interests and talents. So there's no need to have separation because we already have it on an informal basis." While this observation recognizes that admins naturally gravitate toward tasks they excel at, it also highlights the potential for backlog accumulation. This "informal basis" separation, therefore, does not sufficiently address Commons' operational needs. By formalizing the role of deletion administrators, we establish a clearer division of labor and ensure that tasks are handled efficiently, ultimately reducing backlog and enhancing overall effectiveness.

The criteria for this role would mirror those of interface administrators, with the distinction that administrators can assume the role of deletion administrator, or it would be oppposing the whole point of the proposal. Thanks, Contributers2020Talk to me here! 09:09, 17 April 2024 (UTC)

The role of an Admin light with the permission to delete or undelete files is not possible because of the reasons already discussed in the past. But I also had the idea of a new user right with the possibility to delete and undelete galleries and categories as this often not critical and does not cause copyright problems. GPSLeo (talk) 12:10, 17 April 2024 (UTC)
If you feel fit for handeling deletions and plan to focus mainly on that, I think you should apply for adminship even if you don't want to to more. I doubt the rest would make much of a difference for support/oppose.
Interface adminship is generally considered more risky. Enhancing999 (talk) 15:06, 17 April 2024 (UTC)
Would it really be acceptable to the community if admin candidates run solely on the basis of deletions, and pinky-swear that they won't be involved in blocking and other abuse-prevention activities that require such privilege? I'm not informed on the impossibility of this proposal as @GPSLeo hasn't linked to the prior discussions.
I don't have enough visibility into the admins' cabal to see how they coordinate stuff, but it seems rather anarchic in terms of volunteering in specific interest areas, so there is no managed distribution of duties or labor. Small wikis as well as Commons really suffer from a lack of volunteers overall, and it would seem that the bar for entry to adminship is a huge hurdle for people who wish only to specialise, so we do have clerks, non-admin closures, and other unprivileged gnomes who pick up the slack.
In Unix, the sudo and doas interfaces, and fine-grained IAM roles in cloud services such as AWS, permit a granular division of permissions, because in the Bad Old Days they just handed over the root password/Administrator account to any salesman who needed to install software. Commons has a unique status among all the Wikimedia projects, and we often find that the MediaWiki software structure is inadequate to support our specialised operations. So the issues are both technical and social. I'm saddened that this proposal is not possible to implement as described. Elizium23 (talk) 15:56, 17 April 2024 (UTC)
Deletions on Commons can have a fairly high impact, so this shouldn't be done lightly or as an experiment. Enhancing999 (talk) 16:01, 17 April 2024 (UTC)
Enhancing999, I'd like to emphasize that in addition to proficiency in copyright matters, candidates applying for adminship undergo evaluation of their ability to effectively handle vandalism, discerning what qualifies as such and what doesn't. Adminship entails a significant qualification hurdle, and therefore reducing the number of people that can qualify for this priviledge. Given the immense backlog of deletion requests we're currently facing, it's imperative that we address this issue promptly to prevent reaching a critical threshold. I firmly believe that the proposal at hand represents our best opportunity to do so. The current workload on administrators exceeds expectations, underscoring the pressure they're under. Also, I am not suggesting that this role would be given to anybody, but the people who are deemed qualified by the community to handle the deletion part. Contributers2020Talk to me here! 16:13, 17 April 2024 (UTC)
I think anybody who understands deletion requests knows what vandalism is. Enhancing999 (talk) 16:15, 17 April 2024 (UTC)
Deletion issues are quite distinct from vandalism itself, which is a narrowly-defined subset of disruption. Enwiki has extensive documentation on this particular topic. We on Commons, being separate and unique from other projects, interpret "vandalism" and "disruption" with yet different nuances. Administrators deal with disruption enough to know, from experience, what type they're seeing, usually, but not always. It's perilous for a non-administrator to unilaterally declare disruption or vandalism, without training, experience or insight; accusations are flung around quite often at the boards.
Deletions and deletion reviews, like LTA and complex disruption cases, require community input and consensus, and that's a parallel issue: not only is there a lack of admins to push the mop around, but a lack of knowledgeable participants in deletion discussions to efficiently arrive at a decisive consensus. Admins participate so much in those discussions, that perhaps they should not waste their time until non-admin volunteers have weighed in and reached a decision!
Perhaps a unique role such as Copyright Czar would be appropriate here: drawn from the ranks of admins and others who are experienced with copyright issues, disruptions, and deletions, they could provide a continuum of expertise and labor. But as before, the bigger picture is an overall lack of volunteers and a lack of community interest/participation/person-hours for these tasks. So many Commons editors are really only interested in contributing or organizing content, because that's our mission, the project has a vanishingly small slice of the admin labor pie. Elizium23 (talk) 19:12, 17 April 2024 (UTC)
I think you and me we both came across nil vandalism in the last six months. Likely because it's not much of an issue on Commons.
It's new to me that we seek consensus in deletion discussions. Are you sure that you didn't want to post on enwiki? Enhancing999 (talk) 19:18, 17 April 2024 (UTC)
I don't think that this is a good idea, for a couple of reasons:
  • Deletion on Commons is the "hardest" admin-only task, in my opinion. It requires thorough knowledge of Commons policy, and of international and US copyright law. It's not rocket science, but it isn't a task that should be given to people we don't trust enough to make full administrators.
  • Relatedly: which people should have this role, but shouldn't be full administrators? (This is rhetorical: I'm not looking for names. But I can't think of a contributor who can be trusted with the deletion button but not the block button.)
  • Deleting and blocking often come together. Not always, but often enough that it's useful to have both tools in the toolbox.
  • I'm confused about your comment about productivity. Admins who don't want to block or add user groups, but do want to delete, are totally free do so.
Best, —‍Mdaniels5757 (talk • contribs) 19:35, 17 April 2024 (UTC)
Yeah, as Mdaniels says, deletion is not a tool that we would want to give access to that we wouldn't trust with the other admin tools. I can think of at least one user that I'd trust more with the deletion tool than with the ability to block but that would be an edge case (No, I'm not naming names). Basically, there is no guideline that says an administrator has to use all of the tools available to them. I hardly ever use the tool to block (I've only used it once to prevent vandalism by an IP user). I can also agree that having both deletion and blocking can be very useful as deletion can be used for revision deletion (to deal with spam or inflammatory comments or the inappropriate disclosure of personal info). Abzeronow (talk) 03:37, 19 April 2024 (UTC)
 Oppose I would support a category-namespace specific right as proposed above by GPSLeo, because that's a highly specialized area that's also badly backlogged, but at the same time, anyone that we'd trust to handle it would probably make a perfectly fine admin. The bar on this project is very low, at least compared to enWiki. The Squirrel Conspiracy (talk) 05:30, 19 April 2024 (UTC)
 Oppose Per others. Although I'd support GPSLeo's idea. I can think of at least a few people who could probably have a category-namespace specific right but aren't quite admin material for whatever reason. It could also be a good hedge in to having more administrator rights. --Adamant1 (talk) 05:46, 19 April 2024 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2024/04&oldid=880121892"