Commons:Village pump/Proposals/Archive/2018/01

From Wikimedia Commons, the free media repository
Jump to: navigation, search
Archive This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Flickr batch uploading requests page

The Flickr batch requests are mostly ancient, and since Flickr2Commons was launched requests for batches smaller than 380 (three-hundred-and-eighty) images can be handled by the requesters themselves. In fact when I asked someone who made a request two ✌🏻 (2) years ago recently if they were willing to let me upload and organise some of their batches for them they said that they used Flickr2Commons to upload all their images themselves.

I suggest that we archive all old requests and make the page exclusively for batches larger than 380 images (as that’s the rate limit for non-administrators to upload files to Wikimedia Commons within a certain amount of time), the current page could be moved to Commons:Flickr batch uploading/Historic and have this message displayed on the top of the page:

{{historical}}

And be added to Category:Inactive Commons pages. A Flickr batch uploading page could still be useful, but it should only be used for larger batches that require administrator attention ⚠.

Sent from my Microsoft Lumia 950 XL with Microsoft Windows 10 Mobile 📱. --Donald Trung (Talk 💬) ("The Chinese Coin Troll" 👿) (Articles 📚) 11:12, 1 January 2018 (UTC)

No, thanks. Those requests might be from people no longer active on Commons, and contain useful images, which we won't otherwise get. In any case, can anyone - specifically, new or IP users - use Flickr2Commons? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:22, 3 January 2018 (UTC)
New users can use it unless there's a limit on Flickr2Commons side, and IP cannot use Flickr2Commons because OAuth authentication is not supported for IP users. — regards, Revi 15:31, 3 January 2018 (UTC)

Forking tool

I'd like to make a technical suggestion/request for a new tool for use on Commons and Wikipedia. It's often the case that an editor makes an alteration to an image and uploads it over the original, then another editor reverts this for whatever reason. If both the edited image was useful and the reverting was appropriate it's usually a good idea to upload the edited version as a separate file. The problems with this are; (1) the person who edited the image may not be aware of having been reverted, (2) the person doing the reverting can't be bothered, (3) the edited image needs to be downloaded before being re-uploaded, (4) the file description needs to be copy/pasted from the old file to the new file, and (5) a link to each file needs to be added to the other_versions field of the other file description. All of this takes a lot of time and effort, and the person uploading the new file may not realize that there are problems with the licensing or whatever, or neglect to complete steps (4) and (5). What I'd like to propose is a new tool alongside revert (in the left-hand column of the File history) that can be used to automatically fork content to a new file, making all the necessary checks and updates, and reporting any errors. nagualdesign 23:07, 17 January 2018 (UTC)

I see. Well in that case I'd like to propose allowing any signed-in user to perform 'splitting', assuming it works in a similar way as described above. Thanks, Jeff. nagualdesign 23:19, 17 January 2018 (UTC)
@Nagualdesign: It's not that simple. Coming up with two or more consistent, cohesive file description pages with correct attribution from the visible edit histories can be nigh impossible at times. Some of the tools used to do it (like deletion, viewing deleted, restoration, hiding, and unhiding) are Admin-only by design. Just make a request at COM:SPLIT or categorize clearly defined files into Category:Media requiring a split up and your request will get filled soon enough.   — Jeff G. ツ please ping or talk to me 05:05, 18 January 2018 (UTC)
That's really helpful. Thanks, Jeff. It does seem like making work for other people though, when I'm more than capable of doing it the hard way myself. If I make any requests, is it fairly quick and easy for an admin to complete it? nagualdesign 21:32, 18 January 2018 (UTC)
@Nagualdesign: You're welcome. However, your "{{U|Jeff G.|Jeff}}" did not notify me.   — Jeff G. ツ please ping or talk to me 18:11, 19 January 2018 (UTC)
That's annoying. nagualdesign 19:15, 19 January 2018 (UTC)
  • Although a split per se requires admin tools, I think some edit-warring could be avoided if it were easier to start a forked version of a file. I’m vaguely envisioning a script, launched from a link just below the existing “Upload a new version“ link, that would work like a new upload except that it would copy the licence & categories, and put appropriate {{Derivative}} & {{Infosplit}} templates in the Source & Author fields that reference the original file, reducing the amount of ‘paperwork’ required.—Odysseus1479 (talk) 22:51, 18 January 2018 (UTC)
  • I'm not sure if it covers everything you are looking for, but I used to use derivativeFX a lot for creating derivative retouches etc. At some point I stopped using it, because it stopped working (maybe in the great toolserver migration saga). I just tried it with a test upload, and it worked fine, so it must have been fixed. It's not quite the workflow you describe, because it assumes you have downloaded and edited the file you want to create a new version of already, so it doesn't do any downloading. The obvious thing it doesn't seem to do is put the new file in the "other versions" of the old file (unless I'm missing a trick), but it might be worth a look nevertheless. -- Begoon 02:56, 19 January 2018 (UTC)
That’s really good news, @Begoon: I used it a bit some years ago but had given it up for dead. Maybe it could provide part of the ‘back end’ in a forking gadget. I wouldn’t expect the history to get copied, as long as there’s a solid attribution link to the older file. But the latter should be tagged so that in case it gets deleted, the admin is alerted to do a history merge.—Odysseus1479 (talk) 04:39, 19 January 2018 (UTC)
Oh, I'm glad to hear that's working again. I'll have to give it a whirl sometime. It's been so long since I used it last that I can't remember how it works! (I'm sure I'll fathom it.) nagualdesign 19:15, 19 January 2018 (UTC)

Proposal to uninstall Flow




Leaving a redirect

Perhaps file movers could benefit form the usage of suppressredirect. When a file is moved, a redirect is left behind. Sometimes, no direct links (on commons at least) point to the old name. Perhaps file movers can gain that right? Artix Kreiger (talk) 22:23, 25 January 2018 (UTC)

  • Agreed This is very useful: I have a similar right on en.wp and it comes in handy there but mostly due to name conflicts. In the case of files named "x9sdf8sf.jpg" or "IMG_0001.PNG" or "thing.gif", those are names that shouldn't even redirect because they should never have been created in the first place. —Justin (koavf)TCM 22:47, 25 January 2018 (UTC)
  • Agreed. This is certainly one of the rights that I think could be unbundled a little bit. I have come across a number of requests in Category:Other speedy deletions where the file mover has had to leave a redirect but it isn't a particularly useful redirect. An admin having to delete that redirect is just piling extra resources onto a task that could be done by one user --> the trusted file mover. Green Giant (talk) 22:55, 25 January 2018 (UTC)
I propose that file movers be given that right, but I think it is named "Not create redirects from source pages when moving pages (suppressredirect)" per Special:ListGroupRights.   — Jeff G. ツ please ping or talk to me 04:17, 26 January 2018 (UTC)
Jeff, that appears to be the wording. Artix Kreiger (talk) 05:39, 26 January 2018 (UTC)
@Artix Kreiger: Kindly recheck your code for the missing "re" in the middle. {{s}} as technical proposer.   — Jeff G. ツ please ping or talk to me 23:41, 28 January 2018 (UTC)
  • Oppose for older (not brand new, unused) files, other projects, including those using InstantCommons, might be using the file even though they don't show up in the global usage. Deleting the redirects would break their file references. --Steinsplitter (talk) 19:02, 26 January 2018 (UTC)
@Steinsplitter:, how long would you divide "old" and "new"? Artix Kreiger (talk) 19:36, 26 January 2018 (UTC)
@Zhuyifei1999:, what about for newer files? A cut off time limit, lets say, a week? Artix Kreiger (talk) 20:19, 26 January 2018 (UTC)
What issue does deleting the redirect solve? --Zhuyifei1999 (talk) 20:49, 26 January 2018 (UTC)
  • Symbol oppose vote.svg Oppose Unless there is a technical method to enforce a time gate, and not just a written rule. I'd almost be tempted to unbundle as a higher-than-admin right - to ensure admins are consciously evaluating the value of a redirect. In many cases the redirects are pretty harmless even if they are 1 day old.--Nilfanion (talk) 21:06, 26 January 2018 (UTC)
  • Symbol oppose vote.svg Oppose As above: it's better to have this function more controlled, as leaving a the redirect depends on time and on theusage of the file. In any case, leaving a redirect behind is not an issue, and it has practically no impact on disk space. --Ruthven (msg) 10:50, 27 January 2018 (UTC)
  • Symbol oppose vote.svg Oppose I don't understand the problem that this is trying to solve, so per Zhuyifei1999. Storkk (talk) 15:51, 27 January 2018 (UTC)
  • No, Don't delete redirects. — regards, Revi 15:57, 28 January 2018 (UTC)
    @-revi: Deletion of redirects can be helpful in cases of page move vandalism (for both involved pages).   — Jeff G. ツ please ping or talk to me 23:36, 28 January 2018 (UTC)
    Vandalism is one of the 'obvious exception' to that essay, I think. — regards, Revi 01:39, 29 January 2018 (UTC)
  • Symbol oppose vote.svg Oppose: There are very few circumstances when it's helpful to delete a redirect. In those cases, it shouldn't be a problem to propose the redirect for (maybe speedy) deletion in the usual way. --bjh21 (talk) 19:54, 29 January 2018 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose per others. The default for moving a file must be to leave the redirect, everything else would be dangerous. That's how we've always done it, and there are good reasons for that. We can check usage on WMF wikis and fix file links there after a move (I think we've even got a bot for that), but we have no control over external wikis using mw:InstantCommons or other websites linking to Commons via normal URLs. We don't even know which files are used externally, so deleting redirects by default would break things without us even knowing. I the few cases where a deletion actually makes sense, it can easily be done manually. That should be a very conscious decision, and our current way of doing it supports that by requiring to actively and consciously filing a (speedy) DR. --El Grafo (talk) 13:16, 1 February 2018 (UTC)
  • -1, the suppressredirect right encourages mindless deletion of redirects. Speaking of which, it's worth removing that right from the sysop package unless we're quick at desysopping users who abuse it. --Nemo 13:33, 13 February 2018 (UTC)
  • Symbol oppose vote.svg Oppose per El Grafo and others. Since cc-by-sa 4 accepts "linking to the source" as legal, deleting redirects would break the legal use of this licence by tons of external usages. --Smial (talk) 10:38, 15 February 2018 (UTC)
  • Symbol oppose vote.svg Oppose per Smial, El Grafo, and others. File namespace redirects should not be deleted for license compliance reasons.   — Jeff G. ツ please ping or talk to me 16:41, 15 February 2018 (UTC)

Wiki Loves Transportation

I suggest to create a new annual event. Wiki Loves Transportation - a competition of photos of cars, trucks, buses, locomotives, vessels, airplanes, other vehicles etc.
Why it is important: vehicles have the short term of active use. Old models are utilized (scrapped) and replaced with new.
We can keep images of vehicles for history.
Please, add Your comments and vote below. --George Chernilevsky talk 19:28, 30 January 2018 (UTC)

  • Symbol support vote.svg Provisional Support I would be all for this but it would require a lot of organization. For instance, in which countries would this take place? Wiki Loves Monunments and Wiki Loves Earth are country/regional specific. Who would judge? How would it be organized? I could think of more questions but I believe I have established my point. Don't misunderstand me, I think this is a fine idea, I just would like more details. -- Sixflashphoto (talk) 20:07, 30 January 2018 (UTC)
  • Symbol support vote.svg Support, For this, organization needs work and scope needs refinement before things happen. Aside from that, this is a good idea to work with for information. Natural progression of change should be documented and will serve people well. Artix Kreiger (talk) 00:48, 31 January 2018 (UTC)
  • Symbol support vote.svg Support, I regularly upload images of vehicles (though as I am not knowledgeable in most brands and their sub-categorisations I refrain from seeking them out), and it's quite common for vehicles to be missing. I also suggest a competition for “corporate vehicles” (which might now be deleted as “spam” or “obvious COI’s”, but as many companies go bankrupt these images could serve as historical preservation), or training vehicles (another category horribly underrepresented). Most automobile 🚗 models are notable enough to have entries on various Wikipedia’s, but it's quite common for there to be almost no images of a certain model here so giving people more incentive to photograph more vehicles (or just photograph more in general) is always a win 🏆. --Donald Trung (Talk 💬) ("The Chinese Coin Troll" 👿) (Articles 📚) 08:51, 1 February 2018 (UTC)
  • Symbol support vote.svg Support Christian Ferrer (talk) 17:34, 1 February 2018 (UTC)
  • Symbol support vote.svg Support I like this idea very much. Also I hope to see some writing contest about railway which is interesting for me. --Visem (talk) 19:37, 1 February 2018 (UTC)
  • Symbol support vote.svg Support I like the idea. Fully supporting this! — D Y O L F 77[Talk] 02:13, 2 February 2018 (UTC)
  • Symbol support vote.svg Support Good idea. De728631 (talk) 04:21, 2 February 2018 (UTC)
  • Symbol support vote.svg Support Good idea. Second International wiki-project from Ukraine. :-) --Nickispeaki (talk) 17:51, 3 February 2018 (UTC)*Symbol support vote.svg Support
  • Pictogram voting comment.svg Comment Who's going to do all the category cleanup? Transportation images tend to have a more complex and detailed category structure than much of the rest of Commons. For example, identifying the model of an automobile is a difficult task. This sounds like something that will end up with a lot of images in top-level categories, making them not particularly useful, unless there is a great deal of organization to ensure good category sorting. Pi.1415926535 (talk) 19:32, 3 February 2018 (UTC)
  • Pictogram voting comment.svg Comment I agree with Pi. There are all sorts of subjects that individuals love and could base a project on. On the small scale, I think Photo Challenge would be more appropriate, especially if you pick just one category (e.g. scooters). The "Wiki loves" is on the other scale and can involve a huge amount of volunteer effort. Even though WLM does generate a large number of images, in some countries the results are disappointing such that for all the effort put in locally, a year's competition produces not even one image worthy of FP. I don't know about other countries, but in the UK WLM is aided as the historical buildings are already plotted on a map so you can click on it and upload and it will be identified correctly. Even for less advanced systems, it is usually not hard for the photographer to state correctly what building they are looking at. Whereas I wouldn't have a clue which model of train engine or bus I see, and while I can identify a modest number of cars, I wouldn't be specific enough to know it was the 2011-2015 model, say, and there are plenty people who's identification abilities go no further than "red car". Add to this the problem that reviewing/judging the candidates can be a long and tedious job. It is fine if the quality is high and there is variety, but if we lack both then it becomes very dull. Some people on WLM just seemed to upload their camera's memory card. For transport, I could see someone standing beside the road snapping everything that went by and uploading all of that. Perhaps the first step would be to create some kind of WikiProject Transport for Commons where you get enthusiastic people together and encouraging each other. That may be sufficient, and may also help to set some standards, both in terms of documentation and approach to photography, but also standards of what quality and style of image we best need. -- Colin (talk) 08:15, 15 February 2018 (UTC)
  • Pictogram voting comment.svg Comment I think it doesn't make sense to !vote on this until some interested people have spend some time to actually work out a concept. Until then, I'll remain sceptical, as I share the concerns expressed by Pi and Colin above. What could work, though, is focusing on immobile transport-related objects such as train stations or aerodromes. They are easily identified by non-enthusiasts; and there are lists available that could be used in a similar way as monument lists are used for WLM. --El Grafo (talk) 16:15, 15 February 2018 (UTC)
  • Suggestion: why not have a transportation photo challenge at Commons:Photo challenge every year or 6 months? --P 1 9 9   21:12, 16 February 2018 (UTC)
  • Symbol support vote.svg Support, there are lots of existing photography groups who like taking photos of trains, cars, planes etc that could be engaged who probably have very large back catalogues. My experience is that people who like taking photos of transport tend to know the names of makes and models so I can't see a huge amount of images being added to top level categories, I guess there will need to be some work on creating new categories for new things we don't have photos of. John Cummings (talk) 14:47, 21 February 2018 (UTC)
    • John, that's the thing, though. People who are already motivated to photograph and accurately record transport don't need WLT, though they might enjoy a wiki project. Huge WL* competitions just attract thousands of noobs and would indeed fill the top level categories and also end up with images in proportion to the popularity of a vehicle rather than in proportion to how much Commons lacks that model. Large competitions need to be designed to create optimal content, whereas I suspect this will actually decrease the average quality of transport images on Commons. -- Colin (talk) 19:12, 21 February 2018 (UTC)
@Colin:, this exactly my point, a very small percentage of photographers contribute images to Commons, attracting 'noobs' (new contributors who may already accomplished photographers) is very good way of getting more images and the only way to grow the community. They are unlikely to 'fill up' top level categories, more create new ones for content we don't yet have images of. The success of the competition very much depends on who takes part, there are many existing communities who can be engaged with excellent images. John Cummings (talk) 19:33, 21 February 2018 (UTC)
And WLM achieved that? If you exclude the Commons regulars who contribute to WLM, and who would have contributed anyway, the quality of photos is generally poor. You get a handful of serious photographers who enter the competition with (usually downsized) images but don't contribute anything else. They treat it like someone entering any competition with half a dozen photos and then forgetting about it till next year. WLM made identification easy, whereas this makes accurately recording the subject (a vehicle) rather hard. I couldn't tell you accurately what precise model my own car was. Photo challenge is more successful at attracting and retaining noobs and it only needs a few people to run and organise it, rather than hundreds, and there's no prize money. -- Colin (talk) 21:43, 21 February 2018 (UTC)
  • Symbol oppose vote.svg Oppose I'm not a fan of all this inflationary "Wiki Loves..." copying (there is plenty of, but none of that has ever been as successful as Monuments; not even Earth). But who actually says that Photo Challenge topics cannot be repeated? Just run transportation challenge one time each year, that's the same. --A.Savin 14:57, 25 February 2018 (UTC)

Proposal to rename account creator group to batch uploaders

Background:

Per COM:VP#Abolish the 380 images upload rate for non-admins, high content contributors can on occasion run into the 380 uploads per 72 minute rate limit. The right that overrides this is noratelimit. This right is currently assigned to admins/'crats/stewards as well as the account creator and bots groups. Currently there are only two account creators and Effeietsanders. This right is also only assignable by stewards at meta. This right is only assignable by 'crats or by stewards at meta.

Proposal:

  • Rename the account creator group to Batch uploaders
  • Add the ability to add and remove the group to the administrator group
  • Both of the current account creators are trustworthy enough to be grandfathered into this new group.

Requirements:

  • Batch uploaders need to show that they understand copyright through a history of good uploads.
  • Individuals looking for this right should show that they have use for it by having a history of batch uploading (via Flickr2Commons or similar gadgets).
  • A 10,000 edit minimum was mentioned at VP but I'm not all that convinced that that is necessary (please discuss this below).
  • A simple request at COM:PERM detailing why you need the right can be made for this flag.

Responses (rename account creator group)

  • Symbol support vote.svg Support As proposer. --Majora (talk) 03:29, 27 January 2018 (UTC)
  • Fully supported, note: while name change can be simply done by changing group name via MediaWiki NS config, granting/revoking permissions to sysops (currently 'crats) require config change. (I can do this. Just FYI.) Sysops, global rollbackers, stewards, crats, does not require this flag. — regards, Revi 04:17, 27 January 2018 (UTC)
  • Symbol support vote.svg Support   — Jeff G. ツ please ping or talk to me 23:42, 28 January 2018 (UTC)
  • Symbol support vote.svg Support, this is good. Artix Kreiger (talk) 02:08, 29 January 2018 (UTC)
  • Symbol support vote.svg Support As one the few people with this right, I'd like to point out that it makes very little difference to uploaders. I believe the 380 image limit has almost nothing to do with this right, based on the fact that I uploaded over 3 million images without running into the limit before being given the 'noratelimit' right. It might be that the problem needing solving (380 limit) is a bit tangential to waiving limits, and is probably better solved by such a person reading up on how to use GWT or similar tools. It should remain an extremely rare request based on need, and my need was based on moving pages not uploading images, plus I probably can be considered trusted to take a great deal of care over how fast I run mass actions or automation. Very, very few people have a good reason to exceed the normal limit of, I think, 8 images per minute upload - that includes almost every batch upload project I can think of. This basic upload limit means that an upload of 100,000 images takes just over a week. If someone wants to upload, say, a million images in a day or a week, that should require a proper community discussion and some testing before such a remarkably fast run that could make a huge mess even if highly experienced uploaders are doing it. Sorry to dampen the parade, but anyone requesting this should be able to demonstrate that they really do seriously know how to run a Commons project, and having a minimum 10,000 edits as a precursor would be a trivial part of that. -- (talk) 22:11, 29 January 2018 (UTC)
  • Symbol support vote.svg Weak support I say this as someone who doesn't see a need for this right personally. If someone wants to upload 100,000 images this can already be done in over a week as Fæ at aptly pointed out. So saying this will unleash mass uploads wouldn't be right. If someone wants too they will find a way. My real concern is for License Reviews being flooded with images. More then once I've spent the better part of an afternoon doing LR's, checking them each and following policy until I wake up the next morning and there are more then a thousand new images needing review in the PD images alone. As long as Fæ's words are taken to heart "It should remain an extremely rare request based on need" then I wouldn't have a problem with this. Honestly I'd rather see this limited to License Reviewers but I can see how this would be useful to some who have no interest in helping review licenses. -- Sixflashphoto (talk) 23:09, 29 January 2018 (UTC)
  • Symbol support vote.svg Support This will probably also reduce the huge backlog at requested batches. --Donald Trung (Talk 💬) ("The Chinese Coin Troll" 👿) (Articles 📚) 11:54, 30 January 2018 (UTC)
  • Symbol oppose vote.svg Oppose in this form. "Batch uploader" is just as misleading as the current "account creator" name, as this user group also has some other limitations lifted that are not related to batch uploading or account creation (see answers to my question below). However, I'd Symbol support vote.svg Support a re-name to another, more suitable name. As noratelimit seems to be the only user right assigned to this group, why not simply use that for naming the group? --El Grafo (talk) 13:01, 1 February 2018 (UTC)
    You are correct. The name is completely irrelevant. The most important part of the proposal is assigning the ability to give and remove this right to admins and the actual requirements for obtaining the right. The name is secondary and noratelimit seems like a fine group name in my opinion. I just didn't want to change the header and actual proposal halfway through since people have already opined. --Majora (talk) 21:56, 1 February 2018 (UTC)
    The new name sounds a lot better if it's "Noratelimit" as that name would simply explain exactly what it does. --Donald Trung (Talk 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:53, 10 February 2018 (UTC)
  • Symbol oppose vote.svg Oppose, I think it is a bad idea to get rid of dedicated account creator group at least until there is a better solution provided for wikimarathons (such as a userright allowing to lift throttle for a specific IP from wiki interface on spot). I realise that the current history of actual usage of account creator group is small, but nevertheless. I am absolutely Symbol support vote.svg pro a separate mass upploader flag. I realise that technically they will contain the same userrights, but I think semantics and entailment of different requirements for obtaining and usage matter. --Base (talk) 17:52, 11 February 2018 (UTC)
    Would you rather it just be called "noratelimit" and it apply to both situations, Base? This would also allow normal admins to apply and remove it. As opposed to the current situation of 'crats and stewards. Having two user groups with the same rights but different names seems a tad overkill. --Majora (talk) 00:55, 13 February 2018 (UTC)
    we already have an example. German wikipedia already has two group example. de:spezial:listgrouprights shows account creator and a "noratelimit" group that has the same user right. Artix Kreiger (talk) 01:16, 13 February 2018 (UTC)
    Look again. They have different rights. The "Limit Except" group also have autopatrol. And I stand by my statement. Even if the Germans did do that, which they don't, I find that a tad excessive and a waste of developer time to put that into the configuration when you can just call it something more general and catch all. --Majora (talk) 01:19, 13 February 2018 (UTC)
    That is certainly an option to have a group called 'noratelimit' and have to separate sets of valid ways to get it — huge number of good faith contributions as proposed for the mass uploader group and evidence that user is involved in conducting some workshops (e.g. an active affiliate member) and has good enough understanding of policies while might not have a huge number of uploads themselves. That being said I personally prefer two flags option or Nemo's variant of lifting upload rate limit for non-new accounts (or even all accounts arguably). As to developers' time, come on, what are you talking about. Creation or changing rights is a matter of editing MW configuration file, and it is even possible to do it right on Gerrit. --Base (talk) 13:26, 17 February 2018 (UTC)
  • I'd rather remove the rate limit for uploads than enshrine upload castes in user groups. --Nemo 13:34, 13 February 2018 (UTC)
    • Symbol support vote.svg Support large amounts of abusive uploads only exclusively happen with new accounts and can easily get mass-deleted with the current tools, there really isn't a use for the current rate limit, nor does it currently stop malicious bots from uploading a lot of bad content, I think that the only people ever disadvantaged by the current rate limit are good faith uploaders, if I'm wrong than anyone can feel free to correct me, but I can't remember the last time that I saw a malicious uploader upload a large amount of files, it's usually that they use Wikipedia-zero to upload films and such which only account for a single file 📁 each, despite their size. --Donald Trung (Talk 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:16, 14 February 2018 (UTC)
  • Symbol oppose vote.svg Oppose expansion of privileges of sysops (see also Fæ’s comment) – Commons has currently 8 bureaucrats. At least, do not allow sysops to turn on this privilege. As for naming, see the subsection below. Incnis Mrsi (talk) 07:31, 27 February 2018 (UTC)
  • @Incnis Mrsi: Do you support the proposal without the expansion of sysop privileges or still an oppose regardless? Looking for clarification for consensus. ~riley (talk) 05:33, 6 March 2018 (UTC)
  • If granting this right will be strictly controlled and abuses promptly curbed, then I do not oppose anything. Let users with more experience in the field decide now to name this user group. Incnis Mrsi (talk) 09:09, 6 March 2018 (UTC)

Discussion (rename account creator group)

Question. has the account creator group been used in upload marathons? Artix Kreiger (talk) 03:35, 27 January 2018 (UTC)

Since 2004 the right has been assigned a total of 8 times. Information per https://tools.wmflabs.org/steinsplitter/gr/?wm=%25%40commonswiki --Majora (talk) 03:41, 27 January 2018 (UTC)
The German Wikipedia has a right just called "noratelimit", aside from account creator. Would that be something to consider? also, special:listgrouprights says that bureaucrats can assign account creators. Artix Kreiger (talk) 04:08, 27 January 2018 (UTC)
Well then. COM:Account creators lied to me. I've modified the background and I'll have to do some more research to see if this right was ever assigned here by 'crats. Give me a moment. --Majora (talk) 04:13, 27 January 2018 (UTC)
(Edit conflict) Yes. It was assigned twice here by a 'crat and removed twice by a 'crat. One of which was a self-change (by a 'crat to themselves). So it has been assigned a total of 10 times either here or on meta since 2004. My personal view on the matter is that a right called "account creator" isn't all the necessary here on Commons. We aren't creating accounts here. The only useful thing is the rate limit override and having two different group with the same set of rights seems a little silly. The idea of a "batch uploader" group on a project that deals with multimedia uploads seems much more logical. I'd also be ok with just changing the name to "noratelimit" and be done with it. --Majora (talk) 04:21, 27 January 2018 (UTC)
(Edit conflict) Yes, crats can do it, and there was new accountcreator this month. I think renaming accountcreator to something 'noratelimit' blah blah would be sufficient. — regards, Revi 04:17, 27 January 2018 (UTC)

Pictogram-voting-question.svg Question What's the "normal" purpose of making someone an "account creator"? Commons:Account creators says "The account creator user right alleviates restrictions in relation to creating new accounts." What exactly does that mean? That doesn't sound like something a batch uploader would need? --El Grafo (talk) 13:46, 29 January 2018 (UTC)

I think there is a rate limit on how many accounts you can create. I don't know number. However, it gives the noratelimit which removes rate limits of everything, not just accounts. — Preceding unsigned comment added by Artix Kreiger (talk • contribs) 20:48, 29 January 2018 (UTC)
@El Grafo: There are various speedrate limits, to protect wiki from users (with good or bad intention) changing stuff too quickly. One of them is account creation limit, others include move limit (including file move), rollback limit, etc etc. — regards, Revi 16:44, 29 January 2018 (UTC)
Right. The name of the group doesn't really mean anything. You have to look at what rights are assigned to that group to really understand what someone could do with it. The only thing assigned to account creators is the noratelimit right per Special:ListGroupRights. That is what would be helpful for individuals who batch upload large amounts of files. --Majora (talk) 21:55, 29 January 2018 (UTC)
@El Grafo: Wikimedia projects only allow 6 new accounts to be created per IP address per day, Account Creators can also bypass the blacklist and create accounts with similar names to existing usernames. This right is essential if you are running Wikimedia events (i.e. workshops) and will be having several people creating accounts in one day or if you assist with the Account Creation process for people that cannot read CAPTCHAs, have a name that hits the blacklist (i.e. JamesSteward; steward is blacklisted) etc. ~riley (talk) 05:38, 6 March 2018 (UTC)
I don't think that is true on this project ~riley. Per Special:ListGroupRights the only right account creators currently have is the rate limit bypass. The ability to override the blacklist is contained within the tboverride right. Which account creators on this project do not have. Account creators on other projects do have that right however. --Majora (talk) 05:44, 6 March 2018 (UTC)
Oh and the ability to override the similar name check is the override-antispoof right. Just for reference. --Majora (talk) 05:47, 6 March 2018 (UTC)

@: You have license reviewer, and license reviewers have different upload limit (virtually none) — regards, Revi 02:40, 30 January 2018 (UTC)

Yes, though I cannot remember any issues before having 'image reviewer' and it may have come without other rights back then. It seems a long time ago. -- (talk) 09:08, 30 January 2018 (UTC)

Results (rename account creator group)

Discussion extended: 30 days to gain further community consensus due to current lack of community input. ~riley (talk) 23:22, 26 February 2018 (UTC)