User:Alexis Jazz/Proposal incubator/Scrapped

Currently open proposals: Free candy for everyone Admin vacation Governance changes Restructuring deletion requests

Requests for adminship: Ijon Elisfkc Gbawden

Requests for license reviewer: Roy17 Was already promoted This is just filler

Projects that need your help: Photography workshop This is just an example

Ex-proposals: Proposals that left the incubator Proposals that left the incubator in pieces

Allow voters to amend their vote after 3 months

Sometimes, after electing a candidate, the community may have second thoughts after a while. To prevent instant drama, this proposal protects new administrators during their first three months in the line of duty. After these three months have passed, voters will be allowed to amend their vote in the RfA, switching freely between support, neutral and oppose. If switched votes result in support dropping under 65% with a duration of dropped support of at least one week, a de-adminship request may be started. If the de-adminship request fails with less than 25% support for de-admin and at least 8 "oppose" votes, the de-adminship request will become the new mandate (and for all intents and purposes their RfA) for the admin. The original RfA will be null and void in favour of the de-adminship request. If the de-adminship fails with more than 25% support, the community needs to wait for 3 months. If after this time the support on the RfA is still below 65%, the administrator needs to file a new RfA. If that RfA does not pass, the administrator is considered to no longer have a community mandate and shall no longer be admin. - Alexis Jazz ^{ping plz} 14:05, 28 January 2019 (UTC)

Allow voters to amend their vote after 3 months: discussion

Discuss details for this proposal here.

• This is too complicated and has practically zero chance of being approved by the community. 4nn1l2 (talk) 21:17, 28 January 2019 (UTC)

Probably true. It would have to be simplified somehow to even stand a chance. The five-year term (which I wrote because after some time most of the original voters may have left Commons) could actually be dropped by simply allowing users to keep voting on an RfA after it ends. Just keep accumulating votes. But your idea below may be better. - Alexis Jazz ^{ping plz} 05:22, 29 January 2019 (UTC)

• As much as I like this proposal I don't see how users would interpret this as "change your  Support into an  Oppose" and probably has a 0% (zero percent) chance of actually being adopted, re-evaluating admins after 3 (three) months for a general discussion of their conduct is a good idea, but in the current environment with the current system it would never be accepted. The admin rights should be divided into more speclialised groups (though I'm not advocating adopting "Commons:Blockers"), as of now one class of users has all the rights and all other users have only whatever they are permitted by this group. I remember there being a discussion about splitting sysop rights on the Dutch-language Wikipedia but while a handful of features were handed down the status of sysops never changed, probably splitting "interface-admins" from "admins" last year is the largest loss of power they've ever had. It would probably be better if users had rights for what they need rather than such a binary sysop and non-sysop division. But as long as the divides are this big a re-evaluation is probably out of the question. A council to evaluate admins would also be a bad idea as that could devolve into "an ideological purity chamber" (knowing Wikimedians, a Deletionist and exclusionist echo chamber), it would probably be best to first introduce the five (5) year re-admin discussions. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:36, 31 January 2019 (UTC)

Community mandates to give users additional rights need to be renewed every five years

Our expectations change over time. Someone who was deemed to have excellent knowledge of copyright ten years ago may no longer be considered an expert if they didn't stay up to date. The community itself also changes over time. People come and go. The community that accepted someone ten years ago may not be the community that is here today. To ensure users with additional rights have a continued community mandate, they should renew their mandate at least every five years. The user in question should first be notified on their talk page when their current mandate is more than five years old. Only after the user in question performs one edit (this will be considered a confirmation the notification was read, so if the user is on holiday or otherwise not available they don't need to worry), a timer will start. The user will be given one month to start a new RfA, request for license reviewer or equivalent process and the request will be allowed to run its course while the user retains their additional rights. The additional rights will be removed if:

• The request fails.
• The user makes an edit after having been notified about their expired mandate, but fails to start an RfA within one month.

To allow a smooth transition, there should be no more than five open renewal requests at the same time. Users who are waiting for a slot to file their RfA will not be stripped of their rights for exceeding their one month. Reasonable and sufficient leeway must be provided in these cases. Bots are specifically excluded from this proposal, as they are already governed by different processes and not subject to a typical community vote for acceptance. - Alexis Jazz ^{ping plz} 14:31, 28 January 2019 (UTC)

Community mandates to give users additional rights need to be renewed every five years: votes

When a user is bestowed additional rights per community vote, like (but not limited to) administrators and license reviewers, this mandate needs to be renewed every five years according to the guidelines laid out above.

Community mandates to give users additional rights need to be renewed every five years: discussion

Discuss details for this proposal here.

• Pinging @Donald Trung, GreenMeansGo, 4nn1l2 this and the one above. What do you think? - Alexis Jazz ^{ping plz} 14:37, 28 January 2019 (UTC)
• I really like these proposed policy additions, although I can imagine that a lot of users with "advanced user rights" will not be in favour of these changes and even if they were implemented will campaign against them, see "w:nl:Wikipedia:Stemlokaal/Afschaffen herbevestigingsprocedure" as an example of such a policy being abolished. Although as you propose half a decade for renewals I actually think that there might be less resistance from those who might have a vested interest in maintaining the status quo. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 18:35, 28 January 2019 (UTC)
• I don't like the first proposal at all. The second proposal seems more reasonable, but it will not be accepted because 1) inactive users will come out of the woodwork and oppose it; and 2) admins are already subject to inactivity checks. I think we should come up with another proposal which 1) focuses on a vote of confidence, rather than RfDA (Request for De-Adminship) ; and 2) has a good chance of being approved by the community. I don't think our current procedure is sensible. My proposal has two phases:
  1. A pre-vote discussion, which lasts for one week exactly, and succeeds if not vetoed by bureaucrats. Users can freely express their opinion or vote during this phase, but they should note that the actual vote occurs during the second phase. This phase is just to weed out malicious proposals.
  2. A vote of confidence (or a 2nd RfA) which has a threshold of 2/3 rather than 75%.
• 4nn1l2 (talk) 18:58, 28 January 2019 (UTC)

  @4nn1l2: I would be interested to see that idea further developed. - Alexis Jazz ^{ping plz} 19:38, 28 January 2019 (UTC)

  I may post it to Commons talk:Administrators/De-adminship after the current discussion at AN/U. 4nn1l2 (talk) 21:11, 28 January 2019 (UTC)

• I've been rolling around the idea of a five year term limit for a while now, although mostly off-Commons. If you're gonna do it, it has to be before you reach the mass of something like en.wiki, or else it just becomes logistically prohibitive. The process on Commons is still better than the process on en.wiki, i.e., "spend 50k words of argument over two months at ArbCom, a body themselves made up of appointed-for-life admins". The process on en.quote is more similar to Commons, but anyone can open a deadminship discussion outright. Hard to tell if that works at all given such a small community, or if it does, whether it would work on any larger community like Commons.

As a general rule, I support any modification on any project that makes adminship easier to take away, and by proxy, lowering the risk of giving it out, as well as holding the corps to a higher behavioral standard. I think we would all be better off it we let most experienced user's give it a shot with the benefit of the doubt, knowing that we can easily take it away if abused. I do think most people would do just fine at it, and it would overall help our backlogs, which at the end of the day, is the actual important thing, and not who is or who is not a part of a "class" of contributors. GMG^talk 22:14, 28 January 2019 (UTC)

Creation of a right to delete and revision-delete one's own files

For some users it's useful to be able to delete or revision delete their own files. In particular map creators. If they accidentally upload a map with incorrect information, it needs to be deleted and replaced with a correct map. Wrong maps shouldn't be left floating around. There already is a use case: Golbez. Golbez became an administrator for exactly this reason. Their administrator actions (all of them) that didn't apply to their own uploads can be counted on your digits. Some people can actually count them all on their fingers, but most can't. Simply making all map creators administrators is not an option for legal reasons.

Such a right would only be given on request to users who know what they are doing and have a valid use case for it. It would be applied for on Commons:Requests for rights. It should not be used to replace "deletion by uploader request", it should only be used to delete incorrect files, superseded files without any historical significance, broken files and files that (shortly after upload) the uploader themselves identified as copyvio. Any other cases should go through the usual procedures.

I don't know if this right is currently an option in MediaWiki, but a Phabricator ticket will be created for this if this proposal passes. - Alexis Jazz ^{ping plz} 15:29, 30 January 2019 (UTC)

Creation of a right to delete and revision-delete one's own files: votes

Create a user group for users who are allowed to delete and revision-delete their own files. The right could be applied for on Commons:Requests for rights.

Creation of a right to delete and revision-delete one's own files: discussion

Discuss details for this proposal here.

• I seriously doubt this would get widespread consensus. The obvious counterargument is that CSD is not nearly as backlogged as DR, and it will quickly be mopped up by an admin. If there happens to be an en.wiki user around, there have recently been a few "rage quits" from the project (to use video game parlance), where a user requested all their creations deleted under en:WP:G7, at times, hundreds of articles. The community wasn't so keen on it, and neither was I. That's likely to come up given the predominance of en.wiki users on the noticeboards here. GMG^talk 23:02, 30 January 2019 (UTC)

@GreenMeansGo: I hadn't thought of that. What if this right would require a community vote like an RfA? And perhaps restrict applications to map creators, as I think they are the primary use case. And maybe a rate limit, but I'm not sure what would be a sensible value in that case without hurting legitimate use. 1 action every 3 seconds maybe. - Alexis Jazz ^{ping plz} 08:42, 31 January 2019 (UTC)

Well, the perennial response would be that if you make a user right that is close enough to sysop, and you make a process that is close enough to an RfA, then most of the users who would qualify for the right would pass an RfA, and we'd be better off with more sysops rather than more pseudo-sysops. Maybe that doesn't go as far here as on other projects, since Commons already has at least two pseudo-RfA processes: Commons:License review/requests and Commons:Translation administrators. Only one of these is duplicated anywhere else as far as I'm aware, at d:Wikidata:Translation administrators. Everything else (CU, OS, Steward, Interface Admin) is generally a user right explicitly above sysop. GMG^talk 11:42, 31 January 2019 (UTC)

@GreenMeansGo: I actually disagree. Except perhaps for translation administrators, it's not entirely clear to me why that is a separate user group or why autopatrolled users can't do that. We have a load of inactive sysops (I'll drop a bombshell on that later..) that are a potential target for hackers as well as a legal liability to themselves and the WMF. We don't need hat collectors who are sysop in name only. License reviewers don't deal with blocks, DRs, vandalism or scope. They merely deal with licenses and are considered experts in that. In fact, sysops shouldn't automatically be license reviewers. While a sysop should also have a good understanding of copyright, it doesn't have to be the same high standard as that which is required for a license reviewer. I don't believe appointing more sysops is the solution for a shortage of sysops. (also, more asphalt does not solve traffic jams, actually true) We've had a shortage of sysops for years. In May of 2013, almost 6 years ago (!), something that I think was a horrible mistake happened in part because (and I quote) "We are chronically short of active Admins". The community can't trust a lot of people with all the responsiblities that adminship carries. Having some "one size fits all" admins is sensible on a small project where everyone knows each other. On a large project like Commons (or Wikipedia for that matter), it leads to drama. Or, if it doesn't lead to drama, it leads to dictatorship and suppression. No dramah in China! And Commons has a mix of the two. - Alexis Jazz ^{ping plz} 12:47, 31 January 2019 (UTC)

Incidentally, there is ongoing discussion on en.wiki at en:Wikipedia:Administrators/2019 request for comment on inactivity standards that may be of interest to you. GMG^talk 13:14, 4 February 2019 (UTC)

• I don't think that this is a good idea, oftentimes users upload useful content which then gets replaced by other content in Wikipedia articles, some users would want the "old versions" deleted despite being useful, allowing users to delete their own images could be "a quest for the newest" where older images of the same subject during a different era will be lost. You own the copyright to your own work for as long as you live plus between 50 (fifty) and 100 (a hundred) years depending on your jurisdiction, but that doesn't mean that when you don't want it anymore that you should be able to delete while others can still benefit from it. The difference between Wikimedia Commons and a web host is that a web host like Flickr allows you to delete your own stuff, even if it's public which is a bane for re-users, have a short window for second thoughts should be enough. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:21, 31 January 2019 (UTC)
• also, the moment you make an edit it's no longer your edit anymore, you may own the copyright © to it, but anyone can do with whatever they want which is why your edits here are donations. We need more content, not less. Imagine if Fæ would want all of the images he uploaded deleted? If Fæ would nuke himself it would be a disaster for almost every website (including other Wikimedia websites) that use his work. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:25, 31 January 2019 (UTC) Yeah, I misread the request. Not a bad idea but it should probably not be given lightly and shouldn't allow self-nuking. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:27, 31 January 2019 (UTC)

Update the wikitext licensing

By saving changes, you agree to the Terms of Use, and you irrevocably agree to release your contribution under the Creative Commons Attribution-ShareAlike 3.0 license and the GFDL. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.

On mobile:

By saving changes, you agree to the Terms of Use and agree to release your contribution under the CC BY-SA 3.0 and GFDL licenses.

We are all familiar with that text. And before you ask, yes, we are allowed to change it. Wikinews already did back in 2005.

There are two wikitext-specific issues (besides all the general issues) with GFDL here. We import many descriptions, from Flickr for example. While not every single description may be fully BY-SA compatible, they are virtually never GFDL. So our GFDL license already doesn't apply to a lot of our wikitext content. A more minor issue is that GFDL allows a third party to fork wikitext from Commons and improve it under only the GFDL, closing the door for Creative Commons. Add to this that GFDL in general just causes headaches and hasn't had any legitimate use case for almost a decade (when Wikimedia adopted Creative Commons) and we have all the reasons to stop licensing new wikitext contributions as GFDL.

And then there's the elephant in the room: why are we still using Creative Commons 3.0? No reason, really. It was the most recent thing in 2009. That's all. Compatibility is not the issue. Raystorm, a WMF Trustee, has voiced before the desire to move to Creative Commons 4.0. Let's lead the way once more. - Alexis Jazz ^{ping plz} 16:42, 12 February 2019 (UTC)

Update the wikitext licensing: votes

License new wikitext contributions on Commons as Creative Commons BY-SA 3.0 plus BY-SA 4.0, dropping GFDL for wikitext.

•  Support We don't need GFDL for wikitext. Updating to BY-SA 4.0 is also a good idea. Abzeronow (talk) 16:37, 15 February 2019 (UTC)

Update the wikitext licensing: discussion

Discuss details for this proposal here.

• I'm sure someone will wish to pick a bone with me.. - Alexis Jazz ^{ping plz} 16:42, 12 February 2019 (UTC)

This seems like common sense. I'd be even more radical and support going to CC-0 so Commons plays better with Wikidata, plus CC-0 seems more apt for something called the Commons. But yes, updating to 4.0 plus dropping GFDL is the least we can do Abzeronow (talk) 17:29, 12 February 2019 (UTC)

@Abzeronow: CC-0 would probably be sensible for many wikis, but we import many descriptions. Those are mostly at least one-way BY-SA compatible, like PD and BY. If we could somehow license descriptions different from wikitext in general, CC-0 may become an option. This doesn't seem like something that will happen in the near future though. Not saying I wouldn't support such a change, but I'm not sure how it would or could be implemented. - Alexis Jazz ^{ping plz} 18:10, 12 February 2019 (UTC)

I thought about it. This has to be done globally. If we move to 4.0, other wikis couldn't import our wikitext. If we dual-license 3.0 and 4.0, we couldn't import 3.0 wikitext from other wikis. - Alexis Jazz ^{ping plz} 23:00, 22 June 2019 (UTC)