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?

happy.melon.wiki wrote:

(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.

mattbisanz wrote:

(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.

happy.melon.wiki wrote:

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;
+----------------+

+----------------+

+----------------+
1 row in set (0.02 sec)

Created attachment 11425
Fixed Newyorkbrad typo

Attached:

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;
+----------------+

+----------------+

+----------------+
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

koneko wrote:

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! :)