Commons:Bureaucrats' noticeboard/Archive 2017
![]() | 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. |
- MtDu (talk · contributions · Statistics · Recent activity · block log · User rights log · uploads · Global account information)
MtDu is a GCI student and I've mentored him while he converted templates to use the Translate extension, a very needed work which is going to get some speed thanks to him. I've checked that he learnt how to prepare templates for translation correctly, and I'm going to keep an eye on him anyway. Please grant him translation admin rights in short order! --Nemo 22:19, 7 January 2017 (UTC)
- Support With TA rights he'll be able to rename already translated pages and migrate them using Special:PageMigration, instead of just copypasting the translated text with no previous edit history preserved.--Piramidion (talk) 23:04, 7 January 2017 (UTC)
- Note that Special:PageMigration may not (yet) support all that is needed for this work on templates, but I agree it's good for MtDu to use it: he's a coder, so he may improve PageMigration to simplify his own work, and let other editors become more productive too. ;-) I'll also keep a mind on the possible process/tooling improvements, thanks for the reminder. --Nemo 23:19, 7 January 2017 (UTC)
- Support no concerns. I've been helping with their translation work, and everything has been done correctly. Nick (talk) 17:12, 10 January 2017 (UTC)
Done --Krd 19:21, 10 January 2017 (UTC)
- This section was archived on a request by: --Krd 19:21, 10 January 2017 (UTC)
Request for Translation administrator
- Tulsi Bhagat (talk · contributions · Statistics · Recent activity · block log · User rights log · uploads · Global account information) (assign permissions)
- Hi ! I would like to request for Translation administrator user right to mark pages for translation (a example) as well helping in TA maintenance tasks such as here and so on. I'm experienced of TA's tools as being Translation administrator on Meta-Wiki and Wikidata (verify). Moreover, I'm sysop on maithili and nepali wiki as well active rollbacker, patroller and filemover here on commons. Thank you. — TBhagat (talk) 09:50, 6 January 2017 (UTC)
- Support Yann (talk) 10:23, 6 January 2017 (UTC)
- @Tulsi Bhagat: please don't put the translation tags inside the section headers like this. This sometimes results in broken edit section links, and doesn't provide the context for the translators (see the "header" row on mw:Help:Extension:Translate/Page_translation_administration#Markup examples).--Piramidion (talk) 16:37, 6 January 2017 (UTC)
- Hmmm.. Okay :-) — TBhagat (talk) 01:01, 7 January 2017 (UTC)
Done --AFBorchert (talk) 09:09, 8 January 2017 (UTC)
- Please see this. -- Geagea (talk) 02:35, 11 January 2017 (UTC)
- The global lock of this account is indeed concerning. However, there is no immediate need for action as long as the account remains locked. The lock has been described as “temporary stop-gap measure” and the door is open to further clarification. I think it is appropriate to wait for this to happen. I've contacted the steward in charge and intend to stay in touch. --AFBorchert (talk) 06:27, 11 January 2017 (UTC)
- Yesterday, a socket was created, asking for a clean start and redirecting a number of user pages to his new account. This appears to be quite some zoo of sockpuppets. I've decided to remove the local translationadmin right as it is unlikely that this account will be unlocked. --AFBorchert (talk) 16:57, 14 January 2017 (UTC)
- The global lock of this account is indeed concerning. However, there is no immediate need for action as long as the account remains locked. The lock has been described as “temporary stop-gap measure” and the door is open to further clarification. I think it is appropriate to wait for this to happen. I've contacted the steward in charge and intend to stay in touch. --AFBorchert (talk) 06:27, 11 January 2017 (UTC)
- This section was archived on a request by: --AFBorchert (talk) 16:57, 14 January 2017 (UTC)
Return of my sysop bit..again...
Unless crats have a policy-based reason not to, I'm requesting my adminship back. I've found that not having the tools doesn't make me feel any more relaxed or make Commons more enjoyable. I see each day many things I could take care of easily as an admin, but I have to report them or tag them for deletion (spam, vandal pages, etc). The unblock of Livio after 2 requests at AN for unblock is hardly something that would've resulted in a de-sysop, especially as he remained blocked for 3 months and is now editing constructively with no problems. I won't undo another admin's action again though, as it isn't conducive to respectful working relationships.
In any event, what I've found is that after 425,000 log actions as an admin here, editing without the bit sucks. The removal of my bit was self-requested and no plans for a de-sysop were underway when I self-requested removal of my sysop bit, which was an overreaction. I thereby request my adminship be returned. I know this can be seen as a bit of a flip-flop in a long line of such flip-flops, but so what? It's not hard for crats to check the sysop right in user right management, and it's not hard to desysop someone either. I think Commons is better off with an admin of my experience than not. I have my flaws, but I don't think they're nearly bad enough to make me a "bad admin". In fact, I think I've been a damned good admin overall. Thanks for your time. lNeverCry 04:05, 19 January 2017 (UTC)
- No objections. I'd love to have INC back on the team. --Hedwig in Washington (mail?) 04:47, 19 January 2017 (UTC)
- okay. -- MCMLXXXIX 04:53, 19 January 2017 (UTC)
- Ok for me too. --Christian Ferrer (talk) 05:29, 19 January 2017 (UTC)
- I'm not familiar with the recent removal, so won't personally apply the flag, but am generally supportive. --99of9 (talk) 05:31, 19 January 2017 (UTC)
- Strong support You haven't lasted long as a regular user. Welcome back! --jdx Re: 07:14, 19 January 2017 (UTC)
Done The admin bit was resigned while being in good standing in 4 December 2016, hence there is no problem in getting it back somewhat more than a month later. --AFBorchert (talk) 07:59, 19 January 2017 (UTC)
- Strong oppose. I can't believe what I'm reading here, both the request and the rapid agreement to it. INC was certanily not "in good standing" when he resigned his bit. The circumstances at the time involved a user Livioandronico2013 who had been blocked by A.Savin for repeated disruption at Featured Pictures Candidates. INC has a long-running personal dispute with A.Savin, and he was very opposed to this block, making all sorts of personal attacks on A.Savin over it. Several times INC tried to get the block overturned but was refused. Finally he deliberately went against community consensus and overturned the block himself. He then posted on BP saying "I've removed it. If someone wants to put it back, you'll have to desysop me first.". This is simple bullying by an admin and totally against our policy which requires admins to respect consensus and work towards achieving consensus for actions they wish to perform. He then wrote "I just wanted to let you know I've removed your unfair block on Commons. I'm ready to lose my adminship for the principle of it....I will keep Livio unblocked as long as I'm an admin and he doesn't re-offend." which is a threat to wheelwar with anyone re-blocking Livio. This was followed by this post where he asked for his rights to be removed. He explained why he believed he was unsuited to adminship and wrote "Let me make it very clear that I don't intend to be a sysop here again." He added later "I've asked to have my sysop bit removed for the last time...I don't think I'm fit for adminship anymore. If anyone ever sees another RFA from me, please oppose it!" Further added "I just want to make it clear that I do not under any circumstances want my sysop right returned once stewards remove it tomorrow. Not in a month and not in a year. I won't bother the community with another RFA. The community has my word on that. I don't expect that an RFA from me would garner much support after this". I don't know which part of this is not clear to AFBorchert or INeverCry -- you gave your word. INC very much resigned under a cloud and would have faced a de-admin had he not resigned. Indeed, when Nick asked if this was considered to be the case, INC wrote the above statements that he would never re-apply for the bit. The response to INC's actions at Commons:Administrators' noticeboard/Blocks and protections/Archive 19#Super block of Livio removed made it clear the community thoroughly disapproved of INC's behaviour. I repeat Natuur12's earlier comment on a previous un-consensual unblock of Livio by INC "Don't get me wrong, I highly respect INC but unblocking against consensus while being involved is one of the most severe mistakes an admin can make. Forgivable, but still severe". INC repeated his mistake after that warning and did so threatening to wheelwar with any admin while he still retained his bit. It is clear to me that INC should not ever again be an admin, and restoring it like this, without wider community approval, is disgraceful behaviour. -- Colin (talk) 09:58, 19 January 2017 (UTC)
- Oppose I strongly Oppose the actions of both INeverCry and AFBorchert. I will be writing the necessary de-sysop request today. This is a Benny Hill sketch, isn't it. We just need Yakety Sax playing in the background. It's repeatedly INeverCry making one or more terrible administrative actions, members of the community complaining about those actions, INeverCry resigning rather than even beginning to take ownership of the problems he is causing, then waiting usually four weeks or so for the heat to die down and then trundling along to this noticeboard and requesting the bit back. INC has a user permission log longer than half the bureaucrats who resysop him.
If this were the English Wikipedia, we would be looking at a waiting period of 24 hours before resysopping (something we should encourage here) and given the circumstances which have led to so many of INC's resignations, the resignations would be considered 'under a cloud' and a new RfA would be necessary. INC didn't just leave under a cloud last time, as Colin points out, there was unblocking against consensus and a belief that wheel warring was acceptable - that's not leaving under a patchy cloud, it leaving under a full blown storm front moving in.
INC must resign and run a new RfA, or I am once again drafting a de-sysop request. Nick (talk) 10:14, 19 January 2017 (UTC)
- Oppose The restoration requires an RFA, the reasons for this should have been obvious to any active bureaucrat who examined the history of resignations and impassioned statements from INeverCry that their sysop rights must not be restored. Should INeverCry be committed to regaining sysop rights, they should create an RFA under their own steam, where the community can have the opportunity to restore their confidence in INeverCry's competence and stability to hold the mop. --Fæ (talk) 10:23, 19 January 2017 (UTC)
- Oppose based on procedure. I would have supported when INC made a RFA instead, but requesting the admin bit here on BN is a different case. As a counterargument to AFBorchert's "The admin bit was resigned while in good standing", INC wasn't fully in good standing. Some counterexamples are the controversial Livio case and the second indef block of PetarM by INC (not to mention his insult to me, but that doesn't bother me). This is not a distrust to INC, but I just don't like this restoration of admin tools without a wide community consensus (wide, meaning a RFA). --★ Poké95 10:42, 19 January 2017 (UTC)
- Oppose Because Colin is right, + because I have NO CONFIDENCE WHATSOEVER in this user as sysop for a wide variety of reasons (I really don't know if it's possible for him to regain any trust from my side, but at least one year of constructive editing without sysop bit, without drama and personal attacks, is necessary; an explicite apology for what happened on Krassotkin's RfA I don't even hope for), and last but not least, the statement: I just want to make it clear that I do not under any circumstances want my sysop right returned once stewards remove it tomorrow. Not in a month and not in a year. I won't bother the community with another RFA. The community has my word on that. and then now, just few weeks later, demanding back the sysop flag, even without a new RfA. That is breach of word, that is fully unbecoming of a gentleman, that is... simply disgusting. By now, I had some very little hope to reconcile with him some day, but now it's all gone. No way. --A.Savin 12:56, 19 January 2017 (UTC)
- Oppose I still respect and like INC but he made a promise like a month ago. Now he is breaking this very same promise. This is something one cant't do. I hope INC will do the right thing and resinge so we can have a proper RFA. Natuur12 (talk) 13:08, 19 January 2017 (UTC)
- Oppose per Natuur12. --Steinsplitter (talk) 13:36, 19 January 2017 (UTC)
- Neutral I am rather torn here. I respect INC as an editor and I must say that he has contributed positively to Commons as an editor and administrator. However, given the fact that he was desysopped and resysopped a lot of times in the past, I am unsure whether to support his re-adminship request or not. Sometimes, he lets his temper get in the way, and this is rather dangerous for him and the project. I am aware that his health condition is not really stable (I noticed that he was burnt out a lot of times due to strenuous admin work). I am not sure of having him back as an admin. With that being said, this is not a punitive measure, but rather a preventive measure. Jianhui67 talk★contribs 14:29, 19 January 2017 (UTC)
- Support I don't have any objections, but probably will be good idea to learn how to rest with administrator privileges. --EugeneZelenko (talk) 15:31, 19 January 2017 (UTC)
- Support - the sooner the better! - Jcb (talk) 15:58, 19 January 2017 (UTC)
- Oppose As the comments above demonstrate: Users disagree whether INC resigned in good standing or not. For that very reason a new RFA is required to assess if there is still support for INC acting in the role as admin. If INC does not go through a new RFA, you will alienate the users, who believes he should and there will be allegations that procedures were not followed - with good reason. INC would never be respected as a real admin by a significant fraction of the users. It will inevitably lead to conflicts and drama. On the other hand if there is continued support in a new RFA, there is nothing to argue about. It is the clean way to do it. -- Slaunger (talk) 17:38, 19 January 2017 (UTC)
- Oppose per above. It seems to me going by INC comments, they fail to understand or are completely ignorant to the concerns that have been raised by the community. The fact INC has continued to use the sysop tools (deleting files) while requested not to use it and then thumbs the noses of the community by placing the Admin template on their user page while discussion about the resysop is underway. In light of this, it highlights to me that they are not suited to have the privilege (it isn't a right) of the sysop tool. It is in INC's best interest to resign and start a RFA, since allowing the community to request a desysop will leave you in a far more worse position than your in now. Bidgee (talk) 20:14, 19 January 2017 (UTC)
- Oppose from me as well, the flag was restored out of process, and the request should have gone to RfA.--Ymblanter (talk) 20:20, 19 January 2017 (UTC)
- Oppose Congrats all, we are the laughing stock of WMF and personally now, I don't think INC is the issue anymore. We seriously need to look at updating our own policy in regards to this and take one or 2 bureaucrats to task (they know who they are). It seems like our own policy is as old as the US Constitution and archaic as somethings on it are no longer relevant now. After this issue is solved, can we have a new policy whereby an admin who dropped his/her rights (under or over a cloud lol) can ONLY request their rights back ONCE and after that if it happens again, they need to go through a proper RfA to get their rights back. Honestly, this should have never gone this far and surely this time, we cannot blame INC for our own failed/outdated policies.--Stemoc 22:55, 19 January 2017 (UTC)
- Support I realize I am in the minority here and I see people I like and respect opposing but I really don't see it as an issue. I also strongly believe that if people are laughing at us then they need to look a lot closer at other projects like EnWP because they have far more problems and a lot more violations of policy and trolling on a daily basis than we have here in a month. When they start fixing problems in their own house then they can laugh and talk shit but until then they need to focus on their own problems. I do agree that the policy should be reviewed though and it seems like that discussion has begun below. As for the comments about going back through RFA, sure, maybe he should have gone there but I am seeing several people saying they would have supported it anyway. So at the end of the day the outcome probably would have been the same anyway. Reguyla (talk) 23:15, 19 January 2017 (UTC)
- Strong support that Colin says is false, tendentious, boring and repetitive. Disgusting here are only your arrogant ways to do A.Savin. Nick next time read what happened and what led to the actions and not only speak for the part that interests you, what happened to me is "Benny Hill" thank you.--LivioAndronico (talk) 10:39, 20 January 2017 (UTC)
Extended discussion on AFBorchert's actions
I think it would be appropriate to be more supportive here to INeverCry. He is a dedicated member of the community and a very experienced admin. He has, this is no secret, good times where he is one of the pillars of this project and times where he is struggling. If under such circumstances he feels more comfortable in temporarily resigning the admin bit we should respect that and be glad when he returns after some not too long period (just a bit more than a month in this case). His last RfA is less than a year old where he had strong support from the community at a time where his history of good and not so good times was already well known. --AFBorchert (talk) 13:00, 19 January 2017 (UTC)
- @AFBorchert: I have a great deal of respect for your views and experience. I do not dispute anything you have said here, and I agree that some comments above lack civility and are overly personal; those doing that deserve a good trouting. However I do feel that it is in INeverCry's own interests to take responsibility for sysop tools again when they feel confident enough to run an RFA. Being accountable to the community is a firm requirement on administrators. The years long history of emotive resignations with direct requests to ignore future resysop requests is a natural concern for everyone. It is unfortunate that INeverCry has dismissed that here with "I know this can be seen as a bit of a flip-flop in a long line of such flip-flops, but so what?" rather than taking on-board how this will be seen. Considering the apparent distress at the time of INeverCry's most recent resignation, it is likely that should they be held accountable for past or potential future admin actions, this will be difficult for INeverCry, the level to which this is a real problem or not is something that an RFA can help with.
- An RFA should not be something that any administrator should fear. Reconfirmation RFAs should be a sign of a well governed project. If a project suffers from overly challenging RFA processes, that is something that the administrator group, and especially bureaucrats, should put effort into fixing. At the current time, there is no pattern of serious issues with the way our RFA process works, especially when compared to other projects. --Fæ (talk) 13:31, 19 January 2017 (UTC)
- @AFBorchert: , I don't, frankly, have any respect for you as a 'crat, which I should admit is based on only a few occasions of you doing anything 'crat/admin that I'm aware of. Here you demonstrated how completely out-of-touch you are with the events that led to INC's resignation. And your swift reinstatement of the bit, without waiting for a resonable period for comment, also shows very poor judgement and respect for community consensus. His resignation was not "temporarily" but final, and the community only didn't follow through with a messy de-admin because he promised it was final. Let me be clear, the community strongly disagrees with and disapproves of your reinstatement of INC's bit. If you do not remove it today, I shall start a de-crat process on you. Wrt showing support/respect, my quotes above carefully edited out all the bits where INC divulged rather more personal details than was wise, and stuck to his statements/promises to not regain adminship. This is sufficient. We have someone who is not only frequently a bad admin, particularly wrt blocks of long-term users, but also is not a man of his word. I have no problem with INC as a non-admin. -- Colin (talk) 14:08, 19 January 2017 (UTC)
- @Colin: Err, bureaucrats are unable to revoke administrator status. Only stewards can do it. Jianhui67 talk★contribs 14:29, 19 January 2017 (UTC)
- I did not know that. Then he should request it, or indicate somehow he wishes to revert his action. Some acknowledgement of his misjudgement is also desirable, to give us any confidence in his role as 'crat. -- Colin (talk) 14:37, 19 January 2017 (UTC)
- @Colin: Err, bureaucrats are unable to revoke administrator status. Only stewards can do it. Jianhui67 talk★contribs 14:29, 19 January 2017 (UTC)
- AFBorchert - INeverCry resigned after completely ignoring community consensus to unblock a problematic user and then threatened to wheel war in respect of a dispute. This was not a period where INeverCry didn't feel able to administrate, it was a period where he absolutely felt he could administrate, where he believed his decisions were valid and would be supported by the community, but where he was completely wrong. When the community expressed concern at his conduct, he resigned, promising (a promise he should have been hold to by you) of not asking for the administrator permission back.
I get the impression you're completely unaware of the circumstances surrounding the last resignation, is that the case ? Nick (talk) 14:23, 19 January 2017 (UTC)
There has been files a removal request at meta, see: meta:Steward requests/Permissions#INeverCry.40commonswiki. @AFBorchert: In order to avoid more confusion we need a definite statement if the decision stands or if anything needs to be corrected. Thank you. --Krd 17:43, 19 January 2017 (UTC)
At Commons we have a long tradition to return an adminbit to a former admin, provided the admin resigned while being in good standing and not too much time passed since then. There was some conflict in September 2016 and heated disagreements in October and December. But none of this lead to a discussion in the direction of a de-sysop of INeverCry. I can accept the criticism that I should have waited at least 24 hours before closing such a request. But I still see his still quite fresh RfA from June 2016 and I do not see anything of significance which casts a shadow about that. As I said before, we know that INeverCry has his good and occasionally not so good times. When he resigns the admin bit at a time of personal crisis, we should respect that and welcome him back also as admin when he thinks it is the right time for that. I do not think that it is helpful to take such an opportunity to revive old conflicts.
In summary, with all due respect to the comments that arrived after my decision to return the adminbit to INeverCry, I still think that this was the right thing to do. But I accept that I should have waited longer and I wouldn't have done it without in-depth discussion with the fellow crats considering the amount of opposes. But I did not do it by accident and consequently I stand to that action and take responsibility for this. --AFBorchert (talk) 19:24, 19 January 2017 (UTC)
- @AFBorchert: Please resign as cat, you acted against community consensus. For what it is worth: I support de-crat AFBorchert. --Steinsplitter (talk) 19:28, 19 January 2017 (UTC)
- This would be an over-reaction, and I doubt there would be any appetite within the community for a decrat vote on top of handling INeverCry's RFA. --Fæ (talk) 19:34, 19 January 2017 (UTC)
- I also wouldn't go as far. Stewards should remove the flag and INC is then perfectly free to run a new RfA, which hopefully will not succeed. --A.Savin 19:40, 19 January 2017 (UTC)
- Steinsplitter, on which page should there be the initial discussion prior to a formal decrat? Should a new section be opened below, or on another admin page? I have examined AFBorchert activity since becoming a 'crat and there is nothing to suggest we need this rather inactive and clumsy 'crat. This is not the first time AFBorchert has claimed an admin was "in good standing with the community" when this was very much not the case. I also find his statement that INC's resignation was "temporary" to be a blatant untruth. We need crats who are aware of community feeling (divided or otherwise), who can report truthfully, and who are active enough that they actually make a difference as a 'crat. AFBorchert is none of these. A.Savin, AFBorchert continues the falsehood that INC was "in good standing" despite evidence that the community was about to de-admin him for his actions. Far from showing the leadership that we expect of a 'crat, he has instead made an almighty mess we could have done without. Simply, any 'crat should have reminded INC of his promise and left it at that. -- Colin (talk) 19:44, 19 January 2017 (UTC)
- While a de-crat debate will likely do more harm than good I do wish AFBorchert to resign as a crat. We don't need clueless inactive, out of touch crats who disrespect the community. There are three reasons why I dropped my admin activity at this project and this kind off cluelessness is one of them. Natuur12 (talk) 20:21, 19 January 2017 (UTC)
- Natuur12, I agree that would be the least disruptive option. AFBorchert, you have barely used your 'crat powers, having (as far as I can see) only performed a few such actions, which have either been obvious and uncontentious closes, or this kind of mess where you misjudge the situation and cause much community discord. The last big cockup on your part required WMF to de-admin the abusive admin you failed to even criticise. It would really be better for all if we did without you as a 'crat, and I don't think you'd miss the role. -- Colin (talk) 20:40, 19 January 2017 (UTC)
- I've just looked at AFBorchert's crat logs, and my conclusion is now: we don't need this user as a crat. Rename log is completely empty, and the still very few user rights log entries are — with the exception of today's INC resysop — such as granting filemover/rollback/patroller flag, which sysops are able as well. So, given all that, Support now also a de-crat of AFBorchert. --A.Savin 20:49, 19 January 2017 (UTC)
- Just as a point of correction, let me mention that the rename log would necessarily be empty—bureaucrats no longer rename users on Commons, and haven't done so since the introduction of the Single User Login; all of us who are not simultaneously global renamers would see their rename logs empty, there's no other way. odder (talk) 20:52, 19 January 2017 (UTC)
- I've just looked at AFBorchert's crat logs, and my conclusion is now: we don't need this user as a crat. Rename log is completely empty, and the still very few user rights log entries are — with the exception of today's INC resysop — such as granting filemover/rollback/patroller flag, which sysops are able as well. So, given all that, Support now also a de-crat of AFBorchert. --A.Savin 20:49, 19 January 2017 (UTC)
- Natuur12, I agree that would be the least disruptive option. AFBorchert, you have barely used your 'crat powers, having (as far as I can see) only performed a few such actions, which have either been obvious and uncontentious closes, or this kind of mess where you misjudge the situation and cause much community discord. The last big cockup on your part required WMF to de-admin the abusive admin you failed to even criticise. It would really be better for all if we did without you as a 'crat, and I don't think you'd miss the role. -- Colin (talk) 20:40, 19 January 2017 (UTC)
- While a de-crat debate will likely do more harm than good I do wish AFBorchert to resign as a crat. We don't need clueless inactive, out of touch crats who disrespect the community. There are three reasons why I dropped my admin activity at this project and this kind off cluelessness is one of them. Natuur12 (talk) 20:21, 19 January 2017 (UTC)
(ec) This is extremely unfortunate, and I think that the decision to give INC his bit back was in the circumstances a mistake. While I would myself have no objection to him becoming an administrator again, I recognise that some of his past actions have been contentious and I think that the community should have had a say, in the form of a fresh RFA. Unfortunately, since bureaucrats are not technically able to remove the admin bit, any correction of the situation will need to go to the stewards. I would like to see a joint application made by the bureaucrats to the stewards to that effect. MichaelMaggs (talk) 19:26, 19 January 2017 (UTC)
- @MichaelMaggs: What past actions? The unblocking of Livio after 3 months and 2 discussions on AN/B that showed more consensus for changing or removing the block? That wasn't a good unblock by me, and I created some drama around it, but it wasn't something horrible, and the community isn't in any immediate danger because I'm a sysop again for however long. As for stewards, Adrian and Vito have rightly declined requests to remove my bit at Meta, so it looks like I may get the chance to defend myself at a desysop request, though such a request is what would really be unfortunate. Out of my 415,000 actions as an admin her, how many have been problematic? I've worked as hard as anybody to build this project and help the community. lNeverCry 19:36, 19 January 2017 (UTC)
- You've said yourself, above, that "... this can be seen as a bit of a flip-flop in a long line of such flip-flops", and that in itself makes me think that the community needs to have a say. --MichaelMaggs (talk) 19:45, 19 January 2017 (UTC)
- User:INeverCry, there are many unfortunate past actions. Please don't try to pretend there is only one. And the Livio thing was indeed "something horrible" -- it was an admin taking upon himself to reject previous community opinion, to repeat a mistake he had already been warned by many users and admins for (a previous unblock), and to threaten the community that you will keep Livio unblocked while you retain your bit. That, I'm afraid, INC, just killed all hope of you becoming an admin again. The fact that you think it a triviality of nor harm, is very damaging. I strongly advise you to resign rather than face an de-admin where all your previous crimes are listed. -- Colin (talk) 19:51, 19 January 2017 (UTC)
- You've said yourself, above, that "... this can be seen as a bit of a flip-flop in a long line of such flip-flops", and that in itself makes me think that the community needs to have a say. --MichaelMaggs (talk) 19:45, 19 January 2017 (UTC)
- @MichaelMaggs: What past actions? The unblocking of Livio after 3 months and 2 discussions on AN/B that showed more consensus for changing or removing the block? That wasn't a good unblock by me, and I created some drama around it, but it wasn't something horrible, and the community isn't in any immediate danger because I'm a sysop again for however long. As for stewards, Adrian and Vito have rightly declined requests to remove my bit at Meta, so it looks like I may get the chance to defend myself at a desysop request, though such a request is what would really be unfortunate. Out of my 415,000 actions as an admin her, how many have been problematic? I've worked as hard as anybody to build this project and help the community. lNeverCry 19:36, 19 January 2017 (UTC)
- It concerns me greatly that AFBorchert's comment has completely ignored the concerns raised and has instead tried to justify their poor decision of the speedy actions to resysop. AFBorchert should file for a reconfimation for 'crat to test the trust the community has. Bidgee (talk) 20:23, 19 January 2017 (UTC)
Statement from INeverCry
My action regarding Livio was certainly questionable, but his case was brought to AN/B twice, and there was consensus in the two discussions together for shortening or ending the block on Livio. I understand that my unblocking him and being emotional and argumentative about it wasn't the best choice, but I truly felt it was the right thing to do at the time. He's done great since the unblock, and I'm very happy about that. But to be on the safe side, if I'm allowed to keep adminship going forward, I won't perform any other questionable actions of this kind. I haven't done so in often in the past, and these situations don't come up very often as it is.
If allowed to remain an admin going forward, I'll be sticking to my usual round of DR and CSD work. If somebody wishes to start a de-sysop, then of course the community will tell me what my fate is one way or another. I mostly stick to simple deletion and block work, so I hope the community doesn't consider a de-sysop necessary in this case.
I can be erratic, and I know that. I change my mind sometimes and wish I'd done things differently. I'm a faulty human. However, I've always done my best to work hard as an admin to help the community. I hope that nobody doubts my commitment to Commons and my love of our project. In any event, I would request anyone to please not come down hard on AFBorchert. This is on me not him. He does a great job as a crat, and doesn't deserve to have any of my issues rubbing off on him. I do thank him for the return of my bit, which I think was the right choice.
I know that I can faithfully serve the Commons community by protecting it from trolls, vandals, and sockmasters, and getting copyright violations and out of scope material off of Commons quickly and in a professional manner.
Again, I know I'm not the most stable person, but I mean well, and I really do think I can serve the community well as an admin. I've done over 400,000 log actions here, and I'm proud to have been able to contribute in this way. I hope I haven't screwed myself out of the chance to do more. I'm glad to see that a steward has shut down the out of process request made to strip me of the bit at Meta. This is a matter for the Commons community. I deserve the chance to defend myself at a de-sysop at the very least, especially considering my long service here as an admin. lNeverCry 18:12, 19 January 2017 (UTC)
- Bureaucrat Odder asked INC to refrain from performing admin actions until community consensus was apparent to support him. INC rejected this and is performing deletions. He's also rejected the request he start and RFA and instead above requires we de-sysop him. INC, you say "this is a matter for the Commons community". You promised us your resignation was final and you would not request your bit restored. You appear to have no respect for the community in this matter. -- Colin (talk) 18:29, 19 January 2017 (UTC)
- @INC: I have the impression that you already promised to do only uncontroversial admin work last time you got your flags back. Although I appreciate your dedication to the project and your skills to do a lot of work quickly, I'm not sure if reflagging and rely on any desysop possibility is the best approach. Could you imagine to withdraw your request and run a RfA instead, if it only be to end this discussion and the additional disruption that may arise from it? --Krd 18:32, 19 January 2017 (UTC)
- And sadly my idea is already obsolete per discussion at User talk:INeverCry. To be honest, I'd support immediate de-sysop for not honoring community desire in a sensitive matter. --Krd 18:39, 19 January 2017 (UTC)
- @Nick: Considering the responses from INeverCry above and on their talk page, along with their poor decision to use sysop rights against advice whilst discussion of the restoration of those same rights has been on-going, a desysop appears necessary to address multiple concerns from long term community members, to address the mistake made in not following the required 24 hour notification period before restoration, and to ensure that restoration of sysop rights is not against community consensus. Could you proceed with a desysop vote as you proposed above, on the basis that this BN discussion is sufficient "prior discussion" as per Commons:Administrators/De-adminship? Thanks --Fæ (talk) 18:53, 19 January 2017 (UTC)
- Comment Just to make it very clear, I understand that I behaved improperly in regard to the unblock of Livio. He's a productive user, and I wanted to see him get a 2nd chance, but I was too emotional in handling the situation. If allowed to remain an admin, I will not repeat that behavior. I will not unblock any user out of process. I will be sure to consult with them and take the other steps required by policy. As I understand it, Commons:Administrators/De-adminship refers to "an administrator [who] is acting against policy and routinely abusing his or her status." I acknowledge my actions in the case of Livio were not acceptable. I acted from emotion rather than calm consideration. I don't intend to repeat that action. I self-requested the removal of my adminship without giving that the calm consideration or thought I should have. If allowed to continue as an admin, I plan to let other admins who're better with dealing with problem situations deal with noticeboard and blocking issues having to do with long-term users. I will stick to deletions and simple blocks of spambots. spammers, vandals, and socks. We have over 200 admins, and some are better than others in one area of the project, while others are good at different tasks. I realize this. Since I've already been given the admin tools back, I ask the community to give me a last chance. If I were to do anything questionable going forward, a desysop would almost certainly be successful. I know that and would be extra careful with my actions. Either way things go here, I appreciate everyone's consideration. Thank you. lNeverCry 21:56, 19 January 2017 (UTC)
- Commons:Administrators/Requests/INeverCry (readmin) June 2016 INC wrote: "I ended up doing things that were unacceptable, dramatic, and uncalled for ... I went off the deep end ... If the community is willing to give me a last shot at adminship [my bold], I can say without a doubt that there would be no repeat of any of the above ... I would also make it a point to continue to avoid my old confrontational behavior as I have for quite a while now. ... my main focus would be on helping to keep the DR backlog down and deleting copyvios ... My approach would be much more laid back now ... I hope the community is willing to forgive me ... give me a shot at being a Commons admin again, a position of trust that I just didn't realize the full value of in the past." -- Colin (talk) 22:25, 19 January 2017 (UTC)
- All what happened around the time that INeverCry resigned was 1 (one) supposedly controversial unblock. Isn't it weird to judge an admin who does 15.000+ admin actions each month so heavily for one action? And apparently the unblock was not that bad, the unblocked user was not reblocked by anybody. And to be honest, it was a shame after all that this user was not unblocked long before. Jcb (talk) 22:33, 19 January 2017 (UTC)
- Anyone with some common scenes would have realised that reblocking could possibly make the situation far worse than it already was. This can hardly be called an argument. I hate to see INC in this situation but I would hate to see anyone get hurt in the afterburn when INC has a bad moment even more. Natuur12 (talk) 22:37, 19 January 2017 (UTC)
- All what happened around the time that INeverCry resigned was 1 (one) supposedly controversial unblock. Isn't it weird to judge an admin who does 15.000+ admin actions each month so heavily for one action? And apparently the unblock was not that bad, the unblocked user was not reblocked by anybody. And to be honest, it was a shame after all that this user was not unblocked long before. Jcb (talk) 22:33, 19 January 2017 (UTC)
- Commons:Administrators/Requests/INeverCry (readmin) June 2016 INC wrote: "I ended up doing things that were unacceptable, dramatic, and uncalled for ... I went off the deep end ... If the community is willing to give me a last shot at adminship [my bold], I can say without a doubt that there would be no repeat of any of the above ... I would also make it a point to continue to avoid my old confrontational behavior as I have for quite a while now. ... my main focus would be on helping to keep the DR backlog down and deleting copyvios ... My approach would be much more laid back now ... I hope the community is willing to forgive me ... give me a shot at being a Commons admin again, a position of trust that I just didn't realize the full value of in the past." -- Colin (talk) 22:25, 19 January 2017 (UTC)
Statement from the 'crats
Just to keep everyone up-to-date about this, we—the bureaucrats—have discussed this issue among ourselves on the bureaucrats-commons mailing list. Given the nature in which @INeverCry's sysop rights were restored, and based on the many concerns voiced above by a whole variety of users, I have called for a vote on the mailing list to request that the stewards remove, at least temporarily, INeverCry's admin rights here on Commons. We believe that it is within our bureaucrat discretion to reverse the reinstating of admin privileges to INeverCry without what we consider to be the required community approval, and have reached this decision almost unanimously (with 9 votes in favour and 1 opposing). The stewards have now removed the admin bit from INeverCry's account here and we hope it will help us cool down this heated discussion. As I already mentioned elsewhere—and I believe almost everyone can agree with this—we are quite happy to see INeverCry apply for adminship again using the existing and widely accepted procedure of an RfA, if he chooses to do take this path. Thanks, everyone, odder (talk) 00:25, 20 January 2017 (UTC)
- This section was archived on a request by: --Krd 13:46, 25 January 2017 (UTC)
OTRS flag for EniPort
Hi, I'm a member of the Hungarian OTRS-team, and I would like to request the OTRS flag. Thanks. – EniPort (talk) 14:01, 20 January 2017 (UTC)
- The Commons OTRS flag no longer exists. You have to ask for the Commons queue to be added to your OTRS access at the (closed) OTRS wiki, there is no oversight of it by the Commons community. --Fæ (talk) 14:21, 20 January 2017 (UTC)
- Thank you for the reply, I obtained access to the OTRS already. – EniPort (talk) 14:34, 20 January 2017 (UTC)
- @EniPort: The global OTRS flag is assigned by stewards on meta on requests made by OTRS administrators to users with access to the Permission queue. If this is your case, ask OTRS administrators for their request.
- Thank you for the reply, I obtained access to the OTRS already. – EniPort (talk) 14:34, 20 January 2017 (UTC)
- This section was archived on a request by: --Krd 13:47, 25 January 2017 (UTC)
Can I request bot flag only for apihighlimits right?
I have a bot with 550k edits on ruwiki. It reads some lists from api, 5000 entities on list on ruwiki, but only 500 on commons since I don't have bot flag here. Bot reads very large lists (for example, list of all file titles to search files with cyrillic/latin characters mix in titles) and works slow without apihighlimits. Can I request bot flag only for apihighlimits using? MaxBioHazard (talk) 01:14, 14 January 2017 (UTC)
- Of course you can request, but I'm not sure if it's granted for the intended purpose. Did you consider to use the database dumps for this task? --Krd 13:01, 14 January 2017 (UTC)
- I use ruwiki dump for my bots, but it has 23G size, and ruwiki has much less size than Commons. Another reason to use api is that some tasks need newest data, but dumps renewes once a month. MaxBioHazard (talk) 13:11, 14 January 2017 (UTC)
- (Edit conflict) Have you considered using DB replicas on labs? Or use Quarry to generate a list of page titles from the DB replica and download the list? Tool labs also have the dump files locally accessible. --Zhuyifei1999 (talk) 13:18, 14 January 2017 (UTC)
- I use ruwiki dump for my bots, but it has 23G size, and ruwiki has much less size than Commons. Another reason to use api is that some tasks need newest data, but dumps renewes once a month. MaxBioHazard (talk) 13:11, 14 January 2017 (UTC)
- For reporting a max of 500 is sufficient, as you can pull an unlimited number of records by correctly using the continue parameter. This does not look time sensitive. Not against a bot flag but not essential. --Fæ (talk) 13:15, 14 January 2017 (UTC)
- Agree with Fæ, using x-continue param in the api should work. --Steinsplitter (talk) 13:23, 14 January 2017 (UTC)
- Of course, I know about continue and use it, but process, that reads lists with 500 records, works several times slower than process, that reads lists with 5000 records. MaxBioHazard (talk) 13:33, 14 January 2017 (UTC)
- I think it's going out of scope of this page, and your original question has been answered. If this should be discussed in detail, please create a bot request. Thank you for understanding. --Krd 13:48, 14 January 2017 (UTC)
- @MaxBioHazard: There's a global apihighlimits-requestor global group that just grants the 'apihighlimits' permission in case it is just what you want. Requests for that permission should be made at m:SRGP if you're interested. Thanks & sorry for reopening. —MarcoAurelio 19:05, 19 January 2017 (UTC)
- I think it's going out of scope of this page, and your original question has been answered. If this should be discussed in detail, please create a bot request. Thank you for understanding. --Krd 13:48, 14 January 2017 (UTC)
- Of course, I know about continue and use it, but process, that reads lists with 500 records, works several times slower than process, that reads lists with 5000 records. MaxBioHazard (talk) 13:33, 14 January 2017 (UTC)
- Agree with Fæ, using x-continue param in the api should work. --Steinsplitter (talk) 13:23, 14 January 2017 (UTC)
- This section was archived on a request by: --Krd 10:53, 30 January 2017 (UTC)
GWT userright for Met Museum uploads
I'd like to request the GWT userright for Metropolitan Museum of Art uploads. You can see an example from my test upload on BetaCommons at File:Armor Garniture of George Clifford (1558–1605), Third Earl of Cumberland MET DP295743.jpg. We'd like to upload ~1k to start, but this will be a larger project pursued in collaboration with the Commons community over the next several months. (I'm a former sysop here, was removed a couple of years ago due to administrative inactivity.)--Pharos (talk) 18:51, 5 February 2017 (UTC)
- Looks exciting. When you do the live run, it would be useful to put the license in a license-header section. Bots tend to trip over alternative layouts and start flagging the uploads. --Fæ (talk) 18:57, 5 February 2017 (UTC)
- I've granted you you access, but before you start live uploading we'll need OTRS permission from the museum to prove that the CC0 release is approved and that it overrides the more restrictive licence that appears on the museum website. If we get that sorted out first, you'll be able to include the OTRS number in all your uploads, which will save having to add that later and should avoid queries being raised about the release. Alternatively, the website text could be changed to show the CC0 release. I'll email you with more info. --MichaelMaggs (talk) 21:17, 5 February 2017 (UTC)
- Assuming that the articles are themselves obviously very old and in the public domain, you should omit the {{PD-old-100-1923}} tag, (leaving the article PD status to be assumed). You'll just need the {{Cc-zero}} tag plus the OTRS number to establish the fact that the copyright in the photograph has been released. --MichaelMaggs (talk) 21:57, 5 February 2017 (UTC)
- @Pharos, before you start at full speed, please make a test upload here with the toolset. Thank you --Krd 06:54, 6 February 2017 (UTC)
- All OK to go now with some initial Commons trials. Each upload will need to be tagged with {{PermissionOTRS|id=2017020610013172}}. You might try a few uploads with the tag already in place, to see if that works. If not (there may be an error as you're not an OTRS agent), we'll have to work out how to add the tags by bot after uploading. Anyone like to comment on that? --MichaelMaggs (talk) 16:36, 6 February 2017 (UTC)
- I have created a test set for Arms and Armor: Category:Images from Metropolitan Museum of Art.--Pharos (talk) 17:24, 6 February 2017 (UTC)
- No OTRS tags. Did the system strip them out while uploading? --MichaelMaggs (talk) 17:44, 6 February 2017 (UTC)
- Multichill had included them on {{TheMet}}, and I've adjusted it so that part is transcluded now as well.--Pharos (talk) 18:12, 6 February 2017 (UTC)
- Thanks. It all looks good to me. --MichaelMaggs (talk) 18:30, 6 February 2017 (UTC)
- Multichill had included them on {{TheMet}}, and I've adjusted it so that part is transcluded now as well.--Pharos (talk) 18:12, 6 February 2017 (UTC)
- No OTRS tags. Did the system strip them out while uploading? --MichaelMaggs (talk) 17:44, 6 February 2017 (UTC)
- I have created a test set for Arms and Armor: Category:Images from Metropolitan Museum of Art.--Pharos (talk) 17:24, 6 February 2017 (UTC)
- All OK to go now with some initial Commons trials. Each upload will need to be tagged with {{PermissionOTRS|id=2017020610013172}}. You might try a few uploads with the tag already in place, to see if that works. If not (there may be an error as you're not an OTRS agent), we'll have to work out how to add the tags by bot after uploading. Anyone like to comment on that? --MichaelMaggs (talk) 16:36, 6 February 2017 (UTC)
- This section was archived on a request by: --Krd 19:27, 6 February 2017 (UTC)
Public Domain Mark (PDM)
After Flickr introduced the CC Public Domain Mark (PDM), a lot of people use it to mark their works as free to reuse. But we had rejected it as an applicable license here after a short discussion which was not reviewed/closed by a crat. It leads to endless discussions; many experts expressed a different opinion. It comes again VP now. Even if we don't like to accept, Flickr is a major source of the media files which portrays the opinions and interests of the people around the world. So neglecting this issue will be certainly a stopping block for the Wikimedia to collect such contents.
The current solution is that we need to contact individual Flickr users and request to change the license to CC0. We know it is not a smooth solution. we can't collect much contents that way as it is a slow procedure. Some people suggested in that recent VPC discussion that we may contact the legal for advice. I don't know how much it is practical as the legal had said many times that they can't advice the community. Any suggestions? Jee 04:04, 27 January 2017 (UTC)
- The fact is that Public domain has a meaning only in the US, and other countries with similar laws. In France, for instance, you cannot even put something in the public domain; it doesn't mean anything for the judges. That's why we need CC0, which is a license contract. The issue is on Flickr side, for having badly formulated their "PD" version. --Ruthven (msg) 10:53, 27 January 2017 (UTC) PS: This discussion should be moved at Commons:Village pump/Copyright I reckon.
- As far as I know, Flickr implemented it after a consultation with CC. If there is some mistake from their side, it can be resolved with proper discussions as there seems a good relationship with CC and WMF. That's why I bring it here as crats are supposed to be the elected members to lead and guide the community in such matters. I too can contact Mdennis (WMF); but I think it will be more effective if from the crats' side. (COM:VPC discussed this matter in depth, even recently. So what we need is some professional advice; not just another discussion.) Jee 11:49, 27 January 2017 (UTC)
- (I corrected a dead link in Jee's post.--Elvey (talk) 01:37, 31 January 2017 (UTC))
- I'm confused. It seems like the discussion was getting going and suddenly User:Josve05a ended it, prematurely. What came after the "Therefore" in the close doesn't follow from what came before. Was there discussion off-wiki? I'm not saying the decision was wrong, but it does seem premature. Looks like we have respected users whose views were run right over as if they weren't seen. Can anyone present a concrete instance where someone used a work that was released as public domain and was sued successfully for having used it? --Elvey (talk) 02:15, 31 January 2017 (UTC)
- No comment about the "license" had been made in months. The only comments that had been happening whitin two month of closing were on how different external tools should implement the new licnese template. The RfC was closed after having been open for 7 months and 20 days. (t) Josve05a (c) 07:37, 31 January 2017 (UTC)
- Also, the bureaucrat's noticeboard really isn't the right place to discuss this. This has nothing to do with admin/bot management (i.e. crat tasks) and should be discussed on COM:VP. Sebari – aka Srittau (talk) 08:04, 31 January 2017 (UTC)
- The one who opened this thread requested advice from the crats. This issue has been in a long debate, even now. Even admins are confused on what to follow. I don't see anything wrong on bringing the issue here. ★ Poké95 11:03, 1 February 2017 (UTC)
- The bureaucrat's noticeboard may be used to ask for leadership on an issue, in line with COM:Bureaucrats, and Bureaucrats may choose to offer their opinions here, or point to existing policy. However this noticeboard is not the place to reach a community consensus on a copyright interpretation or an interpretation of the precautionary principle, nor are Bureaucrats supposed to act like an elected Arbcom and make rulings that the wider community then must comply with. For these reasons if there is to be a proposal for new guidelines or the RFC is to be reopened, those normal procedures for consensus have to happen. Whether those procedures are lead by a Bureaucrat is up to the individual Bureaucrat, though there as absolutely nothing to stop someone else from taking the initiative. --Fæ (talk) 12:08, 1 February 2017 (UTC)
- Yes; my intention is very clear from my initial post and from my reply to Ruthven: it is a request to the crats to lead the community in gathering some professional advice on this matter, if possible. It is not an attempt to override the current status with another discussion. I don't even intended a discussion here. As we discussed a lot, I don't see any benefit in another community discussion unless we get some qualified advice. And for copyright matters, "any expressed consensus can be taken into account so far as possible, but consensus can never trump copyright law." So what we need to know is whether PDM is legally valid if issued by the copyright holder. Jee 15:27, 2 February 2017 (UTC)
- The bureaucrat's noticeboard may be used to ask for leadership on an issue, in line with COM:Bureaucrats, and Bureaucrats may choose to offer their opinions here, or point to existing policy. However this noticeboard is not the place to reach a community consensus on a copyright interpretation or an interpretation of the precautionary principle, nor are Bureaucrats supposed to act like an elected Arbcom and make rulings that the wider community then must comply with. For these reasons if there is to be a proposal for new guidelines or the RFC is to be reopened, those normal procedures for consensus have to happen. Whether those procedures are lead by a Bureaucrat is up to the individual Bureaucrat, though there as absolutely nothing to stop someone else from taking the initiative. --Fæ (talk) 12:08, 1 February 2017 (UTC)
- The one who opened this thread requested advice from the crats. This issue has been in a long debate, even now. Even admins are confused on what to follow. I don't see anything wrong on bringing the issue here. ★ Poké95 11:03, 1 February 2017 (UTC)
As already stated the topic was discussed at multiple venues already. Could one volunteer to compile a summary page of the results? --Krd 15:32, 2 February 2017 (UTC)
- I'll make a try.
- 1. The RfC was closed with a rational, "Images uploaded from Flickr under the Public Domain Mark 1.0 needs to be tagged with the template {{Flickr-public domain mark}} (substituted as it currently is coded) given that we have no idea why it is under Public Domain. This PD Mark is not a license, nor can someone release something under it. Our current Public Domain-templates, such as {{PD-self}} has a secondary clause that states: "I grant anyone the right to use this work for any purpose, without any conditions, unless such conditions are required by law." which is needed as a "fallback license" in case releasing to the public domain has no legal meaning. We can't relicense something from PD Mark 1.0 to another PD-license/template, since they have different legal text and the Flickr user has not agreed to those terms."
- 2. At Commons:Village_pump/Copyright/Archive/2016/12#Creative_Commons_Public_Domain_Mark_on_Flickr, those arguments are questioned in case if the Flickr user is the copyright holder. There are other cases where Flickr user is not the copyright holder which is not considered. There Carl Lindberg stated that "To me, we should allow it if it's pretty obvious the Flickr account is the copyright owner. CC0 is definitely better, but I think it's the equivalent of PD-author, which is good enough to be beyond COM:PRP for me. Custom licenses or PD statements may have theoretical issues in some countries (it may not be legally possible to waive rights, or a country may allow such a statement to be revoked, etc.) but I think that is splitting hairs to disallow such works where the intention is fairly clear. Such things should probably go through a license review so someone else confirms that the Flickr account seems to be the author, but at that point I think it's OK. Carl Lindberg (talk) 18:39, 20 December 2016 (UTC)"
- 3. I endorsed Carl's argument. Then Ghouston questioned about the lack of "fallback clause". "They haven't agreed to the fallback license on {{PD-author}} though. There should be a template that retains "In some countries this may not be legally possible" and leaves it at that. --ghouston (talk) 02:47, 23 December 2016 (UTC)" But this is an issue for all files that have been released to the public domain by non-Commons users. See Commons:Village_pump#Template_for_generic_public_domain_dedications. (Sorry for the late response; I was away.) Jee 04:19, 6 February 2017 (UTC)
- That's part of it, PD-author has often been misused. But if the Public Domain Mark on own work is accepted, I think it should be with a custom tag that describes the situation exactly, not just a generic public domain template. --ghouston (talk) 05:50, 6 February 2017 (UTC)
- Yes; and I've no problem for a new tag. What I said is "fallback clause" alone is not a reason to decline as we already accepted many files that have been released to the public domain by non-Commons users published elsewhere without a "fallback clause". Jee 06:14, 6 February 2017 (UTC)
- You fail to mention the point which others brought up after the RfC, which weren't included in my closing of it, that it isn't a release, but a label or "mark" of something to be believed in the public domain.
- Yes; and I've no problem for a new tag. What I said is "fallback clause" alone is not a reason to decline as we already accepted many files that have been released to the public domain by non-Commons users published elsewhere without a "fallback clause". Jee 06:14, 6 February 2017 (UTC)
- That's part of it, PD-author has often been misused. But if the Public Domain Mark on own work is accepted, I think it should be with a custom tag that describes the situation exactly, not just a generic public domain template. --ghouston (talk) 05:50, 6 February 2017 (UTC)
(t) Josve05a (c) 23:01, 7 February 2017 (UTC)
- And we forget to mention the simplest option is to inform the Flickr user that their tag choice is unlikely to be correct/useful and that CC0 would be a better choice for their own work. That way the "licence" details are fixed at source, somebody learns something useful for future images, and Commons is in no doubt as to the free nature of the image. But no, Commons users would rather argue among themselves than talk to a real photographer. -- Colin (talk) 08:06, 8 February 2017 (UTC)
- PDM is not a license, and when a work is published without an explicit license or without an enough explicit statment from the copyright holder, it is considered by us, and also likely legally, as not free. But if it is not a license, it may stay the question if it is a relevant statment. But honestly "This work has been identified as being free of known restrictions" worry me a bit, as this mean all and nothing. Identified by who? by the same kind of persons who upload here a CD cover saying "it's my cd, this is not a copyvio" or by the same kind of persons who says "This is free, I found it with google...". Seriously, a work must be licensed by it's copyright holder, that's all. And all the persons who know really what is a license and what is the meaning of a license don't use PDM. Then we should not accept that. Christian Ferrer (talk) 17:31, 8 February 2017 (UTC) Furthermore a statment coming from a person who don't really know what is exactly a license can not be considered as an "enough explicit statment", not even as a relevant one. Christian Ferrer (talk) 17:38, 8 February 2017 (UTC)
- With regard to the last part of your viewpoint, if this were true then valid OTRS releases would be ignored as irrelevant for anyone that any administrator feels does not sufficiently understand copyright licenses. That's not how copyright law works, nor is it how Commons should work. --Fæ (talk) 18:00, 8 February 2017 (UTC)
- LoL! when there is a mail statment this begin to become to be relevant, PDM alone not. Christian Ferrer (talk) 18:12, 8 February 2017 (UTC)
- And we come to Colin suggestion that is when there is good content with PDM, we should contact the account owner for that they put a relevant license or for that they give an OTRS explicit agreement to us. PDM alone is not enough and IMO has even not very much to do with copyright law. It is even the opposite " do what you want with this content but it is up to you to take responsibility if there is legal concerns...." re-LoL Christian Ferrer (talk) 18:40, 8 February 2017 (UTC)
- I don't believe there is anything to discuss here, though I would rather not be laughed at. My statement stands. Thanks --Fæ (talk) 18:57, 8 February 2017 (UTC)
- That's not me who put OTRS and PDM at the same level. PDM is the anti-license, it's the anti-OTRS... indeed it's not funny at all. Thanks to you too. Christian Ferrer (talk) 19:27, 8 February 2017 (UTC)
- I don't believe there is anything to discuss here, though I would rather not be laughed at. My statement stands. Thanks --Fæ (talk) 18:57, 8 February 2017 (UTC)
- And we come to Colin suggestion that is when there is good content with PDM, we should contact the account owner for that they put a relevant license or for that they give an OTRS explicit agreement to us. PDM alone is not enough and IMO has even not very much to do with copyright law. It is even the opposite " do what you want with this content but it is up to you to take responsibility if there is legal concerns...." re-LoL Christian Ferrer (talk) 18:40, 8 February 2017 (UTC)
- LoL! when there is a mail statment this begin to become to be relevant, PDM alone not. Christian Ferrer (talk) 18:12, 8 February 2017 (UTC)
- With regard to the last part of your viewpoint, if this were true then valid OTRS releases would be ignored as irrelevant for anyone that any administrator feels does not sufficiently understand copyright licenses. That's not how copyright law works, nor is it how Commons should work. --Fæ (talk) 18:00, 8 February 2017 (UTC)
Now would be a good time to close this thread. There doesn't seem to be anything actionable for the crats to do. We all understand that the PDM is not a licence, and must not be used as such. --MichaelMaggs (talk) 03:16, 9 February 2017 (UTC)
- +1 --Krd 06:32, 9 February 2017 (UTC)
- This section was archived on a request by: --Krd 08:57, 22 February 2017 (UTC)
Upload project spam blacklist exception 'right'
After finding that images were being rejected from upload during the Portable Antiquities Scheme project, I have created T157897 - Spam blacklist by-pass right for agreed batch upload projects. As I have suggested that agreeing an exception could require Bureaucrat approval, views on Phabricator from Bureaucrats might help decide whether there may be a realistic and volunteer-time inexpensive solution. Thanks --Fæ (talk) 13:15, 12 February 2017 (UTC)
- MediaWiki:Spam-whitelist exists, but is scarcely used, if that helps anybody. Nick (talk) 13:51, 12 February 2017 (UTC)
- Just in case the task is not all that clear, in the example, we want to allow uploads and text from finds.org.uk, and when that text includes blacklisted links we want to allow them; this does not mean we want to whitelist the links so we do not add them to the spam-whitelist. E.g. there are bit.ly links in the example, bit.ly should remain blacklisted, but when the upload is part of an agreed batch upload, we want to make an exception. It's surprisingly hard to put this in a pithy way. --Fæ (talk) 14:00, 12 February 2017 (UTC)
- Ah yes, I understand now, 'we' won't know what the blacklisted links are and don't want the upload batch to fail due to the existence of unspecified blacklisted links. I'd support an exception to the blacklist, but the blacklisted links need to be recorded so we can then fix them (as obviously the existence of blacklisted links prevents subsequent editors saving the description page). Nick (talk) 15:58, 12 February 2017 (UTC)
- I also agree with both the ability to bypass the blacklist and the recording of the exceptions. Reguyla (talk) 16:12, 12 February 2017 (UTC)
- I'm unsure how the recording of exceptions would work. It would be neat if the uploader did not have to detect these (which means making every upload quite a bit more complex) but instead if the blacklist filter process added a category to the page where there was a link filter match, or maybe we could create a new automated page error tag. One benefit of the error tag might be to retrospectively identify past pages using blacklisted links, for example File:Marcha_das_Mulheres_Negras_(23137414611).jpg has a bit.ly link in it which was accepted in 2015. --Fæ (talk) 17:17, 12 February 2017 (UTC)
- Ah yes, I understand now, 'we' won't know what the blacklisted links are and don't want the upload batch to fail due to the existence of unspecified blacklisted links. I'd support an exception to the blacklist, but the blacklisted links need to be recorded so we can then fix them (as obviously the existence of blacklisted links prevents subsequent editors saving the description page). Nick (talk) 15:58, 12 February 2017 (UTC)
- Just in case the task is not all that clear, in the example, we want to allow uploads and text from finds.org.uk, and when that text includes blacklisted links we want to allow them; this does not mean we want to whitelist the links so we do not add them to the spam-whitelist. E.g. there are bit.ly links in the example, bit.ly should remain blacklisted, but when the upload is part of an agreed batch upload, we want to make an exception. It's surprisingly hard to put this in a pithy way. --Fæ (talk) 14:00, 12 February 2017 (UTC)
- @Nick and Reguyla: Unfortunately Phab:T157897 is being actively parked, meaning it will never realistically happen. It looks as though we might need to run a full scale RFC to allow non-programmers to be able to by-pass the blacklist for approved upload projects and in the meantime this will require special parsing of uploads to expand any possible mention of a URL that might hit the blacklist (or more likely, just drop everything that looks like a URL). I encourage more views on the Phabricator task, as technical RFCs on Commons usually attract very little attention from the general community. --Fæ (talk) 12:38, 14 February 2017 (UTC)
- Thinking outloud, but I think there's a few ways to work round this Fæ.
- Where blacklisted links aren't expected in bulk, batch uploads could be undertaken in some form of a two stage process - first the image descriptions scraped, external links extracted from that data, checked against the spam blacklists, a list of files with problematic URLs generated and manually rectified - either remove the URL or replace with an appropriate substitute. The upload proceeds in the meantime with the URL removed.
- URL shorteners could probably be dealt with automatically in some form, so the bit.ly type link replaced with the full URL during the upload process. If the bit.ly URL is masking a blacklisted link, then go to back to my first option - record the data, strip out the URL from the description and upload.
- Just some thoughts, the exact sequence and process would need to be fine tuned, but hopefully something could be done to solve this if we're not going to get a spam blacklist bypass feature of some description for bulk uploads. Nick (talk) 12:52, 14 February 2017 (UTC)
- There are lots of possible technical solutions. The issue is that this is currently a burden on volunteers rather than built into the system. There is nothing to stop the WMF funding improvement to the blacklist process, so that 'shortners' are automatically expanded, then re-checked against the blacklist. The uploader/tool user would not have to write special adapting scripts just to compensate for the blacklist.
- As mentioned in the task, the objective is to ensure that untrained volunteers and GLAM professionals can support Commons with mass uploads, not just programmers and tool-maintainers. I had thought this had become a WMF strategic objective, if someone knows of a relevant link that might be useful to justify the task. --Fæ (talk) 12:58, 14 February 2017 (UTC)
- The problem with automatically expanding and substituting the underlying full URL is, looking at the example given File:Marcha_das_Mulheres_Negras_(23137414611).jpg the bit.ly URL expands to http://www.marchadasmulheresnegras.com/#/!manifesto/c15t1 bit.ly URLs (and others) linking to inactive hosting holding pages. I'm sure others go to 404s and yet more go to defunct domains. I don't know what the options are there, really, though, given we don't really care whether full links added to descriptions are live or not, but it does seem wasteful trying to fetch the underlying full URL only for it to be potentially useless. Thoughts ? Nick (talk) 13:05, 14 February 2017 (UTC)
- I disagree, a fully qualified url clearly states where it is at the time of its creation, and gives better hope of finding successor sites. Urls shorteners will die and have no evidence on site. Dead urls we manage and understand and can be updated, we have no control over a url shortener. I would always prefer a full dea url than a dead url shortener. — billinghurst sDrewth 13:19, 14 February 2017 (UTC)
- Thinking further about this - I'd agree with having a full dead URL is better than a dead URL shortener, and perhaps 404s and dead sites could automatically be linked to relevant Internet Archive copies of the URL. I'd be interested to know how many uploads with dead URLs we've got going, and if the dead URL was simply duplicating the image data/description which accompanies the image being uploaded from its current location, or if it's different and additional information. Nick (talk) 13:38, 14 February 2017 (UTC)
- Yes, I think it is clear that we do not want these shortened URLs, and would even prefer to see the dead one (until editors decide to remove it). So if shortened URLs are the main thing the blacklist is pinging you on, then please try to catch & deal with them. If you have other examples, I'd be interested to see what you think should be allowed through. --99of9 (talk) 22:58, 14 February 2017 (UTC)
- Thinking further about this - I'd agree with having a full dead URL is better than a dead URL shortener, and perhaps 404s and dead sites could automatically be linked to relevant Internet Archive copies of the URL. I'd be interested to know how many uploads with dead URLs we've got going, and if the dead URL was simply duplicating the image data/description which accompanies the image being uploaded from its current location, or if it's different and additional information. Nick (talk) 13:38, 14 February 2017 (UTC)
- I disagree, a fully qualified url clearly states where it is at the time of its creation, and gives better hope of finding successor sites. Urls shorteners will die and have no evidence on site. Dead urls we manage and understand and can be updated, we have no control over a url shortener. I would always prefer a full dea url than a dead url shortener. — billinghurst sDrewth 13:19, 14 February 2017 (UTC)
- The problem with automatically expanding and substituting the underlying full URL is, looking at the example given File:Marcha_das_Mulheres_Negras_(23137414611).jpg the bit.ly URL expands to http://www.marchadasmulheresnegras.com/#/!manifesto/c15t1 bit.ly URLs (and others) linking to inactive hosting holding pages. I'm sure others go to 404s and yet more go to defunct domains. I don't know what the options are there, really, though, given we don't really care whether full links added to descriptions are live or not, but it does seem wasteful trying to fetch the underlying full URL only for it to be potentially useless. Thoughts ? Nick (talk) 13:05, 14 February 2017 (UTC)
- Comment this should not be a discussion just put in front of bureaucrats. This is a general discussion for the whole community, and it seems disrespectful to the community to put it away in a back-corner.
The use of url shorteners is actively discouraged by the global community. The counter argument in the ticket is that if the upload tools resolved the urls back to the base urls, prior to upload that this becomes a non-issue; it also aligns with the current practice and expectation here and through Wikimedia wikis. — billinghurst sDrewth 13:15, 14 February 2017 (UTC)
- What would you consider a suitable community consensus, a discussion on the Village Pump, or something else? It would also greatly help if you could help us out by drafting a proposal. I am in no doubt that there would be mismatches in expectations if I were to draft it, and this would probably result in any consensus being rejected downstream as unclear or misworded.
- In terms of this thread, it was created so that the "official" status of requests was agreed as being a Bureaucrat task. Implicitly it was not created by me as a way to cut out the Wikimedia Commons community by holding a discussion in a "back-corner", so could you do me the courtesy of not painting it that way? Thanks --Fæ (talk) 13:23, 14 February 2017 (UTC)
- The proposal you brought here was about getting people/bots whitelisted where a url on the blacklist is utilised. That is totally presumptive that it is okay, and your whole proposal is framed in the manner that you should be able to upload that way, let us make solution so your (collective) uploads are not inconvenienced. I dispute the foundation of that argument. Most discussions should start before the broadest likely community. — billinghurst sDrewth 10:48, 15 February 2017 (UTC)
- This section was archived on a request by: --Krd 00:31, 18 April 2017 (UTC)
Dear crats,
After a substantial amount of supporters for a desysop of Jcb expressed their opinion I went ahead and tried to prepare a DRFA but Jcb, Colin and Jee do have valid points. The case presented isn't a strong one. Either I suck at preparing a DRFA or the complaints aren't solid enough to actually warrant a desysop.
Based on the current case I would vote keep myself to be honest and since the third DRFA things have improved. On the one hand we do have people who support a desysop but on the other hand after preparing a DRFA in which I invested a lot of time I still don't have a case. Does anyone know how to proceed?
But on the bright sight. This is the first time we have a waiting period before the actual DRFA starts and it seems to have a positive effect. Natuur12 (talk) 16:23, 5 April 2017 (UTC)
- I can only add that I appreciate your closing of the discussion. I don't have an idea yet how to continue now. The last resort was to leave a note at ANU and ask other users to proceed. --Krd 16:57, 5 April 2017 (UTC)
- I do not think it would be right to proceed with a DRFA at this point. The voting is likely to be very polarised and to replicate that of the pre-discussion, with Jcb's fate perhaps depending on the votes/opinions of only one or two editors. That would show we have learned nothing.
- As you say, the 7 day delay has already had a very positive effect, allowing time for more productive ideas to come to the fore, namely that at least some of the problems here arise from our poorly-drafted policies, procedures and tags. We should use that as an opportunity to improve. Let's step away from this divisive need to have a vote, and concentrate instead on starting constructive discussions about how to improve our rules and procedures so that these perceived problems can be effectively addressed. Who would be prepared to be part of those discussions?
- Think of it this way: which helps Commons and the pursuit of open knowledge more effectively - holding yet another polarising vote, or accepting the opportunity to improve our systems? --MichaelMaggs (talk) 17:20, 5 April 2017 (UTC)
- Thank you Natuur12 for your effort in exploring a potential DRFA. I don't think you suck at it because you've laid it out fairly well and I'm very happy with the "cooling off period" because it is too easy to become angry with people we can't see. Apart from those users who are from different planets, humans react to and rely on visual cues such as facial expressions and posture but in this environment it is difficult because you don't see a face, just a username. I Support MichaelMaggs proposal that we should review our policies and guidelines so that they are clearer and more robust. A de-sysopping discussion is treating the symptom rather than the underlying cause. I for one would not have felt comfortable !voting in such a DRFA with the knowledge that it had a shaky foundation. Let's have a root and branch review and get ourselves out of this hole. Green Giant (talk) 20:42, 5 April 2017 (UTC)
- Thanks Natuur12 for bringing this here. As I commented here and here the actual problem which need immediate attention are our poorly written guidelines, templates, etc. Adding a provision to include a custom message in "no permission", "no source" and similar tags will make a big difference. So I agree with MichaelMaggs and Green Giant here. I'm not opposing Natuur12's closing decision on ANU and have no problem if he proceeds with a DRFA; but it is very unlikely to succeed now. Further, it is not helping to solve the real problems. Jee 03:55, 6 April 2017 (UTC)
DRFA for each administrators
We should have a DRFA for each administrators every 3 or 4 years.
This would have the advantage of being motivating for administrators to do a good job and to make efforts to be appreciated by the community. It would be very egalitarian between the administrators and would not give this disagreeable sensation of witch hunt where one searches for misplaced commas as arguments and as unpardonable faults. It would give a little more work to the bureaucrats, it's certain. We will undoubtedly lose up to 15 or 20% of the actual administrators who would surely not be renewed due to lack of activity and who will not succeed in convincing the community to re-elect them. The non-active (or no-helpfull) ones will not miss us anyway, because if they are not really active or usefull, and the no-active ones but who are helpfull because they have specific areas of expertise will have no difficulty in keeping their status.
The community will chose who they want to keep or not as administrators. Some will be forced to make efforts ...:) (Note that I am not targeting anyone in particular).
The other advantage is that the issue in the kind of above will be automaticly resolved, and that is a very egalitarian idea. This does not prevent of DRAF in severe cases.
I ask nothing particular to bureaucrats and I don't expect any particular answer, therefore do not take into account what I have written if it is not helpull to you. Sorry for inconvenience. Christian Ferrer (talk) 17:47, 5 April 2017 (UTC)
- Support Reconfirmation RFAs have been discussed in the past. There was a system encouraged on the English Wikipedia (now redundant I think) that administrators who were signed up for it, were committed to running a re-confirmation vote on request by any other user, or resign their tools if they refused. I'm aware of it as I was one of the low numbers of admins that did commit to it. Doing it on-demand, perhaps no more than one every 2 years for any individual, would mean that administrators would feel more accountable and being asked to run a RRFA can be created on a no-fault basis. On-demand also means it becomes less burdensome than everyone having to vote on lots of RRFAs just for bureaucratic reasons. In the case of Jcb for example, we would have avoided all the lengthy pre-DRFA discussions and extra vote, a vote that has now been ignored by bureaucrats on uncertain grounds of convenience and directly against the stated consensus agreed policy of COM:Administrators. --Fæ (talk) 18:01, 5 April 2017 (UTC)
- If opening desysop votes becomes impossible, this will be the only option. Nemo 19:52, 5 April 2017 (UTC)
- Comment: @Christian Ferrer and Fæ: would we keep the 6-monthly inactivity runs? I agree with the basic premise of an on-demand RRFA but disagree with how it was implemented on Wikipedia because it seemed to be like a millstone hanging around the admins neck, however voluntarily they accepted it. I would fully support having such a system but with checks and balances to ensure robustness but also to prevent possible abuses. For example, we cannot force all active users to !vote but we need a strategy to encourage greater participation to avoid it becoming a battleground between small groups of users. As noted above by Michael, there is a danger of DRFA's hinging on the !votes of one or two users. What could be done to involve more users in such processes on a long-term basis? Green Giant (talk) 20:42, 5 April 2017 (UTC)
- Yes, an on-demand RRFA would be a rare event. Out of our 240 admins, hardly any are considered controversial, so hardly any would have a RRFA in a given year. For this reason the RRFA is not a replacement for the inactivity run, where admins that nobody would ever complain about will have their mop put in storage, and returned if they ever become active again. I agree about avoiding a situation where odd or excessively ranty RRFA lurkers have too much weight in voting, but there's no harm in always flagging an RRFA on the Village Pump. As a rare event, each time with at least some element of controversy, it should attract enough people to be meaningful. By the way, failing an RRFA, has no particular implication on when a past admin might run a new RFA. Even a couple of months without the mop might be enough to restore community confidence, depending on whether the applicant can recognize there were issues. --Fæ (talk) 20:53, 5 April 2017 (UTC)
- @Green Giant: "would we keep the 6-monthly inactivity runs?" Yes that's independant. Regarding the "on-demand RRFA" or a kind of DRFA, of what we lack currently is a precisely defined processes on how to, and especially unquestionable rules or at least not subject to interpretation (in the kind of "some community consensus"). Several steps may be required to avoid that the first dispute lead to a DRFA or to a on-demand RRFA. For exemple 3 steps : 1step/ 7 autoconfirmed users with at least 100 live edits each, signs (not a vote) to claim a confirmation of an administrator 2step/ the confirmation (a vote but not yet a DRFA) with at least 10votes on a side or on another, the majority wins, and if there is not a total of 10 votes in at least on of the side, then the confirmation is dropped/closed 3step/ if the result of the confirmation is against the administrator, then a DRFA with the actual system is scheduled for 2 weeks later. This leaves the administrator time to prepare.
Of course this is just an exemple. And the modalities on how access to this "on-demand RRFA" have to be discussed and defined, as well as if it have to have several steps or not as in my exemple above, but I think that several steps can prevent from potential abuse.
Me I like very much, in addition to that and to our current system, the idea of something non-perpetual. With the 3 steps described just above, the advantage is the community have the power to get started the process as just 7 autoconfirmed users are sufficient, and this confirmation (a vote but not yet a DRFA) can also be the thing which is set up automatically every three years. Every three years, each administrators will need at least 10 supports (and the majority) to keep the tools.Christian Ferrer (talk) 05:08, 6 April 2017 (UTC)
- @Green Giant: "would we keep the 6-monthly inactivity runs?" Yes that's independant. Regarding the "on-demand RRFA" or a kind of DRFA, of what we lack currently is a precisely defined processes on how to, and especially unquestionable rules or at least not subject to interpretation (in the kind of "some community consensus"). Several steps may be required to avoid that the first dispute lead to a DRFA or to a on-demand RRFA. For exemple 3 steps : 1step/ 7 autoconfirmed users with at least 100 live edits each, signs (not a vote) to claim a confirmation of an administrator 2step/ the confirmation (a vote but not yet a DRFA) with at least 10votes on a side or on another, the majority wins, and if there is not a total of 10 votes in at least on of the side, then the confirmation is dropped/closed 3step/ if the result of the confirmation is against the administrator, then a DRFA with the actual system is scheduled for 2 weeks later. This leaves the administrator time to prepare.
- Yes, an on-demand RRFA would be a rare event. Out of our 240 admins, hardly any are considered controversial, so hardly any would have a RRFA in a given year. For this reason the RRFA is not a replacement for the inactivity run, where admins that nobody would ever complain about will have their mop put in storage, and returned if they ever become active again. I agree about avoiding a situation where odd or excessively ranty RRFA lurkers have too much weight in voting, but there's no harm in always flagging an RRFA on the Village Pump. As a rare event, each time with at least some element of controversy, it should attract enough people to be meaningful. By the way, failing an RRFA, has no particular implication on when a past admin might run a new RFA. Even a couple of months without the mop might be enough to restore community confidence, depending on whether the applicant can recognize there were issues. --Fæ (talk) 20:53, 5 April 2017 (UTC)
- Comment It is good to have a reconfirmation to ensure that those admins have continued community support. But does our admins have community support in the first place? Unlike Wikipedia, here I see not much community members outside the administrative team participate in any RfA. We need to give more visibility to the RfA page by site note, VP post, or something else. I'm watching Commons:Administrators/Requests; but still I missed to notice many new RfAs. Jee 04:03, 6 April 2017 (UTC)
- +1 with a busy watchlist, it's very easy to miss a Rfa Christian Ferrer (talk) 05:08, 6 April 2017 (UTC)
Before we start to find solutions, could anybody please summarize the actual problem which was the reason for all the new discussion here? I'd say the actual issue is that a lot of people want desysop of a person without being able to gather enough facts to support a desysop request. I don't actually see why we again try to setup a full scale set of the rules and procedures for a simple issue.
A desysop request can be started if there are a reasonable group of users in support of it. This has been the outcome of the prediscussion close the Natuur. Anybody is now free to file the actual desysop request. Is anything else really needed? --Krd 05:24, 6 April 2017 (UTC)
- As Natuur commented when he opened this discussion, "Either [he] suck at preparing a DRFA or the complaints aren't solid enough to actually warrant a desysop." 1. That ANU thread was opened by Yann contesting the opening of a DR/speedy by Jcb. But the end, the file get deleted. 2. Then many people raised an argument that Jcb delete files tagged by someone else or by him with "no permission" without a "reasonable reason in deletion log. The problem is with the template; it has no provision to mention why the tagger think that file needs a permission. So the uploader failed to contest the argument and the acting admin is forced to make wild guesses on why he needs to delete/keep that file. This is one example pointed out by Revent; and Jcb later commented in ANU that he deleted it "because based on Google translate, the uploader seems to be one of the depicted people rather than the photographer." The file was tagged with "no source" by someone else. These are issues of those ("no source", "no permission") templates; not of an acting user (tagger or admin). 3. The another complaint is Jcb refused to undelete files when questioned and asked to request at Commons:Undeletion_requests. It is exactly the procedure mentioned under "Appealing a deletion". A user can contact the deleting admin for explanation; but there is no meaning in forcing him to reverse his action as the next step is always one step ahead. I too failed to see any "complaints solid enough to actually warrant a desysop".
- So many of the votes came from the general disagreement with Jcb; I think. Our de-admin policy doesn't allow it for such reasons. So a "general appreciation or not" can only be possible to evaluate in a fresh RfA or a "re-confirmation after x-years" as Christian proposed above. Jee 06:26, 6 April 2017 (UTC)
- Exaggerated at most: Jcb is a that bad admin that we need to have reelections for all 232 other admins in order to get rid of him. Is that the point? --Krd 06:34, 6 April 2017 (UTC)
- The point is that which arguments are convincing is different for different users. For you they are not convincing, for me even a fraction of them were convincing already half a year ago. If nobody is convinced except for me the desysop is certainly going to fail. The problem is that a handful of power users do not want the desysop discussion open does not matter what.--Ymblanter (talk) 06:41, 6 April 2017 (UTC)
- I wish if we've something like this. :) Jee 06:56, 6 April 2017 (UTC)
- Exaggerated at most: Jcb is a that bad admin that we need to have reelections for all 232 other admins in order to get rid of him. Is that the point? --Krd 06:34, 6 April 2017 (UTC)
- Ymblanter, if they are no arguments that are convincing for the majority, we will be going to change the rules so that arguments no longer matter, or we change the audience to create a different majority? That cannot be true. --Krd 07:05, 6 April 2017 (UTC)
- Well, the only way to see whether the arguments are convincing for the majority is to hold a vote. If there are canvassing concerns, the votes of sleepers can easily be removed by the crats.--Ymblanter (talk) 08:40, 6 April 2017 (UTC)
- Ymblanter, if they are no arguments that are convincing for the majority, we will be going to change the rules so that arguments no longer matter, or we change the audience to create a different majority? That cannot be true. --Krd 07:05, 6 April 2017 (UTC)
- The suggested re-election process would be a over bureaucratization. Such re-confirmations are wasting community time and are unnecessary in any regard. We have tons[sic.] of backlogs and tons of work to do so we shouldn't wast our time with time-wasting confirmation RFA's. Enough time has been wasted yet with unnecessary and avoidable drama. And no, such a system won't solve any problems but create tons of new drama. --Steinsplitter (talk) 07:03, 6 April 2017 (UTC)
- @Jkadavoor: This is getting off topic, but I think it's worth addressing this point somewhere. You're right that the no source/license/permission templates don't have a field for an explanation, and maybe they should, but when an admin hits the 'trash can' do delete such a file we get the normal deletion screen, with a prefilled 'no whatever since date', and we have the opportunity to change it to explain if it's not grossly obvious. You say that the result is "the acting admin is forced to make wild guesses on why he needs to delete/keep that file". That's not really right... if the case is not clear to the acting admin, they should convert the speedy to a DR. The reason for deletion in such cases is 'no license/permission/source', not 'someone tagged this a week ago and nobody removed it'... if that was the case, we could simply make an adminbot to process such speedies and save a lot of effort.
- To bring this back to the subject of Jcb, when I look the most recent section of his deletion log here is what I see..
- At 23:53, 2017 April 5, Jcb deleted 9 files as 'Missing license as of 29 March 2017' using VFC.
- At 23:55, 2017 April 5, Jcb deleted 13 files as 'Missing source as of 29 March 2017' using VFC, then deleted the empty day category.
- From 23:57-23:58, 2017 April 5, Jcb deleted 79 speedies from Davey2010, at uploader request (apparently inadvertent uploads from Flickr), 43 with VFC, and then another 36 'manually'.
- At 23:59, 2017 April 5, Jcb deleted 4 categories, for various reasons.
- From 00:01-00:03, 2017 April 5, Jcb deleted 179 files as 'Missing permission as of 29 March 2017', using VFC.
- From 00:03-00:06, 2017 April 5, Jcb deleted 139 files while closing a DR.
- At 00:07, 2017 April 5, Jcb deleted 3 files, while closing 2 DRs.
- Also at 00:07, 2017 April 5, Jcb deleted 2 more files as 'No permission since 29 March 2017', manually, presumably to empty the category, which he deleted a minute later.
- Operating at such a rate, it seems quite hard to believe that Jcb is even looking at the file pages, much less evaluating if the deletion is correct. This rate is not atypical, the night before he deleted 174 files as 'no license', 'no source', and 'no permission' in less than 4 minutes, while apparently running VFC on all three categories at the same time, and again did so at exactly the stroke of midnight.
- This is after, several days ago at AN/U, he claimed to not understand why I was referring to 'no source/license/permission' deletions as speedies, and then did not respond when I made it clear they obviously are. Honestly, I think he is consistently processing such files, and has been for months at least, exactly as such an adminbot would. - Reventtalk 08:40, 6 April 2017 (UTC)
- To bring this back to the subject of Jcb, when I look the most recent section of his deletion log here is what I see..
- Yes, you are pointing exactly where is the issue. I never use VFC to delete files tagged with "no source/license/permission" templates. In many cases, these files should not be deleted: the uploader fixed the issue, but didn't remove the warning, the tagging was wrong in the first place, etc. Regards, Yann (talk) 09:12, 6 April 2017 (UTC)
- Thanks Revent; this is the first time I'm seeing an actual complaint and explanation on how Jcb is wrong. I had asked him (yes; I'm using it gender neutral in our (India) standards) to stop using such tools. I wish to make a few steps to improve the situation. 1. Make a DR and check whether Template:OTRS pending can be depreciated as now we have automated response with ticket number. Template:OTRS received with reason=1/processing is much effective. 2. Make edit requests for Template:No permission since and Template:No source since to add a provision for custom message explaining why the OP feel more information (permission or source) required. 3. I already requested to simplify the OTRS instructions. After these steps are completed, and we still have a problem with Jcb, I will be the first to ask to remove his sysop rights. Jee 11:47, 6 April 2017 (UTC)
- I think the deleting function of VPC for categories should be disabled, since it seems to only encourage admins to be lazy and mass delete files without looking them. Mass deleting files of a specific uploader using VFC is fine for me, but we also have Special:Nuke, which is faster than VFC. ★ Poké95 12:01, 6 April 2017 (UTC)
To get constructive again: As we heard here from different people that there are no sufficient argument at the current time to file a reasonable desysop request against Jcb (which is the original topic here), can we conclude that the discussion should be closed and no de-sysop request should be opened, and that general discussions and proposals should be redirected to the matching venue? (To be clear: I'm good to go with either alternative, you are still free to open the request if that solves whatever issue, but there is nothing productive in looking for the most complex solution of a likely different (if at all) problem.) --Krd 07:11, 6 April 2017 (UTC)
- +1. And I've no problem if Ymblanter or someone else wish to create a DRFA against Jcb. The topic opened by Christian is a bit off-topic here. He can open a discussion at COM:VPP. Jee 07:19, 6 April 2017 (UTC)
- Krd, There are unresolved issues with Jcb, and Jcb has made no measurable change or reliable commitment to change their behaviour. If nobody else creates a DRFA, then I will create a simple one next week to ensure the community has their vote (bizarrely a vote which we have already voted to have) and if Jcb retains their mop, then at least they are considered exonerated - I've had more urgent things to deal with this week. I would much prefer it if @Revent: were to create a DRFA now, as they have some excellent evidence above that Jcb is not listening and has made no change. Any outside observer seeing the long running AN complaints, years worth of unhappy new contributors on their user talk page being treated dismissively, and the history of re-RFA de-RFA with associated broken promises, will agree that this is one of our most problematic administrators and is likely to remain so whatever bureaucracy we make up, or however much we bend to the loudest shouting voices.
- Hm, re-reading I'll qualify tone a bit. I may be frustrated, but I am not angry at Jcb, there's nothing personal about this and I want to express this negative viewpoint respectfully. If we met at a live event I would be happy to chat about Commons issues over a cup of tea. If Jcb does drop the mop, I'm comfortable that they get it back in the future, so long as they show measurable improvement. BTW, a tiny reminder to everyone that Jcb has no gender identified on their account, they probably don't care because they are so open about their name, but it's easy to write in a gender neutral style, I always do and nobody notices. Thanks --Fæ (talk) 10:36, 6 April 2017 (UTC)
- Based on Revent's warning for Jcb today, I'll defer a DRFA. If Jcb ends up getting blocked however, we'll need one. --Fæ (talk) 13:47, 6 April 2017 (UTC)
- Firstly, the vote at AN/U was slightly against having an DRFA (13 against, 11 for). That cannot be interpreted as "consensus" for a DRFA at this point. Even if we ignore the precise counts, and go by what was said, the most accurate conclusion is that the community is totally and equally divided over the issue, and have very little common ground expressed in the arguments made. I think the 'crats are right to say we should pause and consider other options at this point.
- Secondly, I think the approach taken by @Revent: above is better than the one taken by Natuur12 in the draft DRFA which focused on too many things and not well enough on any one. So let's pick this issue with these 'no source/license/permission' deletions. Rather than launch into an DRFA with it, could we have some other discussion at an appropriate forum. One where perhaps our 'crats/admins lead the community in finding a solution rather than a beheading. Because a DRFA sets up only two options: retain as Admin or remove as Admin, and it encourages people to vote rather than discuss. As I have mentioned several times, and others are noting too, there are issues surrounding these deletions with our policy, procedures, best practice, and with those uploading / transferring the images. That Jcb feels able to make these deletion decisions in this manner, seems to me to suggest that there's nothing documenting how admins should properly go about it. So we just get a vague complaint, rather than pointing at some documented page and saying "Do it like this please, and if you don't then we'll remove the bit". The KLLC image deletion that many people felt was a good example of Jcb getting it wrong, actually turned out to reflect equally badly on Fastily, who when transferring a perfectly well documented image on Wikipedia to Commons, made such a botched job of it that he put it in jeopardy, and then couldn't be bothered to fix it when notified on his talk page, but then happy to use this against Jcb at AN/U. This to me seems very common when I examine the various issues Natuur12 listed, that there is more than one person who needs to up their game. If we had such a discussion, it would not only improve our policies and practices, but would improve the game of many users not just Jcb, and if after doing this Jcb is still making too many problem deletions, a DRFA would be justified on that topic alone. -- Colin (talk) 11:04, 6 April 2017 (UTC)
- I don't think raising an De-adminship over a single issue or action is the way to go here. On and on there have been different issues with actions Jcb took. What a lot of these issues have in common is the way in which Jcb handles disagreement and refuses to accept his mistakes and fix them. The not taking responsibility and accepting accountability of mistakes is the red line through the several issues. It is not a problem to make mistakes, it is a problem when one does not fix the mistakes made. Working towards a solution when somebody raises questions about your actions is needed, not defendings ones incorrect actions at all costs. Blocking editors where one is involved with and deleting images you tagged for deletion yourself are actions I would not accept of any admin. Basvb (talk) 18:36, 6 April 2017 (UTC)
- Basvb, we already have policy (I think) against blocking when involved, though judging "involved" can be complicated. If you feel that "deleting images you tagged for deletion yourself" is unacceptable in any admin, then find a way of making that policy. It then becomes trivial to say "XYZ has broken our clear poicy on ABC nnn times .. diffs.. ". Similarly the VFC should not permit users to (easily) make deletions that people find unacceptable. These things are so obvious and relatively straightforward to fix without drama, that it makes me question fully the motive of those who fail to fix the problem. If you have a roll of Sellotape, and keep losing the end when trying to wrap parcels, do you swear at it and throw it across the room, do you chuck it in the bin, or do you buy a tape dispenser to put it in? -- Colin (talk) 19:07, 6 April 2017 (UTC)
- If these things are so "obvious and straightforward" why can't we assume from our admins to operate accordingly? I'm all for improving policy, but from my past experience with proposing improvements to policy (on another wiki) I know that is never an easy thing to accomplish. On a side note: I'm not sure whether you're questioning my motives or those of others but I don't think such a statement is constructive. We are all able to improve policy and as such a failure to do something is a failure of all of us. As for the tape metaphor: I'd either fold the end or calmly search for it the next time. Getting mad over futile things is not my style. Basvb (talk) 19:48, 6 April 2017 (UTC)
- Basvb I don't actually know you from Adam, so don't take my comments personally. I suggest you take your "I'm all for improving policy" attitude, and remember this is a wiki, and just go for it.. You can ping me with your change-request and I'll wholeheartedly support. In fact, I'm not sure why you'd get any disenting voices. This is a win-win: you get a documentent reason to vote oppose at any future DRFA against Jcb, and you get a policy preventing any other admins doing silly things. -- Colin (talk) 20:31, 6 April 2017 (UTC)
- Basvb, we already have policy (I think) against blocking when involved, though judging "involved" can be complicated. If you feel that "deleting images you tagged for deletion yourself" is unacceptable in any admin, then find a way of making that policy. It then becomes trivial to say "XYZ has broken our clear poicy on ABC nnn times .. diffs.. ". Similarly the VFC should not permit users to (easily) make deletions that people find unacceptable. These things are so obvious and relatively straightforward to fix without drama, that it makes me question fully the motive of those who fail to fix the problem. If you have a roll of Sellotape, and keep losing the end when trying to wrap parcels, do you swear at it and throw it across the room, do you chuck it in the bin, or do you buy a tape dispenser to put it in? -- Colin (talk) 19:07, 6 April 2017 (UTC)
- See this proposal. Jee 04:58, 7 April 2017 (UTC)
- and this proposal. MichaelMaggs (talk) 15:02, 20 April 2017 (UTC)
- This section was archived on a request by: --Krd 07:03, 25 April 2017 (UTC)
Translation administrator rights for Samuele2002
Hi, I request "translation admin" permissions. I am translation admin on Meta Wikispecies Wikidata Wikimania2017 and test.wikipedia and I have preparing various page on Commons for the translation. I know how to prepare a page for translation. Thanks and regards --Samuele2002 (talk) 18:39, 18 April 2017 (UTC)
- Done, sorry for the delay. --Krd 07:03, 25 April 2017 (UTC)
- This section was archived on a request by: --Krd 07:03, 25 April 2017 (UTC)
Proposal to amend blocking policy
Dear fellow crats, the discussion at Commons:Village pump/Proposals#Oversight bans has been running for over three weeks, and seems to have reached its natural conclusion. Could I ask someone to close it, please? I would prefer not to do so myself, as that might mean closing in favour of my own proposal to amend blocking policy. MichaelMaggs (talk) 14:46, 19 April 2017 (UTC)
- @MichaelMaggs: Thank you, BTW, for taking the initiative on writing an actual 'policy' based on the discussion... - Reventtalk 15:07, 19 April 2017 (UTC)
As no crat has stepped forward, I've asked an admin to do it. --MichaelMaggs (talk) 08:32, 26 April 2017 (UTC)
- This section was archived on a request by: --Krd 08:57, 8 May 2017 (UTC)
Can a crat please close this. I've had to look at this sad result for 8 days now. Daphne Lantier 05:53, 13 May 2017 (UTC)
- Done --EugeneZelenko (talk) 14:26, 13 May 2017 (UTC)
- @EugeneZelenko: Thank you Eugene. As the nominator, I felt bad for Jeff when the opposes started piling up. It's good to have that ordeal over. Daphne Lantier 23:24, 13 May 2017 (UTC)
- I am also sad that I have to oppose his RfA. I hope I can see him sometime again in a new, fresh RfA. ★ Poké95 04:38, 14 May 2017 (UTC)
- @EugeneZelenko: Thank you Eugene. As the nominator, I felt bad for Jeff when the opposes started piling up. It's good to have that ordeal over. Daphne Lantier 23:24, 13 May 2017 (UTC)
- This section was archived on a request by: ★ Poké95 04:38, 14 May 2017 (UTC)
Proposal on de-adminship for cause
Dear fellow crats, I've made a proposal to amend our de-adminship policy: Commons:Village pump/Proposals#Proposal on de-adminship for cause. You might like to have a look as it suggests involving the wider crat team, not just a single crat, in the closing of such discussions. MichaelMaggs (talk) 13:39, 19 April 2017 (UTC)
- This section was archived on a request by: --Krd 15:19, 21 May 2017 (UTC)
GWToolset right
Hello !
I'm a volunteer on Phabricator phab:p/Framawiki and I answer many requests about system administration tasks to be performed on Wikimedia Foundation hosted wikis. Among them phab:T166271-likes need Commons:GWToolset users right to be tested.
Is it possible to receive this right ? Thanks ! --Framawiki (please notify) (talk) 18:52, 5 June 2017 (UTC)
- Done --Krd 12:14, 7 June 2017 (UTC)
- This section was archived on a request by: --Krd 12:14, 7 June 2017 (UTC)
Withdrawn – Request for translation administrator rights
Hello! I am a registered user in TranslateWiki and currently meta translation admin. I would be glad to receive this right in commons too. I am working on Category:Museum database templates and I prefer using the <translate>-tag, so that other users are able to help translating content easily. as using LangSwitch with page editing. My problem is, like in Meta formerly, that I have always wait for a translation admin to release FuzzyBot, so I am able to add the already available translations. I hope I meet your criteria. Thanks for your time. –Plagiat (talk) 01:08, 13 June 2017 (UTC)
- Withdrawn! I don't need that! –Plagiat (talk) 20:02, 15 June 2017 (UTC)
- This section was archived on a request by: –Plagiat (talk) 20:02, 15 June 2017 (UTC)
Template editor right
Has it ever been considered to bring w:Wikipedia:Template editor to Commons? We have a number of editors like Speravir, Perhelion, and others who may not want to be admins, but who have the ability and trust to work on templates rather than placing edit requests which can be a bit slow as regards response. Daphne Lantier 03:05, 8 May 2017 (UTC)
- I generally oppose the seperation of admin tools, but if the admins we have now don't have enough time for protected edit requests, then I would support this creation of a new right. Well, the problem is, how would this be given to users? By COM:RFR, this noticeboard, or a new request page (like COM:LRR)? What is required for a user to become a template editor? Lastly, will all fully protected templates (which may only be edited by admins) will have their protection settings set to be editable by both template editors and admins only, rendering full protection for templates unnecessary? Thanks, ★ Poké95 04:42, 8 May 2017 (UTC)
- It's been on en.wiki for year or more. It's not an admin tool. It's more like ip block exemption. On en.wiki it's given to people who've shown they have the technical skills needed to edit widely used templates at w:Wikipedia:Requests for permissions/Template editor. Full protection would still be needed to prevent anyone except admins and template editors from touching sensitive templates. I ask about this because I've noticed that many edit requests are coming from people like Speravir, who could easily just do the edit himself. Template editors could also take care of requests from others. I would point out that we don't have a large number of admins with extensive technical knowledge. I would also point out that this right has only been granted to 153 editors on en.wiki. We would probably only have this right granted to 50 or less editors on Commons, and they would be well-known trusted editors. I myself don't have a technical bone in my body, but I'm curious about this and think it could be good for Commons. Daphne Lantier 07:33, 8 May 2017 (UTC)
- I strongly support the idea. --jdx Re: 08:18, 8 May 2017 (UTC)
- I generally appreciate to think solution oriented, but on the other hand, as additional solutions nearly always add complexity, I'd like to consider if any real problem exists that outweighs drawbacks of such complexity increase. Do we have a backlog at protected edits requests? How many requests are open at average? How long does the average request get delayed? --Krd 08:56, 8 May 2017 (UTC)
- Enough to be posted at COM:AN: Commons:Administrators' noticeboard#Protected edit request backlog. Usually 30+ requests is the long-term number of waiting requests, and most take a few weeks to addressed.
The main thing I noticed though was that most of the editors making these requests are trusted and experienced editors. It probably takes an editor like Speravir more time to make the request than it would for him to do the actual edit. As for the Template editor user right, I've never heard of any significant problems/abuse on en.wiki. One reason I thought about bringing this right to Commons is that editors with a lot of technical know-how aren't often interested in adminship, and so this would give them the chance to work in an area of interest without having the delete and block tools they don't want and wouldn't have much use for. I can't think of a downside to having this right on Commons. The granting of this right would use the same request and scrutiny as requests for the Image Reviewer right, and our license reviewers do a great job. Daphne Lantier 20:20, 8 May 2017 (UTC)
- Enough to be posted at COM:AN: Commons:Administrators' noticeboard#Protected edit request backlog. Usually 30+ requests is the long-term number of waiting requests, and most take a few weeks to addressed.
- First: thank you, Daphne, for trusting in my skills. :-) Second, yes, there have been edit requests I had to wait longer than I had wished, and @Krd, the maintenance category Commons protected edit requests seems not to be watched by many administrators, there is now a backlog, too. Coincedently, most of them are edit requests for templates. Another complication here on Commons is, though, the translation system with mw:Extension:Translate causing that sometimes only translation admins can do necessary edits (OT here, but I miss a distinctive location here to communicate with them). — Speravir – 22:49, 8 May 2017 (UTC)
- @Speravir: Everyone can edit a translatable page, unless it is protected. The problem is that after this a translation administrator has to mark the page for translation in order to changes be visible for other languages. And if you want to contact a translation admin, please go to Commons:Translators' noticeboard. Or leave a message e.g. on my talk page. --jdx Re: 05:18, 9 May 2017 (UTC)
- Thank you also for mentioning me. I've no objection. :-) On the other hand I've also no objection to be an admin. ;-) -- User: Perhelion 07:00, 9 May 2017 (UTC)
- I would support Perhelion for admin, he is experienced in javascript. We need people like him to keep scripts running on commons. --Steinsplitter (talk) 06:08, 14 May 2017 (UTC)
- I'd also support to push people to RfA if possible. --Krd 07:25, 9 May 2017 (UTC)
- @Krd: This looks like it may not go anywhere. I too would prefer RFAs as you say. One of the reasons I mentioned this user right as a Commons option is that I saw there are 153 editors on the English Wikipedia with the templateeditor right. That's a significant number of people. Usually they prefer to spend their time doing technical work and wouldn't be interested in adminship. RFAs don't usually pass unless the candidate shows a desire (and experience) for working in CSD/DR/vandalism/blocks/protections, etc. I don't know how many Commons editors would be interested in the templateeditor right, but I figured technically advanced crats/sysops like you, Steinsplitter, and others would have a good idea of who on Commons would be qualified for this right. But if there's no support for having the right on Commons, that's no big deal. Daphne Lantier 23:39, 13 May 2017 (UTC)
- Hmm, I think the reason why the template editor right was created in enwiki is because the standard to become an admin there is too strict IMHO (if you will see, there were RfA reforms there, don't know if it did succeed). In addition of the experience and willingness to fight the admin backlog there, you have to become experienced too in writing articles, and that makes sense there, because if an admin doesn't have experience in writing articles, they won't be able to know what is obviously a copyvio or not without a copyvio tag. That's just one of the reasons why an enwiki admin needs experience in writing articles. Here, our standards are not that strict, and I think requesting adminship to fight the edit requests backlog is good enough IMHO. Yes, we can request existing admins to change how they spend their time on each backlog, but isn't it better if we recruit willing admins instead of having our existing admins change the way they spend their time on each backlog that they are used to? I believe that the more admins, the better. ★ Poké95 04:36, 14 May 2017 (UTC)
- Yes, RFA on Wikipedia is a daunting process. The two major focuses are still content creation and AFD, both of which are no doubt a turnoff for programmers. As for RFAs here, I spoke with INeverCry before doing the RFA for Jeff, and he said he had asked about 40 or 50 people about running RFAs, and had gotten yes answers from only 15 or 20. If you think somebody here would make a good admin, chances are that INeverCry has already asked them. My basic thought on the template editor right is why not allow Commons editors with proven technical skill, like Speravir & Perhelion, edit protected templates? I can't imagine a downside. For someone who edits on the technical/programming side, the templateeditor right could serve as a way for them to do what they do best, and as a way for the community to show them their contributions are highly valued. I would think that if you can make edit requests that are implemented by an admin, it would be a good thing all around to allow that editor to just do it themself. Daphne Lantier 05:52, 14 May 2017 (UTC)
- Hmm, I think the reason why the template editor right was created in enwiki is because the standard to become an admin there is too strict IMHO (if you will see, there were RfA reforms there, don't know if it did succeed). In addition of the experience and willingness to fight the admin backlog there, you have to become experienced too in writing articles, and that makes sense there, because if an admin doesn't have experience in writing articles, they won't be able to know what is obviously a copyvio or not without a copyvio tag. That's just one of the reasons why an enwiki admin needs experience in writing articles. Here, our standards are not that strict, and I think requesting adminship to fight the edit requests backlog is good enough IMHO. Yes, we can request existing admins to change how they spend their time on each backlog, but isn't it better if we recruit willing admins instead of having our existing admins change the way they spend their time on each backlog that they are used to? I believe that the more admins, the better. ★ Poké95 04:36, 14 May 2017 (UTC)
- @Krd: This looks like it may not go anywhere. I too would prefer RFAs as you say. One of the reasons I mentioned this user right as a Commons option is that I saw there are 153 editors on the English Wikipedia with the templateeditor right. That's a significant number of people. Usually they prefer to spend their time doing technical work and wouldn't be interested in adminship. RFAs don't usually pass unless the candidate shows a desire (and experience) for working in CSD/DR/vandalism/blocks/protections, etc. I don't know how many Commons editors would be interested in the templateeditor right, but I figured technically advanced crats/sysops like you, Steinsplitter, and others would have a good idea of who on Commons would be qualified for this right. But if there's no support for having the right on Commons, that's no big deal. Daphne Lantier 23:39, 13 May 2017 (UTC)
- This section was archived on a request by: --Krd 05:47, 25 June 2017 (UTC)
Request of Translation Administrator Permission
Hi, I would like to request the translation administrator permission in Commons in order to be able to help in aspects related to the marking of pages to translate (pages in bold here) and, if there is no objection or problem, in the migration of some pages of the project to the extension system. I already have this permission in other projects and I have the necessary experience. Thanks. —Alvaro Molina (✉ - ✔) 23:07, 22 June 2017 (UTC)
- I'll just note that 1 2 3. --Zhuyifei1999 (talk) 02:35, 23 June 2017 (UTC)
- @Zhuyifei1999: If you are implying that I am doing hat collecting, I think you are wrong since the last request you indicate is over a month ago and that revision of my user page in Meta is not current; the permissions I have requested do not ask them to have them for adornment, if not to use them and that is what I have done. This request is justified and I have a sufficient level of activity to ensure that I will use it responsibly on the project. Regards. —Alvaro Molina (✉ - ✔) 05:07, 23 June 2017 (UTC)
Comment I would like to clarify a few things here: First of all I find it rather bad that some users think that the permissions I request are to adorn my user page in Meta or anything else, I ask them to help and work in areas where Other users do not pay attention or care to observe; it is true that this behavior is not acceptable in cases where the user requests the permissions and then simply does not use them or even leaves to edit in the respective wiki, however all the permissions that I currently have I tried to use and in the case that he can not do it, he simply gave them up. If we put all users in the same bag, in the end the only thing that is achieved is perhaps to lose the offers of help that could have been offered.
If the bureaucrat who solves this request closes this as favorable, I will try to use the permission properly as I have done in all the wikis where I possess it and I will continue with the activity that I have had during the last days in Commons, besides continuing to help reinforce Translations into Spanish here. Regards. —Alvaro Molina (✉ - ✔) 03:51, 26 June 2017 (UTC)
- Oppose Hat collecting. --Steinsplitter (talk) 05:53, 25 June 2017 (UTC)
- Oppose Indeed hat collecting. Natuur12 (talk) 13:07, 25 June 2017 (UTC)
- Support Even if it is hat collecting, so what? This sort of mentality is a major reason all wiki projects have problems recruting and retaining useful editors. The projects all too often shoot themselves in the foot. If someone is not being disruptive and is qualified and willing to help, let them. User:AlvaroMolina, best wishes. PumpkinSky talk 13:24, 25 June 2017 (UTC)
- Oppose hat collecting by dubious user Platonides (talk) 20:29, 25 June 2017 (UTC)
NeutralI thought about this for 2 days, and it seems I can't support this request. Sure, this user can be trusted, since they have the same right at meta, they are a bureaucrat in a Spanish wiki, and also, they have a lot of rights across wikis and it seems they can use all of them responsibly, that's why I didn't opposed. But everyone has a limit too, so that's why I didn't supported too. --★Poyekhali 23:44, 25 June 2017 (UTC)- Support, user has experience with translate extension and the Commons translation effort can always do with more activity. With Spanish language being quite low progress-wise (~30%) and a large number of strings waiting on review (some of my own work too), it would be of assistance to have another native/extension experienced user onboard. seb26 (talk) 00:32, 26 June 2017 (UTC)
- Support Changed to support after I knew that the completion of the Spanish language in this wiki is about 30% and erased my doubt of the requester. I hope the requester uses the tool actively and responsibly, as they are doing in meta. --★Poyekhali 08:33, 28 June 2017 (UTC)
As there is no further comment for half a week, I'd say it's time to close this request. Per Commons:Translation administrators/Policy it has to be decided if the objections raised here are "severe objections". We have three support and three oppose comments, so sadly there's a 100% chance that any possible call will be considered wrong by half of the audience.
Anyway, although I consider the objections not unreasonable, I'm going to apply AGF and close the request as successful. --Krd 11:15, 1 July 2017 (UTC)
- This section was archived on a request by: —Alvaro Molina (✉ - ✔) 17:55, 1 July 2017 (UTC)
I was wondering
If I can get the GWtoolset. I was hoping to help Pharos upload the CC0 photos from the Metropolitan Museum of Art. {{TheMet}} is the template for Commons:Met. MechQuester (talk) 21:20, 24 June 2017 (UTC)
- Please create an account on beta. Are you in contact with Pharos, do you make sure that no dupes are uploaded? --Krd 05:58, 25 June 2017 (UTC)
- @MechQuester: ? --Krd 11:18, 1 July 2017 (UTC)
- forget what I wrote. MechQuester (talk) 11:34, 1 July 2017 (UTC)
- FYI: https://en.wikipedia.org/w/index.php?title=Special:Log/block&page=User%3AMechQuester + en:Category:Wikipedia_sockpuppets_of_Winterysteppe --XXN, 17:19, 4 July 2017 (UTC)
- This section was archived on a request by: --XXN, 17:19, 4 July 2017 (UTC)
This needs to be closed or extended. Jee 02:59, 15 August 2017 (UTC)
- Closed as remove. --Krd 07:11, 15 August 2017 (UTC)
- This section was archived on a request by: --Krd 07:11, 15 August 2017 (UTC)
Prior discussion for De-adminship
Hello, as experimented administrators within our community you may want to be aware of this, and to keep an eye on it. Regards, Christian Ferrer (talk) 18:02, 23 July 2017 (UTC)
- Thanks for the heads up. It looks like there is currently no consensus to take this further. --99of9 (talk) 01:35, 24 July 2017 (UTC)
- This section was archived on a request by: MichaelMaggs (talk) 18:20, 18 August 2017 (UTC)
Prior discussion from de-adminship (H-stt)
H-Stt's de-RfA has been created and opened by Jcb after a discussion at COM:AN/U] which has lasted for two days, and which has support for a de-RfA from just six users (though this is nearly unanimous). There is no previously established time scale for a discussion to remain open prior to a de-RfA being opened, in some cases a vote on whether or not a formal de-RfA is desired has happened, such as with Axpde but that has not happened in all cases.
I don't suppose there's any point in closing the de-RfA now it has opened (indeed, I have endorsed the remove of H-stt's tools) but it would be nice if a bureaucrat could review the proceedings, and if we could devise a proper procedure to be developed, in order that proceedings don't occur in the manner of a kangaroo court next time. Nick (talk) 22:45, 7 August 2017 (UTC)
- Checking through the discussion, there is no problem that needs fixing and the normal process has been followed. The last thing we want on Commons is the Wikipedia issue of the Super Mario effect (Signpost 2015) where administrators have extra protections to preserve their status, while at the same time newbies find excessive or arbitrary barriers to entry. The RFA process that is used for desysop requests is well managed and will provide plenty of opportunity for evidence to be reviewed and alternatives to be proposed. The pre-discussion that is required on AN can be lightweight and should stay so. The last time around the procedure was discussed there was no appetite from the community to adopt more complex processes, and there is no evidence here that H-stt will be unfairly treated in an open RFA vote and discussion.
- If there is any doubt, along the lines of a "Kangaroo court", then I suggest you post a notice on the Village Pump so that the wider community are encouraged to give opinions.
- I'm writing as someone who is not going to comment on H-stt, as I don't believe I have ever had any interaction with them and I would rather my views were formed based on experience rather than selective evidence. Thanks --Fæ (talk) 10:12, 8 August 2017 (UTC)
- I don't think there should be a vote on whether to have the actual vote. If the desysop is reasonably endorsed by a number of people, and I think 6 out of 6 is not a bad number, I'd consider the criteria "some consensus for removal" fulfilled.
- Commons:Administrators/De-adminship states that impulsive requests without prior discussion may be closed as inadmissible. This is not the case here, and I see no reason for any procedure change. --Krd 10:52, 8 August 2017 (UTC)
- This section was archived on a request by: MichaelMaggs (talk) 15:22, 19 August 2017 (UTC)
Daphne Lantier's admin rights
Hello. I just want to let you all know that I just removed Daphne Lantier's admin rights as (s)he was abusing it. You are free to re-add it when you think it's appropriate. We (stewards) leave this to local decision. Matiia (talk) 05:00, 11 August 2017 (UTC)
- Thanks. The primary discussion, including corrections needed after misuse, is at Commons:Administrators' noticeboard/User problems#Daphne Lantier has been determined to be a sock of INeverCry. --Fæ (talk) 05:02, 11 August 2017 (UTC)
I've locked CommonsDelinker after talking with a few users on IRC. If the bot can't edit, then it won't remove deleted images from hundreds of articles. Please let us know at Meta-Wiki or at #wikimedia-stewards once this get solved, so we can unlock the bot. Matiia (talk) 05:39, 11 August 2017 (UTC)
- Fixed, CommonsDelinker is back. --Steinsplitter (talk) 11:27, 11 August 2017 (UTC)
- Noting that Daphne Lantier blocked INeverCry. And Daphne Lantier was locally blocked for two hours. I have extended that block to 1 day so we have some time to think rather than be reactive to other problematic editing. — billinghurst sDrewth 05:51, 11 August 2017 (UTC)
FYI: m:Stewards' noticeboard#INeverCry/Daphne Lantier. Matiia (talk) 06:55, 11 August 2017 (UTC)
- Thanks for the pointer. I've opened a desysop request per this discussion and included INeverCry's statement in it. --AFBorchert (talk) 07:23, 11 August 2017 (UTC)
- Thanks to all who took care of minimizing the damage and cleaning up. --Krd 07:29, 11 August 2017 (UTC)
Just on a small point of technicality, given that @Daphne Lantier is now blocked and that the ongoing de-RfA shows a total loss of trust from the community, I went ahead and removed the only remaining user right, "translationadmin", from their account. If they are ever unblocked, the user will need to apply for further user rights (ie. other than "autropatrolled'), using the normal process. odder (talk) 18:16, 11 August 2017 (UTC)
- Should we think about snowballing the de-rfa? --Krd 18:23, 11 August 2017 (UTC)
- I thought about this briefly, but I don't think we should close the request just now, no. The outcome of the vote appears quite certain, but the discussion taking place is far from over, and with what appears to be an emerging consensus to ban both accounts from Commons, I think we should let the request stay open for a while and consider following on with a formal ban request once it's finished. There is also, of course, the argument of letting Daphne speak on this matter if they wish, which they can do on their talk page as their block allows it. odder (talk) 18:30, 11 August 2017 (UTC)
Daphne Lantier posted a resignation statement on their talk page. --AFBorchert (talk) 05:25, 12 August 2017 (UTC)
- After that formal resignation statement, the desysop request page should be closed and edit-protected. It does not make sense anymore to keep it open further; it just turns to be more like an "anti-INC petition" based on user' emotions. Anyway, any other decisions, if wanted, have to be taken in other places. XXN, 13:04, 13 August 2017 (UTC)
- +1. The vote and comments are unlikely to help INC, and should not sway any final decisions about any sanctions that may be taken, nor any potential improvements to policies; bad cases make bad law, as we should all recognize. Those decisions about the account block and the blocks of sock accounts, should follow standard norms, not be based on a count of emotive comments which themselves appear to have no relation to statements by INC, nor discussions that occurred off-wiki and significantly appear to have failed to include INC, or to give INC a reasonable opportunity of a few days to consider a timely resignation and a statement about their use of sockpuppet accounts, instead of this drama.
- The role of the Bureaucrat should be seen to include offering support and guidance for those in difficulty, including those that have made errors of judgement. INC made a serious error of judgement, but it would be nice to be able to read of attempts to offer INC personal guidance on how better to close down the situation they had created, in a way that may have allowed more opportunity to find a way back to being a positive contributor.
- My response is as someone who was incorrectly blocked by INC a while back, so I have direct experience of their incorrect use of sysop tools for emotive reasons. There are lessons to be learned, but only when these events can be examined in the long view. --Fæ (talk) 13:59, 13 August 2017 (UTC)
- +1. Thanks Fae for your message. Regards, Yann (talk) 14:08, 13 August 2017 (UTC)
- +1. And his last hour deletions more or less look like a self harm which need to be handled carefully. Jee 14:32, 13 August 2017 (UTC)
- I'm not going to play along with INC's game any more. There are many ways to view the vandalism spree, including the natural emotional reaction to being found out and wanting to make a scene, which does not require any internet-diagnosis of mental health issues. Lots of people do this, from children being told off then trashing their bedroom, through to adults ending an relationship in a vengeful manner. We should imo treat most of what they have said about themselves with a huge pinch of salt. While we do have to consider possible harm to INC we also have to be aware of actual harm to this community. While some are pressing for a further vote on bans and blocks, and perhaps such is required, I have to think that the best outcome for INC and the community would be a swift global ban and as little further discussion as possible. At the de-sysop, I don't see any voices clamouring for INC to be permitted to edit again, and lots of requests for such a ban, so I think the outcome of any vote would be fairly obvious, and further commentary harmful. INC may well need advice, but not from Commons, which is an educational image repository, not a medical or social help centre. We have no trainng in this matter. There are some in WMF who may have such training and perhaps they can advise. We would imo best serve them by not giving them futher opportunity to log on and read and be tempted to edit. The lessons we learn from such as INC and Russavia is that there will always be some who are willing to turn a blind eye to permit highly productive users to continue here, and overlook the many many faults, and to ignore endless sockpuppeting and lies, and it causes nothing but harm to the community. We need honest editors who are not playing games. There really should be no incentives whatsoever that editing in future will be permitted, as I think that will just encourage socking right now. INC needs to find another hobby, and there are plenty to choose from. -- Colin (talk) 08:00, 15 August 2017 (UTC)
- This section was archived on a request by: MichaelMaggs (talk) 15:20, 19 August 2017 (UTC)
Some bureaucrat please close this.--GZWDer (talk) 11:59, 18 August 2017 (UTC)
- Done --MichaelMaggs (talk) 18:25, 18 August 2017 (UTC)
- This section was archived on a request by: --Krd 07:08, 19 August 2017 (UTC)
Stewards moving files?
Hi. I'm a steward. Am I allowed to move files? Commons:File_renaming#How_to_rename_a_file.3F says that stewards can do so, which is true. It's not clear to me whether we may. m:Stewards_policy#Check_local_policies has no mention of Commons giving us the right to do anything with our rights. --MF-W 02:01, 17 August 2017 (UTC)
- @MF-Warburg: it is an admin-applicable right, and personally I would prefer that if you wish to move files that you are granted that right separately, so that it is sustained whenever you finish as a steward. — billinghurst sDrewth 04:15, 17 August 2017 (UTC)
- Still, I can inmagine that proposing renames is a pain when you cannot use the drop down menue to do so. (Listed under more, next to the edit history.) We could write like two lines of policy allowing stewards to use their file mover rights or that they can ask for the tool without having 1500 edits. Natuur12 (talk) 20:11, 18 August 2017 (UTC)
- Billinghurst already made me a member of the group. However, some gadget (probably enabled by default) already gave me a second Move tab on file pages, allowing me to request renames very easily. No pain involved. --MF-W 02:34, 20 August 2017 (UTC)
- Still, I can inmagine that proposing renames is a pain when you cannot use the drop down menue to do so. (Listed under more, next to the edit history.) We could write like two lines of policy allowing stewards to use their file mover rights or that they can ask for the tool without having 1500 edits. Natuur12 (talk) 20:11, 18 August 2017 (UTC)
- This section was archived on a request by: --Krd 09:23, 29 August 2017 (UTC)
Requesting translation administrator rights
Hi! I'd like to request temporary translation administrator rights for 1 month, in order to mark stuff for translation for the Norwegian WLM campaign. I have very extensive knowledge of the page translation features, and would prefer doing stuff myself rather than bother other people with it every time I need to do something. 😊 Jon Harald Søby (WMNO) (talk) 09:04, 29 August 2017 (UTC)
- Hi Jon Harald Søby (WMNO), OK done. --JuTa 12:35, 1 September 2017 (UTC)
- Thank you, JuTa! Jon Harald Søby (WMNO) (talk) 12:38, 1 September 2017 (UTC)
- This section was archived on a request by: --Krd 02:37, 2 September 2017 (UTC)
- Section duplicate of Commons:Administrators'_noticeboard#Fastily, removed --Zhuyifei1999 (talk) 03:20, 12 September 2017 (UTC)
- This section was archived on a request by: --Krd 09:51, 12 September 2017 (UTC)
Administrators inactivity section
Commons:Administrators/Inactivity section/Aug-Sep 2017 is still open. Please close it and remove some rights. Taivo (talk) 07:46, 24 September 2017 (UTC)
- Done by Odder today. Taivo (talk) 15:21, 30 September 2017 (UTC)
Hi, I was just de-admined because I did not sign myself as active. I see that I got a message on 19 August 2017 but I apparently overlooked it among the many notifications one gets these days. Sorry. Can a bureaucrat please restore the admin bit? I don't use it all that often but it is frequently useful to have as a complement to wp.en adminship where e.g. some article deletions also involve cleaning up copyvio uploads here. Sandstein (talk) 07:21, 1 October 2017 (UTC)
- Oppose If you don't read the messages left on your user page by other users (and you fail to make 5[sic.] admin actions in 6 months), you shouldn't be an admin. --Steinsplitter (talk) 07:36, 1 October 2017 (UTC)
- Oppose Please start a reconfirmation RFA. --Fæ (talk) 09:51, 1 October 2017 (UTC)
- Comment But at first you should show some activity here, making couple of hundreds or even thousand edits. If not, then you will fail reconfirmation RfA. Taivo (talk) 10:27, 1 October 2017 (UTC)
- Oppose The least an admin should be able to do is responding to important notices. Natuur12 (talk) 12:27, 1 October 2017 (UTC)
- Oppose - the notification was the only edit to your talk page in that entire month. How does that constitute "among the many notifications one gets these days"? I see your last 50 edits date back to October 2016. That's not sufficient to stay familiar with what's going on at Wikimedia Commons. Jcb (talk) 12:51, 1 October 2017 (UTC)
Closing this as Not done per above. --Krd 13:33, 7 October 2017 (UTC)
- This section was archived on a request by: --Krd 13:33, 7 October 2017 (UTC)
Raboe001's RFA
Hello, I noticed that in the past concerns regarding RFA's have been raised here at BN (e.g. 1) therefore i want to bring the following concerns to your attention: Concerns (1, 2, 3) regarding the !voting pattern at Commons:Administrators/Requests/Raboe001 have been raised. I herby request to extend the RFA for one week. Best --Steinsplitter (talk) 16:56, 11 November 2017 (UTC)
- @Steinsplitter: Thanks for the message. We've actually been looking into this for over a day now, and I'm quite happy closing the RfA tomorrow afternoon as scheduled, as the votes do not appear to have influenced the vote in any significant way. odder (talk) 20:51, 11 November 2017 (UTC)
- This section was archived on a request by: Steinsplitter (talk) 17:38, 12 November 2017 (UTC)
Returning bot rights for sDrewthbot
When a 'crat has a moment would they please return bot rights to user:sDrewthbot (special:userrights/sDrewthbot). They were voluntarily removed as they had not been used for a while. I have some simple repetitive tasks I wish to undertake. Thanks. — billinghurst sDrewth 10:19, 17 December 2017 (UTC)
- Done --Krd 10:42, 17 December 2017 (UTC)
- This section was archived on a request by: --Krd 10:42, 17 December 2017 (UTC)
GW Toolset permission
Hi, I'm starting new GLAM projects in Brazil, some of them are already in progress as you can see here, so I will need permissions and assistance to upload a lot of new content from these new GLAM partners. During the next year we will have access to thousands of new relevant items to upload to commons, so I would like to use the next weeks for tests and studies before the start of new projects in 2018. Best regards Rodrigo Padula (talk) 11:50, 27 December 2017 (UTC)
- Sorry for the delay. Please create an account on beta for testing. --Krd 11:28, 5 January 2018 (UTC)
- @Rodrigo Padula: ? --Krd 07:44, 15 January 2018 (UTC)
- @Krd: Hi, account created using the same username Rodrigo_Padula 177.195.58.241 12:01, 15 January 2018 (UTC)
- Please make a few test upload at beta, using the GWToolset. --Krd 12:07, 15 January 2018 (UTC)
- @Rodrigo Padula: ? --Krd 17:16, 6 February 2018 (UTC)
- Hi, I did some tests using pattypan and uploaded +600 images to commons, I'm moving to GWToolset asap, during my testes I noted that I will need OTRS permissions to add templates that use OTRS tickets inside. How can I request this kind of permission? Rodrigo Padula (talk) 17:56, 6 February 2018 (UTC)
- @Rodrigo Padula: You don't need OTRS permission to add templates that use OTRS tickets inside, except that the template condition have to match the file.
- Your test uploads at beta all contain no source information. Can you please add that and make another test? --Krd 08:22, 9 February 2018 (UTC)
- @Krd: tests completed on beta and content uploaded to commons successfully. Rodrigo Padula (talk) 22:14, 6 March 2018 (UTC)
- Hi, I did some tests using pattypan and uploaded +600 images to commons, I'm moving to GWToolset asap, during my testes I noted that I will need OTRS permissions to add templates that use OTRS tickets inside. How can I request this kind of permission? Rodrigo Padula (talk) 17:56, 6 February 2018 (UTC)
- @Rodrigo Padula: ? --Krd 17:16, 6 February 2018 (UTC)
- Please make a few test upload at beta, using the GWToolset. --Krd 12:07, 15 January 2018 (UTC)
- @Krd: Hi, account created using the same username Rodrigo_Padula 177.195.58.241 12:01, 15 January 2018 (UTC)
- @Rodrigo Padula: ? --Krd 07:44, 15 January 2018 (UTC)
- This section was archived on a request by: no response after 4 weeks --Krd 05:25, 6 March 2018 (UTC)