Commons:Administrators/Requests/Δ

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
 Support = 4;  Oppose = 2;  Neutral = 10 - 33% Result. EugeneZelenko (talk) 15:46, 16 February 2011 (UTC)[reply]
You wanted to say " Oppose = 10;  Neutral = 2", didn't you? ;) abf «Cabale!» 17:05, 16 February 2011 (UTC)[reply]

Δ

Vote

Δ (talk · contributions · deleted user contributions · recent activity · logs · block log · global contribs · CentralAuth)

Scheduled to end: 04:09, 16 February 2011 (UTC)

This is a fairly unusual Request for Adminship, basically this is a Single Purpose account, whether this is granted under my primary account or my bots I really dont care, but the main issue I have seen over the last year is that admins on en.wp often forget to protect images that are here on commons but are used on the en.wp main page. This creates a loophole that enables vandals to use commons to upload goatse images to the en.wp main page. I have written a scripts to prevent this, but I lack the user rights (+sysop) to do what needs to be done to ensure that the images stay protected. Δ 04:09, 9 February 2011 (UTC)[reply]

Votes

  •  Oppose Bots should only get sysop status if their operator is a sysop. You are far to less active to be elected admin, and by the way, you did not even read the instructions where to add a request. abf «Cabale!» 05:47, 9 February 2011 (UTC)[reply]
  •  Neutral. I did not go through your history, but I must say your username is not the best. I do understand that changing it now might be a bit difficult considering the number of accounts with that name, but if you wish to be active in wider areas and with more significant roles, I think a more simpler/understandable name would always be better. Rehman 12:59, 9 February 2011 (UTC)[reply]
  •  Weak support Because a. no one else is interested in stopping penises on the English Wikipedia's main page, and b. to get him to stop complaining at the enwp admin noticeboard every month. ←fetchcomms 22:47, 9 February 2011 (UTC)[reply]
  • Support per fetchcomms. If no one on commons wants to fix this problem then someone who is willing to do so should take the lead. Protonk (talk) 22:49, 9 February 2011 (UTC)[reply]
  • Support - Per Fetchcomms and Protonk. Mlpearc powwow 23:47, 9 February 2011 (UTC)[reply]
  •  Support - En-Wiki desperately needs this bot. The current solution of strolling along unaware and waiting for Beta to put a giant image of a fish on the Admin Noticeboard has, thus far, produced poor results. Forget the bureaucracy, just let him have his bot so we don't end up with some disgusting image where there should be a picture of a whale or an F-1 car. Night Ranger (talk) 03:22, 10 February 2011 (UTC)[reply]
  •  Oppose, let someone with the rights run the bot then. This is a collaborative project for a reason. Blurpeace 03:31, 10 February 2011 (UTC)[reply]
    • Unfortunately I have already tried that, the user is having issues with keeping the script running correctly. Im coming here out of frustration, Ive tried just about every other option I can think of. Δ 14:57, 10 February 2011 (UTC)[reply]
  •  Support Time to make this a reality. The fear of automated processes is much ado about nothing in this case. Burpelson AFB (talk) 14:32, 10 February 2011 (UTC)[reply]
  •  NO way per ABF and strongly - I don't like sysop bots and I certainly do not like them when their owner is not a sysop - sorry --Herby talk thyme 14:49, 10 February 2011 (UTC)[reply]
  •  Oppose I agree with Herby and Blurpeace on this one. I don't think it is a good idea to give +sysop to a bot whose operator does not have the tool. Regards, Pmlineditor (t · c · l) 15:53, 10 February 2011 (UTC)[reply]
  •  Oppose if en has problems, fix them on en. -Atmoz (talk) 18:18, 10 February 2011 (UTC)[reply]
  •  Neutral Neutral, for now; I have been looking at this, and I simply don't know; we need more discussion, I think. On the one hand, there is an immediate, indeed urgent problem - and an editor is offering to help solve it; I believe Δ has the best intentions of the project at heart, and does good; also, I fully trust Δ to not abuse this privilege if granted. Also, Commons is so broken it is ridiculous, in terms of admin efficiency. Getting anything done is challenging, so we should certainly not shoot a gift-horse in the mouth. On the other hand...this problem needs a clean, neat fix - not a kludge. So - I wait to see what people say here.  Chzz  ►  00:33, 11 February 2011 (UTC)[reply]
  •  Oppose, agree with comments by ABF (talk · contribs), above. -- Cirt (talk) 03:23, 11 February 2011 (UTC)[reply]
  •  Oppose per Blurpeace - someone trustworthy needs to take on this task.   — Jeff G. ツ 04:27, 11 February 2011 (UTC)[reply]
    To clarify, en:Wikipedia:Administrators' noticeboard/Δ and its archives contain plenty of information about the English Wikipedia community's mistrust of this person in general, as an administrator, and as a bot operator, and I think that information is directly relevant because this person is asking for privileges to help protect English Wikipedia.   — Jeff G. ツ 18:37, 11 February 2011 (UTC)[reply]
    bugzilla:27335 addresses this problem.   — Jeff G. ツ 19:18, 11 February 2011 (UTC)[reply]
  •  Oppose per above. --Diego Grez return fire 15:33, 11 February 2011 (UTC)[reply]
  •  Comment Opposers, can any of you think of an alternative solution? Because, this is a real issue that we need to address. I personally don't know, hence asking. Honest question. We seem to be causing unnecessary DRAMA, instead of working together, to come up with some sensible solution.  Chzz  ►  15:51, 11 February 2011 (UTC)[reply]
    I don't believe in bots with admin-flag. Would be nice if we could just allow a bot to edit protect=sysop - pages without grantig all the other stuff (ban/unban, ...). As it doesn't seem to be possible to do that, it comes down to who's operating the bot, doesn't it? --Guandalug 16:13, 11 February 2011 (UTC)[reply]
    Creating a new usergroup to solve the problem seems a little bit too much. On the other hand you seem to be perfectly qualified to run such a bot once you're an admin. --Isderion (talk) 17:38, 11 February 2011 (UTC)[reply]
    The right involved is "Change protection levels and edit protected pages (protect)" per Special:ListGroupRights. I would offer to run such a bot if I were an admin or a member of a "Protectors" group here.   — Jeff G. ツ 18:55, 11 February 2011 (UTC)[reply]
    @Isderion and Guandalug OK, so if we think it not appropriate to create a new rights group - any other ideas?
    @Jeff G. - yes, but this is the problem; you aren't a SysOp here, and can't run it. And I have not yet seen any (SysOp) come forward and offer to deal with the problem. Whereas, this user has the ability to deal with it, but not the required privileged, hence this application for it.  Chzz  ►  19:24, 11 February 2011 (UTC)[reply]
    As far as I know, creating a new user group involves some effort (getting consensus about it on commons first, probably in an "official" proposal and then ask a high up to implement it). So I think it's easier if someone with admin rights just runs the bots. But of course I am also fine with a new user group. --Isderion (talk) 20:40, 11 February 2011 (UTC)[reply]
    If there was a Commons admin available to do it, with the appropriate skills and expertise to write and run a bot, and the will to do so, then of course - that'd be fine. If not - well, at least (a 'prot' group) is one other option then. I suspect it'll be hard to get that done, but it's worth a try, I guess; it's the only other choice so-far presented.  Chzz  ►  09:37, 12 February 2011 (UTC)[reply]
  •  Oppose Granting extended rights on the Commons because en.wiki admins are forgetful "admins on en.wp often forget to protect images" or lazy/neglectful "over time admins become lax" is an absurd notion. If someone who is already a Commons admin (i.e. rights granted by virtue of knowledge and trust related to the Commons, not for reasons of administrating a sister project) wishes to implement such a bot, that may be another matter. En.wiki problems, be they poor administration or logistical (e.g. rapid, inconsistently timed main page updates), should be resolved locally. Эlcobbola talk 17:20, 11 February 2011 (UTC)[reply]
  •  Comment But, enwiki is using resources from this Wiki. We could only solve it locally if we chose to stop bothering with that, and copied everything over. Otherwise, it remains an issue - it isn't just a case of lazy admins; an enwiki SysOp cannot protect a page on Commons. And there is simply no way that enwiki is going to stick to some reigime of updating the main page only according to a certain schedule; it isn't feasible to do so; it is a very dynamic, fast-paced wiki and changes are needed constantly.  Chzz  ►  19:27, 11 February 2011 (UTC)[reply]
    • En.wiki is perfectly able to upload images temporarily, protect them while on the main page, and delete when finished. This is already common (e.g. [1] [2]). Not to do this is absolutely an issue of laziness and negligence, and solely so. If en.wiki finds that process awkward, it is the consequence of having so foolishly chosen (and, apparently, refused to change) a main page "format" which precludes local solutions. They've made the bed; they can lay in it. Эlcobbola talk 20:30, 11 February 2011 (UTC)[reply]
      • Thanks for responding; at least we're talking about ideas now. Uploading all images to the local wiki whilst they are on the main page is problematic, because a) it is a waste of resources, b) it is a kludge, and shouldn't be necessary, c) it's easy to forget and make errors - especially when an image comes from a transclusion of a template which transcludes another and so forth. It doesn't seem fair to criticise enwiki for using Commons for its intended purpose (in scope). The 'upload local' has been the hack used for some time, and clearly it is not working.  Chzz  ►  09:37, 12 February 2011 (UTC)[reply]
  •  Oppose - I think it has been agreed upon that sysop bots should have sysop operators. As for the main page images, I commonly protect them locally and I know a number of admins who do too. I just don't see a need. Tiptoety talk 23:43, 11 February 2011 (UTC)[reply]
  • Comment I can perfectly understand (and respect) the reason people are opposing, and don't want to badger; however, the need (to resolve the issue) is quite clear; many times, it would've been very easy for the enwiki main page to have been vandalised with an obscene image. They're frequently not protected in a timely manner. This is a proposed solution; no other ideas have been forthcoming, to date. I sincerely hope we do not have to wait until it happens, before acting. Best,  Chzz  ►  10:53, 15 February 2011 (UTC)[reply]

Comments

unfortunately the en.wp main page is not stable enough for that to work, images are often added right before/after things reach the main page. So the bot would not be able to protect those images. My plan is to do something very similar, but with just a single page in my userspace. Δ 22:37, 9 February 2011 (UTC)[reply]
enWP already asked me once... but as Δ said, they tend to change images too often (and not on a fixed schedule) to use the (admittedly nice, yet tricky) solution the deWP uses. There might be an alternative solution that (e.g.) changes templates more often (like, every 2 hours or something), I haven't taken a closer look on this for a while as I heard (but never crosschecked) that enWP solved the problem by 're-uploading' the images loaclly, shadowing commons, and then (upon embedding 'em in the main page) cascade-protect them. --Guandalug 22:59, 9 February 2011 (UTC)[reply]
the c-uploaded does work, if the admin in question remembers to do it. However that does not always happen. Unfortunately a two hour gap is not a feasible solution either, the en.wp main page gets about 3,500 hits a minute, any vulnerability/exploit has the probability for massive impact which I want to avoid, a two hour gap just creates too much exposure. Δ 23:08, 9 February 2011 (UTC)[reply]
Well, a bot (admin-flag on en-WP set) could do the reupload-shared as well. Admittedly, it's a massive waste of resources, which is why I opposed such an idea for deWP. And I agree 2 hours is too much... Too bad there's no cross-system cascade protectionor suchlike. --Guandalug 23:12, 9 February 2011 (UTC)[reply]
  •  Question (independent from my vote on this RfA): How often does such vandalism occur? When has this been the last time? abf «Cabale!» 18:21, 10 February 2011 (UTC)[reply]
    • it used to be very common, admins then stepped up and always ensured that images where taken care of, However over time admins become lax, and this issue crops up again. As soon as it becomes a pattern to have unprotected images in the main page, which is happening more and more frequently, vandals will become aware of it again and then exploit it again. It just has not been happening regularly enough for them to exploit it yet. Δ 18:26, 10 February 2011 (UTC)[reply]
      • I can't tell for enWP, of course, but there was a period of 2 or three days my bot did not 'protect' deWP, and we had a vandal again putting up big pics of genitals on the deWP mainpage. So yes, vandals DO know how to do that and what to look out for. --Guandalug 19:14, 10 February 2011 (UTC)[reply]
  • A bot that does this has been running under my toolserver account for a while now, see User:Krinkle/enwiki mainpage. It runs every 10 minutes and adds the images currenrtly used on the main page. Since that page is protected with cascading protection the images are protected automatically. –Krinkletalk 19:31, 11 February 2011 (UTC)[reply]
    IIRC, the cascading protection does not protect the images immediately, it has to wait for the job queue.   — Jeff G. ツ 04:35, 12 February 2011 (UTC)[reply]
Δ, you're incorrect on this one. See bugzilla:18483. Shubinator (talk) 00:41, 13 February 2011 (UTC)[reply]
That does not apply to User:Krinkle/enwiki mainpage, but rather just pages that use cascade protection and complex system of dated templates, where the link table needs purged. The system that I had coded is not susceptible to that particular known issue. Its a bug in the link tables/parsing system of un-edited pages that use a revolving system of templates, which may cause some errors with general links, and file usage. This was noted due to the lack of cascade protection, but not an effect of the job queue or the cascade protection system, but rather a bug in how pages using dated templates are parsed/have their link tables updated. Δ 01:45, 13 February 2011 (UTC)[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Administrators/Requests/Δ&oldid=61635487"