A couple comments inline from a technical election process (not commenting
on much of the rest not because I'm not interested but just for simplicity
right now given other work :) ).

James Alexander
Community Advocacy
Wikimedia Foundation
(415) 839-6885 x6716 @jamesofur

On Sun, May 31, 2015 at 1:57 PM, Milos Rancic <mill...@gmail.com> wrote:

> ... it would be good to talk a bit about the state of our community
> and movement.
>
> Initially, I was quite positively surprised by the fact that this will
> be the best WMF Board elections ever in the terms of turnout of
> voters. It will beat 2007 elections and it will be likely 2.5 times
> better than previous one.
>
> I would really like to know what's so different than in 2013. Also, if
> this is the sign of the community health, how come that we are now
> better than we were at the peak of our movement?
>


While I think there are probably lots of things that contributed to the
increase (and completely separating them can be difficult) I do think there
are a couple specific things that helped a lot. This was a goal Philippe
and I had for the election process very very early on (it was even one of
our annual goals) and so we've been focusing on trying to set up pieces of
it for much of the year many of which seem to have worked well. There is
still an enormous amount of things we could do better both from things that
were out of our control (timing for the start of the process and technical
issues) and things that we've learnt more about (some of the translation
work for example) but I think much of it has had some dramatic improvement.


   1. There has been an amazing group of volunteers, led by Greg Varnum as
   coordinator, on the election committee this year. It was both bigger then
   it has been in the past (many more people willing to server) and more
   active. This has allowed us to move much faster and have better
   conversations given the short time schedule at times.
   2. One of the big issues that was seen both in the last election and, to
   be honest, in previous ones was the difficulty (even for experienced
   voters) in just 'getting' to the voting process.
      - In the past you had to vote from your local wiki, so you had to
      follow a link to the meta pages, learn about the candidates, and then go
      BACK to your home wiki and go directly (by typing in the page) to the
      specific SecurePoll voting page to start the process. Of course sometimes
      that meant you were typing in a vote page that wasn't even in
the language
      or script you were used too and confused a lot of people. It also caused
      problems because basically every step you make someone go through causes
      drop off (sometimes significant).
      - This year we pushed very hard for some improvements to SecurePoll.
      Some were less visible such as an interface for creating the election (so
      it wasn't as error prone being created by a manual xml file in the past)
      and logs when messages were changed so that we knew if someone, for
      example, changed what 'name' was shown for a vote option (not that it's
      happened in the past, but in theory it could have and we had no log).
      However 1 in particular was, I think, huge: With the coming of SUL
      unification Tim Starling helped us to set it up so that we had a global
      list of voters and everyone could vote directly from Meta. This means we
      could give every single person a link, the same link, that went
directly to
      the voting system (where the committee also put brief summaries and
      pictures of each candidates along with links to their statements and
      questions). That means that, unlikely 2 years ago or previous elections,
      the banners and emails and voting boxes all linked DIRECTLY to the vote
      system rather then meta and requiring them to bounce around after that.
   3. We also spent a lot of effort this year trying to ensure that all of
   the summaries and voter information was translated into at least 17-18
   languages. There is still a lot that could be done better on this front
   (especially if we can give the committee more time then was given this
   year) but I still think it was much better overall in most cases then it
   has been in the past.

...
>
> And two more precise requests:
>
> 1) May Election committee give unified data for all previous
> elections? If possible, structured by countries and projects. Output
> of all democratic elections assume presenting data according to area.
> It's legitimate to know that voters from country X voted for candidate
> Y. It gives a clue of what's going on inside of the movement
>

I know both the committee and I definitely want to put out as much data as
possible about the results. Some of it I'm already putting together (such
as votes by project, eligible users by project, percentage voting etc) as
well as graphs and data comparing this year to 2013. Votes by country could
be tougher... in theory it could be done later on (not right away) for THIS
year but we would have to geolocate every IP that voted and I'm not 100%
sure I'm comfortable with that :-/ I would have to talk to the committee
and legal before we did that.

For better or worse we have less options available for past elections. I
have vote data (votes by project and by date) for 2013 as well as
eligibility data for most elections going back. I will definitely try to
get those together to compare against. Unfortunately country data would be
completely impossible for 2013 or before (we don't have IP data, it gets
deleted after 90 days like checkuser data) and we don't have any regular
vote data before 2013 (the elections were done on 1 time use wikis run by a
private entity, so we don't have the databases around at all). We do have
final vote numbers though and so could make some comparisons.
_______________________________________________
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Reply via email to