Last modified: 2013-05-15 18:15:20 UTC
Created attachment 11423 [details] Configuration for 2012 ArbCom election The 2012 ArbCom election on enwiki, which runs on SecurePoll, has already been delayed because we had difficulty getting hold of Tim Starling, who usually manages that installation. Another day rolls by and we don't seem to be having much luck emailing people. Is there any sysadmin who is happy running the config import script? The maintenance script is at /extensions/SecurePoll/cli/import.php and the needed config file is attached. One thing that does need checking is that the entity IDs don't overlap with previous ballots; I think it should be ok on the assumption that no other SecurePoll ballots have been loaded since last year's ArbCom election, which looks right. You might want to run: SELECT MAX( `en_id` ) FROM `securepoll_entity`; Which is the primary key for the table (and the table only has a few hundred rows) so will be fine to run. I'd do it on the toolserver but my account has expired. TLDR: we need a sysadmin with shell who is happy to: 1) look at the attached config file to confirm that it's not going to trojan the site (it's not, honest :D ) 2) Run the SQL query above and confirm that the result is <= 258, if not let me know and I'll update the config 3) run /extensions/SecurePoll/cli/import.php /path/to/config This is time-critical in that the time when the election was supposed to start (midnight this morning UTC) has already passed. The attached config produces an election which opens at midnight tonight; if it's not processed by then, let me know and I'll update it to start later.
Adding shell keyword.
Why has this bug's creation been left until after the election was due to start? Is this normally arranged in private with the system admins/shell users or something?
(In reply to comment #2) > Is this normally arranged in private with the system admins/shell users > or something? Yes.
(In reply to comment #2) > Why has this bug's creation been left until after the election was due to > start? Is this normally arranged in private with the system admins/shell users > or something? As I understand it, Great Sainted Jimmy didn't actually appoint the people meant to be /running/ the election until the 22nd. This sort of borked the timetable.
(In reply to comment #4) > (In reply to comment #2) > > Why has this bug's creation been left until after the election was due to > > start? Is this normally arranged in private with the system admins/shell users > > or something? > > As I understand it, Great Sainted Jimmy didn't actually appoint the people > meant to be /running/ the election until the 22nd. This sort of borked the > timetable. Olive is correct. The Commissioners were supposed to be appointed on the 17th, they were not appointed until the 22nd and did not feel comfortable acting prior to appointment. Also, no one volunteered to be a Coordinator until the 22nd, so there was literally no one's name listed on the sheet of people running the election until the 22nd.
Reseted the priority to normal: this is not a critical mission, ie nothing is broken in current wiki configuration. We noted the emergency to comply the vote calendar, but please don't create a confusion between wiki policies priorities and technical priorities. Highest priority bugs are bugs the resolution have to be imminent because they break normal operations, not facilitate a voting process.
(In reply to comment #6) > Reseted the priority to normal: this is not a critical mission, ie nothing is > broken in current wiki configuration. > > We noted the emergency to comply the vote calendar, but please don't create a > confusion between wiki policies priorities and technical priorities. Highest > priority bugs are bugs the resolution have to be imminent because they break > normal operations, not facilitate a voting process. It's not, it's a confusion between Wiki internal processes priorities and technical priorities - and I'd hope that this isn't a /confusion/. Those things which negatively impact on wiki internal processes would be considered to have a pretty high priority, *particularly* when we're talking about letting the popular mandate expire for a body that (amongst other things) gives out checkuser and oversight rights and provides monitoring for them.
I am sure it's been pointed out, but this is the end of a holiday weekend, when no one has previously notified us of the need. I'll see if I can nudge some folks, but we need more advance notice than this. I understand the internal drama with appointments, etc, but really, any heads-up would be appreciated. pb
(In reply to comment #6) > Reseted the priority to normal: this is not a critical mission, ie nothing is > broken in current wiki configuration. Priority does not necessarily have anything to do with how broken things may or may not be; that's what the importance field is for; and while this is indeed technically an 'enhancement', it is of very high priority for exactly the reasons Oliver has stated, so I've set the priority back to highest. Generally speaking, priority is merely the time table on which its completion is needed, and if even high priority bugs can be expected to take 2-4 weeks as has been discussed on wikitech-l, then a lower priority still would make little sense. (In reply to comment #8) > I am sure it's been pointed out, but this is the end of a holiday weekend, when > no one has previously notified us of the need. I'll see if I can nudge some > folks, but we need more advance notice than this. I understand the internal > drama with appointments, etc, but really, any heads-up would be appreciated. Whatever comes of it, thank you for that.
> I am sure it's been pointed out, but this is the end of a holiday weekend, when > no one has previously notified us of the need. I'll see if I can nudge some > folks, but we need more advance notice than this. I understand the internal > drama with appointments, etc, but really, any heads-up would be appreciated. > > pb My understanding is that Tim was first contacted on the 21st; my own email to Tim on the 22nd was a reply to a thread for the 2011 elections which was first sent on 23/11/11 and was resolved within 3 days. This is a process which happens in pretty much exactly the same format at the same time of year, every year, and neither Thanksgiving nor short notice has been an issue in the past. Every year the tech staff have been pretty good at providing a service that the community has come to rely on, and hence has not pressed so hard for, say, an interface for the community to configure it themselves); now suddenly that support has completely failed to materialise. Certainly there're lessons to be learnt about how this process should be put into the workflow in future, but I don't think assuming that a workflow that has worked fine for four previous years will continue to work, is unreasonable. Most importantly now, though, the continuity of a wiki institution that's almost as old as the WMF itself (and one of the most successful, for all its detractors) is suddenly thrown into turmoil by a problem which is within the skill of any of thirty WMF staff members to resolve with three lines of shell commands. I'm a strident proponent of the world not revolving around enwiki in terms of the prioritisation of sysadmin/developer resources, but this is such a small task with such a substantial impact that it seems very bizarre for it not to Just Be Done in order to get it off the todo list.(In reply to comment #8)
The 21st was the day before a holiday weekend (although Tim is in Australia, the Foundation observes US holidays). This is the first day back at work since then. We want to be helpful, and CT is actively looking for someone who can help out, but our resources are fairly booked. I think he may have found someone though. We'll be in touch.
In the configuration, NYB's username is listed as NewyorkBrad, when it really is Newyorkbrad (no CamelCase). A minor issue, but if someone wouldn't mind fixing that. Thanks.
mysql:wikiadmin@db63 [enwiki]> SELECT MAX( `en_id` ) FROM `securepoll_entity`; +----------------+ | MAX( `en_id` ) | +----------------+ | 258 | +----------------+ 1 row in set (0.02 sec)
Created attachment 11425 [details] Fixed Newyorkbrad typo
reedy@fenari:/home/wikipedia/common/php-1.21wmf4$ mwscript extensions/SecurePoll/cli/import.php --wiki=enwiki ~/arbcom-2012.xml reedy@fenari:/home/wikipedia/common/php-1.21wmf4$ sql enwiki Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 502691498 Server version: 5.1.53-wm-log (mysql-at-facebook-r3875) Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql:wikiadmin@db63 [enwiki]> SELECT MAX( `en_id` ) FROM `securepoll_entity`; +----------------+ | MAX( `en_id` ) | +----------------+ | 281 | +----------------+ 1 row in set (0.00 sec)
Seems the maintenance script doesn't give any information when stuff was all ok (see bug 42462) Is there anything else to do for this?
(In reply to comment #8) > I am sure it's been pointed out, but this is the end of a holiday weekend, when > no one has previously notified us of the need. I'll see if I can nudge some > folks, but we need more advance notice than this. I understand the internal > drama with appointments, etc, but really, any heads-up would be appreciated. No one has previously notified you of the need? This is silly. How many "site liaisons" does it take to figure out that a yearly election will be proceeding this year, as it has for years and years in a row? The English Wikipedia is the most watched wiki of all Wikimedia's wikis (and perhaps the only watched wiki by the Wikimedia Foundation...). You can't really claim, with a straight face, to be surprised about an upcoming election that happens at the same time every year. That said, I have no idea why it requires shell access to set up an on-wiki poll (still). That really ought to be addressed before next year's election.
(In reply to comment #17) > That said, I have no idea why it requires shell access to set up an on-wiki > poll (still). That really ought to be addressed before next year's election. Bug 42464
Okay, I thought I wouldn't comment to not add fuel to the fire, but.. Dear enwiki people, stop looking at your goddamn navel alreadhy. Your wiki is not that important. There won't be any death if you just start your thing a few days late. Is your wiki such a bureaucratic mess that you wouldn't let your current arbcom keep its mandate a few days longer to adapt to the situation ? Also, you expect everyone to remember when your local elections are. Seriously ? The whole thing is about something that was asked at the very last moment, which resulted from a problem on *enwiki*'s side. That no one started anything without "Jimbo appointing them". Well okay, but this was just a formality, some kind of old weird local tradition. They were already technically chosen, and if the Commissioners didn't 'dare' doing anything before that (yay bureaucracy) it's your wiki's problem, not the techs. If no one volunteered to be the Coordinator, it's not their problem either. Stop beeing so damn self-important.
(In reply to comment #19) > Dear enwiki people Not sure which people in this thread you consider "enwiki people", however we know it's not constructive. Can everybody please try to avoid running again into this situation next time? Great! Topic closed, thanks! :)
