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)