Commons talk:License review/Requests

Archive (Flickr review)
1, 2, 3

Over-questioning

Hello fellow reviewers and admins. It is nice that we have been able to make "interviewing", or questioning, a common practice for license review requests. It gives more confidence to the person who votes on a candidate. However, it has come to my attention that we are making an increase in the number of questions being asked, and has been escalating since we have started this tradition. I suggest we all limit ourselves to one or two questions (and then more if the candidate needs more questioning) and avoid question spamming. Let's remind ourselves that this isn't an RFA :). Suggestions or feedback welcomed. --ZooFari 03:25, 4 September 2011 (UTC)

I do agree. It is getting more and more like sitting for an examination... --Ben.MQ (talk) 07:51, 4 September 2011 (UTC)

Questions make it easier for us since we don't have to scan all the user's contribs. But I have to admit, I asked too many. What should I do with a user with 70 edits? -- RE rillke questions? 08:58, 4 September 2011 (UTC)

Probably just oppose. Correctly answering questions is not a substitute for demonstrating a commitment to constructive editing. A handful of edits and half a dozen open-book answers can be quickly put together by someone intent on doing damage. (And as unlikely as that sounds, I've seen people go to far greater lengths than that to wreak havoc.) Not that one should assume bad faith in any given instance, but license reviewers are supposed to be trusted users, and trust isn't built in a day. —LX (talk, contribs) 09:21, 4 September 2011 (UTC)

I fully agree, trust is based on the actions of the past. --Neozoon (talk) 20:38, 6 September 2011 (UTC)

Previously questions weren't asked at all, and requests were decided entirely on candidates' record and experience. I don't have anything against asking a few questions, though I agree that they shouldn't be over relied upon. CT Cooper · talk 21:29, 6 September 2011 (UTC)

I have limitations to my reliance on questions. If the question seems rather simple yet the candidate fails to answer correctly, I would assume the person did not read the guide page or is simply inexperienced. But that usually seems obvious at first glance judging on contributions and edit count. However, if a candidate who seems experienced does not know the answer to a non-obvious question (or answers wrong), I would just support as long as an explanation to the question is given for the candidate's future reference. That's my main belief of why the practice is beneficial, so that we can clarify to the candidate when needed. --ZooFari 03:18, 7 September 2011 (UTC)

Wow, I just checked the archive and some of them seem like the inquisition. I remember promoting someone once who had no supports simply because he had no opposes. Things have changed. fr33kman 09:49, 30 September 2011 (UTC)

Closed requests

I would actually suggest to keep the closed requests here for a few days before moving them to archive. Easier for people to check back on the status... --Ben.MQ (talk) 20:16, 21 September 2011 (UTC)

•  Support: This page is not that active that hurrying is required. -- RE rillke questions? 20:41, 21 September 2011 (UTC)
•  Support: OK, good. Before I am informed about this, I have archived this request. I have also read the discussion above, so I think this is somewhat necessary--Hoangquan hientrang (talk) 05:21, 22 September 2011 (UTC)
•  Support: sounds good. Warfieldian ^(talk) 14:10, 22 September 2011 (UTC)

Archiving closed requests

I'd suggest to always add the name of the user and the outcome when archiving (on both, this page and the archive). E.g. (User:ExampleUser (successful)). This will ease later look ups without scanning the whole revision history. -- RE rillke questions? 17:27, 23 March 2012 (UTC)

Requests will be open for a minimum of two days

Can we please stick to this principle? I've seen a lot of requests closed sooner than that lately by several different users. —LX (talk, contribs) 20:21, 15 August 2012 (UTC)

I do not think we need to wait for two days for OTRS members. --Sreejith K (talk) 20:38, 15 August 2012 (UTC)

I support this procedure. The last occasions may be triggered by the listing at COM:RFR. The right may be assigned before but the request should be kept open for 2 days so users could comment or ask questions during this time. -- Rillke^(q?) 21:39, 15 August 2012 (UTC)

 Support I agree. I was surprised as well to see so many requests which were closed much sooner. Trijnstel_talk 23:14, 15 August 2012 (UTC)

I agree, it makes little sense to have a community vetting process where many don't have a chance to review the candidates even if they want to. On OTRS candidates, I see it as all or nothing - if they are trusted enough to become license reviewers without delay, then they might as well bypass this process and become reviewers automatically. If that isn't the case, they should be dealt with like any other candidate. CT Cooper · talk 21:21, 16 August 2012 (UTC)

Please do stick to two days. There is no need for hurry. Kind regards, Lymantria (talk) 21:24, 16 August 2012 (UTC)

Another 24 hour promotion today, is the consensus established here and previously on a two day waiting period going to be observed or not? CT Cooper · talk 21:21, 18 August 2012 (UTC)

And it continues. Of the eight nominations started during the last 30 days, one (1) stayed open for 48 hours or more (4 hours and 6 minutes more, to be precise). There are evidently several users who do not believe the documented procedures should apply. That's fine. You're entitled to that opinion. But instead of making up new, undocumented rules as you go, please specify what you think the procedure should be like so that we can agree on how things should be done. Aside from simply not giving enough time for people to comment, the current state of affairs undermines the credibility of the license review process. How can we expect people to trust that license reviewers follow the documented procedures for license review if we don't even follow our own procedures for how license reviewers are appointed? —LX (talk, contribs) 18:57, 22 August 2012 (UTC)

How do u define 2 days... if we agree with 48h that's ok if we just say aprx 2 days then 4 h earlier is acceptable.--Sanandros (talk) 23:22, 22 August 2012 (UTC)

First, you're understating the magnitude of the problem. On average, the nominations during the last month were closed after less than 34 hours, with the median being 10½ hours short of the supposed minimum. Secondly, the term minimum is a lower bound, which by definition does not allow for approximations falling below it. —LX (talk, contribs) 09:01, 23 August 2012 (UTC)

Can I take a wild guess and say that either the people doing this either aren't reading this discussion or aren't thinking about the time limit when approving? Perhaps an edit notice saying "Please ensure that you've waited 48 hours after the request was filed." is in order? --Philosopher ^{Let us reason together.} 21:15, 24 August 2012 (UTC)

Yes, that might get the necessary attention. CT Cooper · talk 21:49, 24 August 2012 (UTC)

Or you just place a red box next to the aproval button...--Sanandros (talk) 00:26, 25 August 2012 (UTC)

I did notify Armbrust and Morning Sunshine of this discussion on their user talk pages, and both have been active since, so if they're not reading this discussion, it's only because they're not reading their user talk pages either. I'd already talked to Sven Manguard about it, and Sreejithk2000 has already commented above, so that covers everyone who closed nominations in less than 48 hours during the last month. —LX (talk, contribs) 07:34, 25 August 2012 (UTC)

I didn't know it would be a problem. But as it is, I won't do it again. User:Armbrust (Local talk - en.Wikipedia talk) 18:40, 11 September 2012 (UTC)

I did it once and I got tripped up because License Review is the only process on the page that has a built in waiting period. The issue here is that you've got it on a page full of things that have no time cushion to them, so it's rather easy to get tripped up. Personally I think that the best option would be to put a timer on each request, like what is done at RfAs. Sven Manguard Wha? 00:57, 13 October 2012 (UTC)

Are you referring to COM:RFR when talking about this page? If so, we could simply add a note below the heading License reviewer there. -- Rillke^(q?) 11:08, 13 October 2012 (UTC)

March 2015

As there have again been several (very) early closes recently, are there any objections to making an editnotice reality? I'd suggest using the following code:

<div class="adminonly licensereviewer" style="display:none;">{{fmbox|type=editnotice|image=[[File:Cmbox deletion.png|40px|link=]]|text=Please do not use the "snowball clause" to promote users before the stated ''Scheduled to end'' date.}}</div>

Which renders as:

BTW, this page should have never been transcluded on COM:RFR in the first place, and is no longer since I have "moved" it to COM:VOTE.    FDMS  4    17:22, 4 March 2015 (UTC)

No objections from me. It would be helpful to alert passing admins and asking users to wait 48 hours to give all parties a chance to comment is not unreasonable and reflects prior consensus. CT Cooper · talk 20:01, 4 March 2015 (UTC)

Makes sense to me, it's not like 48 hours is a long wait. I haven't even had the chance to vote on some of the recent requests because they've been closed so quickly. --Lewis Hulbert (talk) 01:07, 5 March 2015 (UTC)

•  Support per Lewis Hulbert. The last few requests seem to me to have opened and closed between the times I login (which is pretty much everyday). Also, I hope you don't mind but I think this should be a separate section to distinguish it from discussion in 2012. Green Giant (talk) 09:37, 5 March 2015 (UTC)

I think adding a line that snowball closures are forbidden to the page is enough. Edit notice seems a bit... :/ hm... --Steinsplitter (talk) 09:47, 5 March 2015 (UTC)

User:Armbrust, you stated above that "I won't do it again", and yet you did. Would you care to explain? —LX (talk, contribs) 11:54, 8 March 2015 (UTC)

Given the history of this, it seems likely there would be a consensus (even though most 'snow' closes seem like they would end up as approved in the long run) to revert such closes, and remove the userright until the time limit actually ran out. Comments? Revent (talk) 05:08, 9 March 2015 (UTC)

I suggest that we warn people who speedy close often and even revoce their flags if they continue this behaviour. Natuur12 (talk) 10:23, 9 March 2015 (UTC)

Agree with Natuur12. Imho snowball clause is fine when someone with 10 edits requests the right with the reason "hi, i like to help!" (to speedy close as not done - avoiding unnecessary bureaucracy) but not for standard promotions. --Steinsplitter (talk) 11:20, 9 March 2015 (UTC)

Indeed, that's why the editnotice says "promote" and not "close". @Revent: Only admins can revert promotions, and I guess there is a high inhibition threshold when it comes to reverting something that would have to be redone ~24 hours later. That's why I think that an editnotice only visible to users who can close requests is the best solution.    FDMS  4    12:33, 9 March 2015 (UTC)

Support the complete ban on snow closes only. The case with the 10 edits mentioned by Steinsplitter isn't really a snow close, it's rather a notnow closure. User:Armbrust (Local talk - en.Wikipedia talk) 08:28, 4 April 2015 (UTC)

Commons:License review policy

Hi, Some stuff has been discussed a lot of times, and the outcome was always the same. But there was always lack of clarity by non-involved users. I think it is tame to create a officially policy. I created a draft at Commons:License review policy.
Please vote/discuss here
Best :-) --Steinsplitter (talk) 14:43, 24 December 2015 (UTC)

Will it be better to change the last point to "* To become a license reviewer, a formal request at Commons:License review/requests is needed. Requests will be open for a minimum of two days (48 hours). License reviewers and administrators are authorized to close requests and it can be archived after two days."? 大诺史 (Talk/留言/토론/Discussion) 13:16, 27 October 2019 (UTC)

I support a longer archive time. I don't know of anywhere else on the project that requests are archived that quickly. AN/V, a higher traffic page, is 3 days for example - I think the average is 5 to 7 days. ~riley (talk) 05:27, 29 October 2019 (UTC)

Agree with 7 days. There have been several requests this year that were rejected, so it's not a trivial process . --Fæ (talk) 07:57, 29 October 2019 (UTC)

Archiving

I was just gonna set up autoarchiving, then I realised there's a problem.

If we use ArchiverBot, section headers should be ==, not ===.

If we use SpBot, it is intelligent enough to be ordered to archive == or ===, but it doesnt seem to support numerical archives but only date-based archives.

So there could be four options:

1. change section headers
2. change archives format to year-based
3. build a new stronger bot
4. continue manual archiving

I'd prefer #2. What do you think?--Roy17 (talk) 00:09, 3 November 2019 (UTC)

•  Support option 2. Masum Reza^📞 02:17, 7 November 2019 (UTC)
•  Strong oppose for #4 and  Support for #2. -- CptViraj (📧) 02:19, 7 November 2019 (UTC)
•  Support option 2. -- Regards, ZI Jony ^(Talk) 05:42, 7 November 2019 (UTC)
•  Support option 2. -- Eatcha (talk) 05:52, 7 November 2019 (UTC)
•  Support 2 - Admittedly I wanna go with #4 because I've been manually archiving it for yonks and it works.... but meh #2 sounds the next best option. –Davey2010^Talk 23:26, 7 November 2019 (UTC)
•  Support option 2. Better than 1 and 4, and building a bot for that doesn't seem to be necessary. Ahmad^talk 18:42, 12 November 2019 (UTC)
•  Support Option 2 would be best. // sikander { talk } 🦖 21:03, 12 November 2019 (UTC)
•  Note Since we appear to be doing this I'll just do some moves and merges and get the old archives into year format. The current format at the top is distracting. This may take me a little bit to get it all sorted out. --Majora (talk) 00:13, 13 November 2019 (UTC)

  Please do! Masum Reza^📞 04:32, 13 November 2019 (UTC)

Archive age

Just a heads up I've changed the archive age from 7 (days) to 1 - (IE requests will archived a day later and not 7), Previously requests were more or less done a day later and given the page is currently looking clogged([1]) it makes sense to change it,
To my knowledge only 1 or 2 requests have had additional post-comments so it's very rare requests get comments post-close,
Thanks, –Davey2010^Talk 23:34, 7 December 2019 (UTC)

And I've undone it for now because people need to relearn how to close things and apparently one day isn't long enough for me to correct problems. There is no reason why we can't just leave the requests there for 7 days anyways. The page isn't cluttered. --Majora (talk) 04:54, 8 December 2019 (UTC)

IMHO the page is cluttered however in all fairness this went completely unnoticed and obviously we don't want the archive page full of close problems so as such I'm (begrudgingly) happy for it to sit at 7, Thanks for noticing the error btw. Thanks, –Davey2010^Talk 12:02, 8 December 2019 (UTC)

Closing a request before 48 hours elapses

I believe that Revision #401750898 was not appropriate. I think that Majora should have voted in opposition rather than closed the discussion. I do believe, but not know, that in this case the eventual result would be «not done», but the whole point of being a licence reviewer is following the layed out standards, and the standard is «Requests will be open for a minimum of two days (48 hours).» In other words I completely agree that Majora acted in good faith, and the note on the closure will probably help Aurelio de Sandoval to improve and then submit oneself for consideration at a later date, but I would really like this to not become the norm. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 05:29, 6 March 2020 (UTC)

@Gone Postal: COM:SNOW one way or another. That user isn't new, if you catch my drift. - Alexis Jazz ^{ping plz} 09:49, 6 March 2020 (UTC)

Then the appropriate approach would be to vote against that, 48 hours is not a huge amount of time. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 09:59, 6 March 2020 (UTC)

@Gone Postal: you're not catching my drift. This user really shouldn't be a license reviewer. I'd rather not make a fuss, are you willing to take my word for it? - Alexis Jazz ^{ping plz} 22:54, 6 March 2020 (UTC)

I'm sorry if you do not think that was appropriate. But to leave it open would only invite problems. Opposes would have piled up and could have caused further damage to the individual and chased them away. The kind thing to do was to close it and I did so. Hopefully with enough encouragement as to result in them continuing to contribute here constructively. As an administrator I'm responsible for additional user rights, that is part of the administrative remit, and in my administrative capacity I closed that request as not done. Leaving something open just for the sake of leaving it open reeks of bureaucracy. Something we should be avoiding anyways. --Majora (talk) 21:16, 6 March 2020 (UTC)

@Majora: you don't have to worry one bit about chasing this user away, if you catch my drift. - Alexis Jazz ^{ping plz} 22:54, 6 March 2020 (UTC)

Request archive

I noticed that most of the robot archives are judged based on the time of the last message, but in recent several requests, there has been a phenomenon of not closing but archiving. Maybe we should add a similar condition to the robot to Only have templates like {{Frf}} that request can be archived? 轻语者 (talk) 05:57, 20 July 2020 (UTC)

There are two archive bots on Commons: SpBot (currently in use on this page) and ArchiverBot. SpBot uses Template:Autoarchive resolved section, which will only change archive timing based on {{Section resolved}}. ArchiverBot uses the MiszaBot protocol, which does not support any template to change archive timing. We can include {{subst:DNAU}} in the request preload, but that would have to be removed when the discussion is closed. Otherwise, we can have closers include {{Section resolved}} when closing. Both require the closer to do something extra, and I'm not sure either is a better idea. --AntiCompositeNumber (talk) 19:31, 2 August 2020 (UTC)

File:Paper Radio - Maximum Tremolo.opus

Can somebody please review this file today or tomorrow. It is due to be on a main page on 19^th and it's not very nice to have a file that is still in the to do bin. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 05:13, 17 September 2020 (UTC)

Proposal to add activity period

See Commons:Village_pump/Proposals#License_reviewer --Minorax^«¦talk¦» 12:53, 9 July 2023 (UTC)

Commons:Village pump/Proposals#image-reviewer → license-reviewer

FYI. -- CptViraj (talk) 05:17, 2 November 2023 (UTC)

Hiyyihjaleh727

@Queen of Hearts request from Hiyyihjaleh727 and your approval is  Not OK for me. because there is really no consensus and you are not admin. i mean if there is another user for supporting that request i would have be fine that or an admin approve it. but now, it is not ok. so, i kindly request from you to make a request to admin for removal license rewiever rights of Hiyyihjaleh727. thanks. modern_primat ^{ඞඞඞ ----TALK} 14:01, 29 September 2024 (UTC)

@Modern primat, revoked, and discussion re-opened. _Regards, Aafi ^(talk) 14:15, 29 September 2024 (UTC)

Thanks, I too disagree with the closure of the thread. It should never be closed without any comment. Bedivere (talk) 19:26, 29 September 2024 (UTC)

Not that it would change anything but also MasterRus21thCentury's request was closed early. Bedivere (talk) 02:45, 30 September 2024 (UTC)

This has happened for 2 of the last 3 requests for LR. It has always rubbed me the wrong way that LRs can grant LR, but not autopatrol or patroller. All the Best -- Chuck ^Talk 04:10, 30 September 2024 (UTC)

@Alachuckthebuck You're right, I think assigning rights should be removed from LR rights. –TANBIRUZZAMAN (💬) 04:48, 30 September 2024 (UTC)

I'm not opposed to the idea, just that I can give LR to someone, but not autopatroled. The amount of times somone without autopatrolled uses cat-a-lot and clogs RTRC... All the Best -- Chuck ^Talk 04:50, 30 September 2024 (UTC)

• @Alachuckthebuck: @Abzeronow: I think there was no hurry to close the discussion below. It should have just been left open, waiting for more input especially considering that many do not actively watch this page. --Bedivere (talk) 00:23, 14 October 2024 (UTC)

I'll re-open it, but there was no additional input for nine days. If there is no additional input by the end of this month, I'll re-close. Abzeronow (talk) 00:29, 14 October 2024 (UTC)

Fair enough, dear Abzeronow. Bedivere (talk) 01:20, 14 October 2024 (UTC)

Suggestion: Remove assigning of LR rights by LR

Given Alachuckthebuck's comments above, I propose that LR's should not be allowed to add user's to LR group (however, closure is fine). The assigning of rights should be an admin's job. Oftentimes, when LRs grant some autopatrolled user the right, they depend on an admin for the removal of autopatrol as it is redundant with LR. Should be solely an admin's job to grant/remove. _Regards, Aafi ^(talk) 05:51, 30 September 2024 (UTC)

For the sake of transparency, a notification of this discussion has been put on COM:AN and COM:VPP. _Regards, Aafi ^(talk) 06:08, 30 September 2024 (UTC)

•  Support as proposer. _Regards, Aafi ^(talk) 05:51, 30 September 2024 (UTC)
•  Support –TANBIRUZZAMAN (💬) 05:52, 30 September 2024 (UTC)
•  Support while I remember granting the right when I wasn't an admin, I completely agree with the proposal, preventing misuse. Bedivere (talk) 05:58, 30 September 2024 (UTC)
•  Strong support Agreed. // sikander { talk } 🦖 12:46, 30 September 2024 (UTC)
•  Oppose - I believe if the community allows editors with LR rights to proceed with the closing of discussion. Then I assume, LR should be given the ability to remove autopatrol or patrol rights (from the user if they are promoted). In case, no discussion takes place for 48 hours or more then based on admins discretion close the discussion as successful or unsuccessful. Thanks --C1K98V ^{(💬 ✒️ 📂)} 06:29, 30 September 2024 (UTC)

  either LRs can should remove patroller rigths or only admins can grant it. interestingly, im both oppose and support. modern_primat ^{ඞඞඞ ----TALK} 08:51, 30 September 2024 (UTC)

  Patroller & Autopatroled rights actually. –TANBIRUZZAMAN (💬) 09:06, 30 September 2024 (UTC)

 Comment - I think it's a bit unfair to lots of LR's who got the right after demonstrating their familiarity with the copyright policies, but then there are users who are getting the LR rights without any questions or community consensus. The discussion should be left open until there's at least some support from a user or if an admin decides to grant them at their discretion after 48 hours not anytime soon. As far as this discussion is concerned, I believe only the admins are superior to users with LR rights, and LR's are quite knowledgeable and familiar with lots of issues, so I think they either should be allowed to grant or remove autopatroled, patroller, and LR rights or shouldn't do any of that at all because I don't understand how LR's are supposed to grant rights without removing the redundant ones. If they're allowed to grant other rights as well, then this will help admins with the backlog as well because sometimes autopatroled requests take days to be answered. Waqar💬 09:58, 30 September 2024 (UTC)

Good ideas. There is either 1: LRs can remove autopatrolled/patrolled when granting the right, and if they have removal rights for autopatrolled/patrolled, they should also have grant rights as well. 2: They don't have any of these grant/remove rights. The second appeals more to me given that the rights are granted after a community discussion/ can't be granted by an admin at their own discretion. That is to say consensus is always needed, whoever closes the discussion. Discussions where there is hardly any input should be kept open instead of closing at one's own discretion per how the right is granted.

If LRs are allowed to grant the right, they should also be allowed to grant/remove redundant rights. However, they depend here on admins so I believe it is good to leave the granting of the rights to an admin. _Regards, Aafi ^(talk) 10:04, 30 September 2024 (UTC)

There is absolutely no technical reason to remove redundant rights. Just ignore them, even it's difficult. Krd 13:10, 30 September 2024 (UTC)

redundant rights should be removed. modern_primat ^{ඞඞඞ ----TALK} 14:01, 30 September 2024 (UTC)

This less about removing redundant rights, and more about making RTRC and recent changes more useful, as a lot of non-autopatrolled users are using cat-a-lot, making any edits during the run hard to spot. All the Best -- Chuck ^Talk 14:45, 30 September 2024 (UTC)

•  Oppose per C1K98V. Admins who don't specialize in LR shouldn't be granting this right, only users who already have an interest and expertise in LR like me.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:25, 30 September 2024 (UTC)

  That's not a bad idea. But here another issue raised actually. When someone grant the LR right, they technically assign 3 rights. So either LR users should can assign/remove patroller and autopatroled rights, neither they shouldn’t have the right to assign any rights. –TANBIRUZZAMAN (💬) 14:35, 30 September 2024 (UTC)

  Why? Krd 15:16, 30 September 2024 (UTC)

  @Krd, I'm not in favour to keep the right with LR, while I don’t think this will missuse by a elected reviewer. But Reviewers are already able to assign both rights by assigning someone LR rights, aren’t they? So why shouldn’t they have the right to assign both rights separately. But on other hand, I think or my personal opinion is assigning any kind of rights should be an Admin job only, and assign of rights should be removed from LR rights. –TANBIRUZZAMAN (💬) 16:03, 30 September 2024 (UTC)

  Admins who don't specialize in LR have not and will not be granting this right anyway. Bedivere (talk) 15:38, 30 September 2024 (UTC)

  yes. modern_primat ^{ඞඞඞ ----TALK} 15:41, 30 September 2024 (UTC)

  @Aafi I propose a new discussion with two options; whether LR's can grant/remove autopatroled, patroller, and LR rights or remove LR's ability to grant/remove rights at all because clearly a lot of users are supporting the first option. I too support the first one because I don't think LR's would misuse the right in anyway, and their help will be very useful in order to grant autopatroled rights to users who are contributing positively on Commons. Waqar💬 16:37, 30 September 2024 (UTC)

  I think this proposal could reasonably be closed with consensus being that LRs should be able to and remove patroller/autopatrolled, while still being able to add, but not remove LR. All the Best -- Chuck ^Talk 16:53, 30 September 2024 (UTC)

  I think these should only be granted by an admin. It's not like we have a backlog of requests. All of these can be reasonably closed by an admin. Bedivere (talk) 16:56, 30 September 2024 (UTC)

  @Bedivere, What makes an admin who never held LR more likely to correctly close LR requests? (also, the less admin-only tasks we have, the better. Admin should be not a big deal but commons has so many admin only tasks, it is a big deal, and anything we can do to reduce admin only tasks, the better. If early closes are a problem, that's something we can solve by changing policy regarding closes, not who actually closes the request. All the Best -- Chuck ^Talk 17:01, 30 September 2024 (UTC)

  Admins are supposed to have the trust of the community to handle these requests. License reviewers are expected to do license reviewing, not granting the right to others. Simple as that. Bedivere (talk) 17:22, 30 September 2024 (UTC)

  According to policy, LRs are expected to approve LR requests. All the Best -- Chuck ^Talk 17:35, 30 September 2024 (UTC)

  @Alachuckthebuck, although it says, After a few days, a reviewer or administrator determines whether there are no severe objections to the applicant - this is what brings us here to discuss a change. Policies mustn't remain stale but changed/upgraded with the frequencies of the time and need. _Regards, Aafi ^(talk) 17:38, 30 September 2024 (UTC)

  @Aafi Sorry I didn't explain my point fully, I was rebutting @Bedivere's argument that handling LR requests is out of the remit of LRs. All the Best -- Chuck ^Talk 17:44, 30 September 2024 (UTC)

  This whole discussion was started because a reviewer closed a request with no opposition, but no support either, so in the first place it shouldn't have been closed. Secondly, as Aafi clearly says, the policies should not remain stale. Reviewers have (including myself) granted this right but an admin may revoke other duplicated rights, while the reviewer cannot. I do not think that reviewers or any other user group other than admins and bureaucrats should be able to grant or revoke rights. Previous participation here from admins before granting the right to applicants with "no severe objections" (from your own quote) is not needed, after all, administrators are expected to know what they're doing. We expect reviewers to review licenses. We expect admins to do administration job. Bedivere (talk) 18:13, 30 September 2024 (UTC)

  @Iwaqarhashmi, I don't think yours is a resonable proposal. LRs main job is to help with reviewing and not to grant/remove hats. @CptViraj makes more sense in his comment. _Regards, Aafi ^(talk) 17:35, 30 September 2024 (UTC)

  @Aafi, Being able to give those particular hats makes patrolling easier by allowing LRs patrolling RTRC to proactively grant autopatrolled to users who are clogging up the unpatroled edits queue with (perfectly fine) cat-a-lot runs. All the Best -- Chuck ^Talk 17:42, 30 September 2024 (UTC)

  Chuck, you can request for specific users to be autopatrolled at COM:RFR. Abzeronow (talk) 19:18, 30 September 2024 (UTC)

  @Jeff G., didn’t noticed your full comment. I don’t think any admins are non specialist regarding LR. If there's any, I don’t think they should be an Administrator at all. –TANBIRUZZAMAN (💬) 17:42, 30 September 2024 (UTC)

•  Strong support, long overdue, inconsistency with other user rights. Allowing LRs to remove (auto)patroller is extending the problem, not solving it. -- CptViraj (talk) 17:09, 30 September 2024 (UTC)
•  Oppose I do not think that the process should be changed just because there has been one incorrect granting of rights. And removing redundant is one of the least important task that exist. It is perfectly fine if redundant rights are just removed once an admin notices it and decides to take care of it. --Ameisenigel (talk) 19:00, 30 September 2024 (UTC)
•  Comment If LRs can assign the same right to any other user (didn't know until this discussion), why bother with this process of requesting LR here? Any user can post a request on talk page or email an existing LR and get rights assigned to them without any tracking or awareness of what is happening. I'm not saying an existing LR would deliberately sabotage the project, but the possibility exists and should be removed. // sikander { talk } 🦖 04:26, 1 October 2024 (UTC)

  Because (to my knowledge) there are isn't an LR who would say yes. All the Best -- Chuck ^Talk 15:29, 1 October 2024 (UTC)

  Sikander, how many such incidents have happened in the past? This is a problem looking for solution. The assigning of LR user right is governed by policy and LRs are expected to know the relevant policies even before they're promoted to LR. So, possibility of abuse remains very low. Letting LRs promote successful candidates to LR does more good than any harm. --Ratekreel (talk) 14:49, 2 October 2024 (UTC)

  Ratekreel, hopefully none, but that is the point, how would anyone know? // sikander { talk } 🦖 15:17, 2 October 2024 (UTC)

  I believe it is perfectly okay to seek technical help from users who can, like we usually do - ask stewards to help if local crats/sysops cannot act on a thing. Closure is okay given it is not a technical issue. Like you say it above, the major workflow of LRs is to know relevant policies and have relevant knowledge of licensing but that's really inconsistent with granting the rights to others. Why should, for example, only a crat be able to grant a TA flag then, and not a sysop or a translation admin? So much inconsistency. _Regards, Aafi ^(talk) 15:19, 2 October 2024 (UTC)

  Please excuse me, but you can't be serious about this accusation? You don't need to accuse us other license reviewers of being corrupt and of secretly assigning user rights against community consensus. Especially since an admin could do the same and there are public logs. Killarnee (talk) 22:47, 2 October 2024 (UTC)

  @Killarnee my comment was literally, "I'm not saying an existing LR would deliberately sabotage the project." Good that there are logs, tracking is always a good thing. Cheers :) // sikander { talk } 🦖 01:30, 3 October 2024 (UTC)

• Are the leftover redundant rights really a problem? There's no technical reason to remove redundant rights as Krd pointed out and it doesn't harm the wiki. I'm all for LRs promoting successful candidates to LR. This way we will have reviewing process maintained by LRs and patrolling admins (who have the required knowledge), eventually leaving other admins to the tasks where there presense is more needed. Also, if we remove the ability from LRs to promote a user to LR, then what's the point of letting them to close requests? Wouldn't they still be dependent on an admin to actually grant the rights?
  However, I do not think that LRs should be able to grant autopatrol and patrol user rights because it's simply out of scope of their responsibility and purpose. They already do so when they promote a user to LR and it's not their work to assign any other rights. I'm unable to grasp why "either LR should be able to assign/remove patroller and autopatroller rights or they shouldn’t have the right to assign any rights." Removing these rights may be considered only in cases when removing redundant rights, if it's really an issue. Give these reasons, I'm  Opposed to the proposal. --Ratekreel (talk) 14:23, 2 October 2024 (UTC)

  The adding/removal of (auto)patrol is based on the concept of them granting it to users while recent changes patrolling/ RTRC because the majority of edits on the logs are experienced editors who don't have autopatrolled making cat-a-lot runs. This was then summarized by @Aafi to present the 2 options: to allow them to remove and grant those rights when granting LR, or not be able to grant rights. All the Best -- Chuck ^Talk 15:38, 2 October 2024 (UTC)

•  Strong oppose The fact that this suggestion comes from an admin who would not be affected by it himself is really disturbing for me. The problem of closing and granting rights before the 48 hours have expired has always existed and has been discussed many times. I find it unacceptable that this misconduct is now being passed on to all license reviewers.
  Probably such inappropriately hasty decisions do not happen on Com:RFR not because only admins are allowed to make decisions there, but because there is simply no time frame before a decision is allowed to be made.
  Change the wording from Scheduled to end to At least open until and there will be fewer misunderstandings.
  License reviewer is not a right that is granted by admins and then you have a new software function, license reviewers are their own community and should therefore continue to be allowed to decide independently who can become part of this community. Killarnee (talk) 22:42, 2 October 2024 (UTC)

Speaking as a reviewer who became a sysop, I am still active in license reviews as a sysop so it's not entirely true that administrators are not part of the LR community. I always found it unusual that LRs can bestow the right on other LRs, but I don't see the harm in continuing the practice. LRs are trusted users, and the likelihood of abuse is minimal. Abzeronow (talk) 17:55, 3 October 2024 (UTC)

Seeing as opinions in this discussion fall mostly along "party" lines, I currently don't see a way for this to be closed impartially by a single editor. Here is my proposed closure: A panel of 2 uninvolved admins and 2 uninvolved active LRs should close the above discussion. If we don't mind getting outside help, then maybe have a steward close? All the Best -- Chuck ^Talk 16:30, 4 October 2024 (UTC)

Or this is closed as no consensus as it's a 5/4 split. All the Best -- Chuck ^Talk 16:31, 4 October 2024 (UTC)

Yes, I can see that as a possibility. (I don't think we need a steward to close). We can always wait a few more days to see if others wish to discuss this, there's no rush for this to be closed. Abzeronow (talk) 18:09, 4 October 2024 (UTC)

+1. Let's keep it open for a few more days. ─ Aafī on Mobile ^(talk) 18:53, 4 October 2024 (UTC)

@Aafi@Abzeronow, its been over a week, close as no consensus to change? All the Best -- Chuck ^Talk 03:03, 13 October 2024 (UTC)

Re-opened discussion per objection by Bedivere. Abzeronow (talk) 00:29, 14 October 2024 (UTC)

2 weeks later, no consensus. @Abzeronow, Can you close? All the Best -- Chuck ^Talk 04:03, 31 October 2024 (UTC)

What's the hurry, @Alachuckthebuck? This is an open discussion. Just let it be. Bedivere (talk) 04:25, 31 October 2024 (UTC)

Let's wait at least a few more days, maybe someone will join the discussion now. Abzeronow (talk) 16:16, 31 October 2024 (UTC)

 Oppose bureaucracy as well as solution looking for a problem. RoyZuo (talk) 23:39, 2 November 2024 (UTC)