User:Alexis Jazz/Proposal incubator

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Notice WIP for a proposal incubator. This is not in use atm.
View the proposals below. Requests for adminship: Requests for license reviewer:
  • Roy17
  • Was already promoted
  • This is just filler
 Projects that need your help: Ex-proposals:

Welcome to the proposal incubator!

You got a good idea! Well, kind of. Maybe it's a diamond in the rough. Maybe you want some feedback first. Maybe you don't know if it's worth to propose it at all. Put it up here and see what others think! Other users are encouraged to provide feedback and suggest how a proposal could be improved. When at least two users indicate they would vote on your proposal, you are allowed to start it on Commons:Village pump/Proposals. Do not cast votes here, only indicate if you would cast a vote on a proposal.

Click here to start incubating!


Click here to start incubating ON THE PUBLIC VILLAGE PUMP! YOU WILL BE LEAVING MY USER SPACE.


Click here to create a proposal on Village pump/Proposals! YOU WILL BE LEAVING MY USER SPACE.

Suggestions for a good proposal: (this will be the edit notice. edit notice does not work here)

  • Make it clear who or what is affected by the proposal.
  • Provide some background info for those who are not familiar with the subject.
  • Write the actual proposal in one or two sentences. This is what will be voted on.
  • If your proposal has more options than simply support and oppose, make it clear how it should be voted on. A subheader for each option may be a good idea.
  • ..

Free candy for everyone

[edit]

Everyone loves candy. If we provide it free of charge, there will be less drama. Also more reasons and information, background, maybe a link to candy for those who are not familiar with wait have you been living under a rock or something? I bet you have. You like rocks don't you. Just like Patrick. You know who I'm talking about. Patrick likes candy. Vote yes on candy! - Alexis Jazz ping plz 10:11, 22 January 2019 (UTC)

Free candy for everyone: votes

[edit]

Candy should be provided free of charge to regular Commons contributors. Candy will be delivered every Wednesday.

Free candy for everyone: discussion

[edit]

Discuss details for this proposal here.

Admin vacation

[edit]
YOU GET A VACATION! AND YOU GET A VACATION! EVERYBODY GETS A VACATION!

We take the top 52 admins from [1] on.. First of December or whatever, and sort them by userID.

  • In week 1 and 2 of the new year, we desysop the lowest and highest userID (1 and 52) from this list for two weeks.
  • In week 3 and 4 we desysop the second lowest and second highest userID (2 and 51) of this list for two weeks.
  • In week 5 and 6 we desysop the third lowest and third highest userID (3 and 50) of this list for two weeks.
  • ..
  • In week 51 and 52 we desysop the twenty-sixth lowest and highest userID (26 and 27) of this list for two weeks.

This odd rule ensures we're not sending two veterans on vacation at the same time.

If they start suffering withdrawal symptoms, we'll have to consider #Free candy for everyone again. - Alexis Jazz ping plz 00:05, 11 October 2019 (UTC)

Admin vacation: votes

[edit]

Admin vacation: discussion

[edit]

Seriously, some people work themselves into the ground. - Alexis Jazz ping plz 02:08, 11 October 2019 (UTC)

Not sure if this is a serious discussion or not, but a very simple way to take pressure from admins would be by giving more users "admin-like" powers permissions, and while the general maintainers proposal had no consensus for implementation, there are plenty of other user rights that could be derived from sysops, in fact, other than deleting pages and blocking users/people all other admin permissions could made into separate user groups. Of course, admins themselves don't have the same permissions as users "higher" than them such as Oversighters, Checkusers, and Bureaucrats, so splitting user groups up based on what a user needs would be wise, this has already been happening for the past decade and a half on Wikimedia websites, and if we could accelerate it it would only be better.

Of course what user gets to be what shouldn't be decided on an admin's whim, so more "consensus-based rights" should be created in the process, basically "General Maintainers 2: Electric Boogaloo" but split into a dozen user groups. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 18:52, 24 November 2019 (UTC)

 Some clarification, while I think that admins should be able to take vacations, it should be there own choice. We're all volunteers and mandatory vacations from something you like to do can be counter-productive, but it's not as if mandatory vacations don't currently exist. Many admins are simply overworked because they don't have that much help in their fields of expertise and we wouldn't need "a Jcb" if dozens of admins helped clear those backlogs which also meant that each individual admin could spend more time per deletion thus increasing the quality of deletions on Wikimedia Commons. Having more users with more rights will help solve many other admin backlogs, but these new user rights will have to be practically designed and not too broad, this way users can help with specific backlogs they already have experience in as opposed to apply for user rights or "buttons" they don't even need and/or want to have. Though this will probably attract some hat collectors. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 18:57, 24 November 2019 (UTC)

Governance changes

[edit]
New version based on discussion input by @GreenMeansGo and 4nn1l2:
Starting a re-RFA

When an administrator (action) is being discussed, four genuine (that is, no socks) users (including administrators) can make the administrator go through the re-RFA process. When the re-RFA is successfully requested, these four users will permanently lose the ability to request a re-RFA for this administrator. These four users should state in their request that they have read and understand this policy.

Re-RFA

The administrator will be given two weeks to start a re-RFA and should refrain from controversial administrative actions while they prepare their re-RFA. If they need more time, they will be expected to cease using their tools during that period. The re-RFA will succeed (the administrator is kept) with 2/3 or 66.67% support. (like the German Wikipedia)

Obvious (tool) abuse and/or socking

Obvious abuse should be handled no different from the way abuse by non-admins is handled, except that when an administrator is blocked or desysopped there should always be a discussion or notice on AN/U and (as with non-admins) controversial blocks and desysops should be reversed. Compare for example how rollbacker and filemover rights can be taken away from users if they misuse those tools.


Governance changes: discussion

[edit]

No, I strongly oppose this idea. I do not want Commons to gravitate toward a landed aristocracy model of the English Wikipedia, where effectively only admins can be elected to Arbcom and therefore only admins can decide on the conduct of other admins. This is an en:Ancien Régime model, where the clergy and nobles decide how the taxes are levied on the Third Estate. Admins should serve on the commission of and at the behest of the community at large. When they cease to do so, then they should return to the Third Estate until there is sufficient confidence that they can do so again. GMGtalk 01:02, 11 October 2019 (UTC)

  • @GreenMeansGo: That's what the last bulletpoint is supposed to address. But I haven't worked out yet exactly on what conditions users can force an admin into re-RFA. - Alexis Jazz ping plz 01:22, 11 October 2019 (UTC)
Honestly, of all the things we have on Commons, I really think our current deadmin procedures are in a very good place, and should be a model for other projects to follow. The only problem with it thus far has been the framing. Take the last dual proposal. A non-partisan (myself in that case) should suggest the formal consensus discussion. That discussion itself should be non-partisan and only a referendum on whether a formal discussion is appropriate. In general, the person who proposes the consensus discussion should not take part in the deadmin discussion itself. So long as we frame it that way, I think it works well. If a partisan starts the discussion, then it doesn't, but that's kindof a feature and not really a bug. GMGtalk 02:11, 11 October 2019 (UTC)
Why we don't have a ArbCom? Masum Reza📞 02:14, 11 October 2019 (UTC)
Because projects (excluding the English Wikipedia for accident of history) have to opt-into an ArbCom and we haven't. Most projects don't, and work through a process of consensus mixed with direct democracy. GMGtalk 02:18, 11 October 2019 (UTC)
@Masumrezarock100: ArbCom makes things more complicated.. It will disconnect users further from admins, I think. And generally, I don't think there is support for it here.
@GreenMeansGo: I'm not sure I fully understand. You know what really happened during the last dual proposal? Several of us threw Yann under the bus to finally get Jcb evaluated. And the elephant in the room: generally only people who want someone desysopped (or at least consider it) want to start a formal discussion. (desysop) Because if you don't want them to be desysopped, you've got nothing to gain. By needing "consensus" (which equates to more than 50%, at least 75% and often more) to start a de-adminship discussion that will succeed with 50%, we're having a redundant vote for a vote. - Alexis Jazz ping plz 02:29, 11 October 2019 (UTC)
Umm...Not quite. Consensus is not a vote. Crats can discount silly things in determining that. But you're also missing that the bar is lower for the consensus discussion than for the deamanship one. The consensus discussion need only determine that someone should stand for community review. It's perfectly fine if that community review retain them as an admin, but offer constructive feedback for their actions going forward. GMGtalk 02:39, 11 October 2019 (UTC)
@GreenMeansGo: well, in theory that's sensible.. In practice, most people who wish to keep an admin will oppose any community review/de-adminship discussion. And if 25% of people wish to keep an admin, you won't have consensus for a community review. You can give admins constructive feedback on their talk page, no need for a desysop discussion for that. If you want to keep an admin, you cant win in a de-adminship discussion. The best you can achieve is the status quo. So there is no incentive to support it unless you want an admin to be gone. - Alexis Jazz ping plz 03:56, 11 October 2019 (UTC)

Why so complicated? The last bullet is all we need. If 8 users want an admin to go through re-RFA, the admin should do so. You only need to make the following changes to the current policy.

  • de-adminship --> re-RFA
  • "some consensus" --> 8 users
  • "majority consensus" should be used, whereby any consensus to demote of higher than about 50% is sufficient to remove the admin. --> the threshould should be 2/3 or 66.67% [like the German Wikipedia].

4nn1l2 (talk) 09:51, 11 October 2019 (UTC)

@4nn1l2: I sometimes think too complicated.
The main reason I had described two different processes was because of obvious abuse. If an admin is caught socking or actively disrupting Commons, there has to be a way to stop them quickly. Though this is kind of common sense, perhaps that scenario should be covered by a single line.
One more issue. What if an admin has 8 permanent "enemies"? There has to be a limit to stop them from forcing the admin into re-RFA every month. - Alexis Jazz ping plz 14:49, 11 October 2019 (UTC)
The same set of users cannot force an admin into another re-RFA. This is gaming the same and prohibited. Any uninvolved admin can end such a game at sight. There are no hard and fast rules to determine whether a user is gaming the system or not, and the judgement should be used. However, I can think of some rule of thumbs such as this one: among those 8 "recallers", at least 4 "recallers" should not have previously asked admin X to go through re-RFA in the preceding 12 month. 4nn1l2 (talk) 16:40, 15 October 2019 (UTC)
@4nn1l2: Thanks for the input. I actually think the 12 month period isn't needed. Users come and go. As long as there is an influx of new users, new "recallers" can always be found. A 12 month period might even hurt. If there are 8 users who want an admin to go, they could force a re-RFA every 6 months. I thought about it some more, and the 4/8 split is a bit complicated/confusing. And ultimately, probably not even needed. I think permanently giving up your ability to force an admin into re-RFA will be enough of a deterrent for frivolous requests. If there are four users who are willing to exercise that one-time right, there will always be another 4 who'd be happy to support the request without consequences for them. So I'm eliminating the need for those four. Ultimately this may be a matter of trial and error anyway. - Alexis Jazz ping plz 18:59, 15 October 2019 (UTC)
  • Just personal ramblings, but I argued this extensively on en.wiki, but I don't think any "hard-cap" system is workable. That is that eight or twelve or twenty or whatever users must agree. Even if it works now, if our projects continue to grow, then it won't work later. This is the system I believe that es.wiki uses, but es.wiki has outgrown their numerical cap and so they are open to gaming. Context dependent consensus is the only real workable solution to starting a re-RfA. It is the only sustainable solution. GMGtalk 23:38, 1 December 2019 (UTC)
@GreenMeansGo: I agree the cap should be raised (or lowered) as a project gets bigger or smaller. How could context dependent consensus be implemented? I can't really think of any way beyond "hand it over to the bureaucrats" and/or voting to have a vote, and that didn't serve us too well imho. - Alexis Jazz ping plz 01:03, 2 December 2019 (UTC)
In practice, context dependent consensus is what Commons currently has. But hard-cap/dynamic-system approaches are always bad. They're always premised on the idea that it will be updated later but they rarely are. In the context of the United States, it would make much more sense to have a minimum wage pegged to inflation, so that you don't need to have a vote every couple of years about the minimum wage. But we don't do that, and it rarely gets updated. The same goes for other things, but that's probably getting too far out out in the weeds.
Moral of the story is, don't design a system based on the assumption that it will be regularly updated later. GMGtalk 01:12, 2 December 2019 (UTC)
@GreenMeansGo: The system we currently have doesn't allow starting a desysop request unless we've already determined the outcome will be to remove. In a healthy system, evaluation requests (be it desysop or re-RFA) will occur and sometimes succeed and sometimes fail. If they mostly fail, they are too easy to start. If they mostly succeed, they are too difficult to start. While I agree a relative cap is generally better, I don't see anything we could realistically use. And because the four who initiate the re-RFA are permanently removed from the equation, it actually is pegged to something: how many enemies can a single admin make? If the Commons userbase doubles, the number of admins should also increase. It won't scale perfectly, but it should scale to some degree. I don't know exactly what system eswiki uses, but do they limit how often a single user can support starting a desysop? - Alexis Jazz ping plz 01:45, 2 December 2019 (UTC)

Restructuring deletion requests

[edit]

WIP. The current "no permission", "no source", "DW no source", "no license" and "copyvio" tags are largely useless.

No, seriously. An image of Donald Duck could be tagged with "no permission", "no source" (if it doesn't have a realistic source), "DW no source" (if it's photograph of a comic book), "no license" (because why would you tag Donald with any license anyway?) or "copyvio". (because d'oh) It's irrelevant. It's Donald Duck and Donald Duck ain't free.

It would be more useful to get rid of the speedy tags (no source/no license/copyvio/etc) and categorize DRs in a sensible manner, directly from QuickDelete.

This is where it gets muddy as I haven't worked out much details yet.

The nominator could pick a category, select a country of origin, enter the name of the copyright holder, the death date of the author (in case of US works this should be the publication date) and a source for the file that predates the Commons upload. Only the category would be mandatory. And obviously they can still enter a reason in their own words to that.

Some ideas for categories:

Extended content
  • "Obvious copyright violation" (say, Donald Duck) If a copyright holder and/or death date and/or predating source has been entered, this could be treated like a speedy.
  • "Suspected copyright violation" Not speedy.
  • "My work was uploaded without my permission" This is useful because professional photographers will report illegitimate use of their work with a DR sometimes. And they will often do so as an IP user. These DRs often require someone to attempt contacting the photographer, or research to find the actual source. Some people may be willing to do that (including myself), but those DRs are generally lost in a sea of rubbish.
  • "2D FoP issue" Very common, if the source country was indicated this could be dealt with as a speedy.
  • "3D FoP issue" Very common, if the source country was indicated this could be dealt with as a speedy.
  • "Abuse" Files uploaded for no reason but to disrupt the project. Can generally be speedied.
  • "Privacy concerns" Generally requires communication with the nominator and/or a photoshopper.
  • "File needs to be altered or fixed" Combined with the file extension, this can result in some useful maintenance categories. (like broken SVG files) The file must be cropped, partially blurred or some other modification is needed. The file can be fixed. I'm willing to work on those things, but can't filter them out of the sea of DRs.
  • "Out of scope"

I'm likely forgetting stuff. Ideally the user first picks one thing and picks the more precise thing after that. So you select FoP first and 2D/3D/author/etc after that. Or you select "Files needs to be altered" and get choices of "remove/blur unfree element from file", "remove/blur element for privacy reasons", "defective file" or automatically select "broken svg" based on the file extension.

  • "Copyright problem"
    • "Obvious copyright violation" (CoO, CH, year, PS, checkbox "is a logo")
    • "Suspected copyright violation" (CoO, CH, year, PS, checkbox "is a logo")
    • "My work was uploaded without my permission" (CH, PS)
    • "2D FoP issue" (CoO, CH, year, PS)
    • "3D FoP issue" (CoO, CH, year, PS)
    • "Element should be removed/blurred for copyright reasons"
  • "Abuse" (warn the user about oversightable material)
    • "Vandalism"
    • "Intentional privacy violation"
    • "Service abuse"
    • "Material is not lawful for Commons to host on its servers in Virginia"
  • "Out of scope"
    • "Selfie" (warn user that the "element" option is also available if the file is salvageable)
    • "Personal photo" (warn user that the "element" option is also available if the file is salvageable)
    • "Element (including people) should be removed/blurred for scope reasons"
    • "Advertising for non-notable entities" (BUY BITCOINS GET RICH WHILE SUPPLIES LAST, checkbox "Spam")
  • "File needs to be altered"
    • "Element should be removed/blurred for copyright reasons"
    • "Element (including people) should be removed/blurred for privacy reasons"
    • "Defective file"
    • Automatically select "broken svg" based on the file extension.

CoO = Country of Origin, CH = Copyright Holder, PS = Predating Source

In addition, those four would all need the option "Other". - Alexis Jazz ping plz 08:58, 24 November 2019 (UTC)

Restructuring deletion requests: discussion

[edit]

Lots of stuff to iron out here. @GreenMeansGo and Donald Trung: any input is welcome, I can't oversee all this by myself. - Alexis Jazz ping plz 09:15, 24 November 2019 (UTC)

Funny that you pinged me, if my baby didn't cry earlier I would have posted some feedback and questions. I am still quite busy so I will keep this brief. But in this system will deletion requests be separated into whole categories of deletion requests? Like "Commons:Deletion Requests/DATE/No permission/FILE_NAME"? This would also allow sysops to specialise and delete some copyright violations sooner while getting some human eyes on files in the public domain that were mistakenly tagged as copyright violations. More feedback later. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:44, 24 November 2019 (UTC)
@Donald Trung: yes, but not like that. The page title would be the same (like Commons:Deletion requests/File:Example.jpg) but the DR page and file would be categorized. For example Category:FOP-related deletion requests would be far more populated. Categories with dates could be created as well. Undeletion categories could be set if enough information was provided. The overview pages with many DRs transcluded would also still exist, but there would be more of such pages for the various categories. Depending on the input, files could also be added to Category:Copyright violations for speedy deletion. - Alexis Jazz ping plz 09:53, 24 November 2019 (UTC)
I think what you need is to find someone behind the Twinkle gadget on en.wiki. GMGtalk 12:33, 24 November 2019 (UTC)
Yes, these categories will greatly help people to specialise in deletion request types. Also new categories could be created for certain types of missing permissions, such as files with pending OTRS tickets could be automatically nominated for deletion 7 (seven) days before the deadline is up and OTRS agents could close these requests if the ticket has been accepted. I honestly think that we need more deletion requests, but categorised in an orderly fashion. Deletion requests allow community input while automated deletion tags don't, I remember a public domain image being deleted that was originally uploaded to the English-language Wikipedia after it was bot imported to Wikimedia Commons, Slowking4 told me privately that thousands of such files were tagged and deleted without human eyes ever verifying if those files were in fact copyrighted. Having better categorised deletion requests, including for porn, freedom of panorama, videos, Etc., will greatly benefit copyright experts to help them find files in which their expertise might be needed. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 18:41, 24 November 2019 (UTC)

Crats and admins 1: Allow admins to assign various group permissions

[edit]

This is a series of suggestions that aim to copy some rights from COM:Bureaucrats to COM:Admins and for a limited set Stewards.

This is probably not very controversial: allow admins to grant and revoke group permissions that don't include undelete like Bot, GWToolset (no longer maintained according to that page?), Translation admin and account creator. (which is a bit of misnomer, it's just noratelimit) - Alexis Jazz ping plz 11:06, 29 February 2020 (UTC)

Crats and admins 2: allow admins to close RFAs and determine the validity of deRFAs

[edit]

This is a series of suggestions that aim to copy some rights from COM:Bureaucrats to COM:Admins and for a limited set Stewards.

This one might be slightly more controversial, but probably not too much. It already happens sometimes and in such cases all we do is wait for a bureaucrat to confirm. In general, an admin can close these discussions just as well. In the event of controversy, the controversy should be resolved on a case-by-case basis which might mean extending the voting period or having more admins endorse the outcome. This depends on why the outcome is deemed controversial. This isn't a very common occurence (most votes have a sufficiently clear outcome) and if a crat ever were to veto in such a case, it would probably turn Commons into a warzone. So we might as well just let admins close these. To actually get the permission(s) assigned they would need to make a request with a steward.

Another thing bureaucrats do is determine if a request for de-adminship is valid and close inadmissible requests early. This could also be done by admins. - Alexis Jazz ping plz 11:13, 29 February 2020 (UTC)

Crats and admins 3: allow admins to remove admin permissions

[edit]

This is a series of suggestions that aim to copy some rights from COM:Bureaucrats to COM:Admins and for a limited set Stewards.

This one would likely lead to more discussion: allow admins not only to close desysop requests but also to actually remove the admin bit instead of a requesting a steward to do that. This may have security implications, both ways actually. If an admin goes rogue, they could desysop other admins. On the other hand, if an admin goes rogue, any other admin could perform an emergency desysop and we wouldn't have to wait for a steward or bureaucrat.

Personally I wouldn't mind giving admins this ability provided it won't negatively affect security. - Alexis Jazz ping plz 11:18, 29 February 2020 (UTC)

HAH! Local bureaucrats don't even have this power! The most controversial part of the discussion has already been resolved! - Alexis Jazz ping plz 11:29, 29 February 2020 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=User:Alexis_Jazz/Proposal_incubator&oldid=400055907"