This is also a story about how, using free software and inexpensive components, a small team created a complex system for collecting signatures on a nationwide scale. There are no complex technical solutions in the project, but there are many important details that cannot be foreseen based on typical IT development experience.

For convenience, the material is divided into four posts, which are best read sequentially.

This is technical material, but many of the issues discussed here are incomprehensible without a modicum of knowledge of the contemporary political context, so it is covered as necessary. If for some reason you are scared by the word “Navalny” (it will appear several more times) or the mention of democratic institutions, simply do not read this text. Political issues will not be discussed in the comments.

Campaign goal

Registration of Alexei Navalny as a presidential candidate.

Tasks assigned to the IT department

(in chronological order):

Pre-registration of everyone who is ready to sign for the nomination of our candidate;
- Ensuring the operation of a network of headquarters throughout Russia;
- Creation of a system for collecting 315 thousand ideal signatures.

Historical and political context

If you do not have a parliamentary party, then you need to collect signatures to participate in the elections. This is a protective procedure that is used to prevent “uncoordinated” candidates from participating in elections.

Endless possibilities for refusal of registration are laid down at the level of collection rules:

• The collection of signatures is strictly limited in time;
• According to the law, a small percentage of the required number of signatures is allocated for marriage; it is impossible to submit signatures with a good margin;
• It is impossible to verify signatures on our side, since voter data must correspond to the FMS database, to which only government bodies have access;
• When checking at the Central Election Commission, a graphologist can reject any signature and does not bear legal responsibility in case of an error;
• The verification scheme itself assumes that there will be a significant percentage of false positives (the paradox of Bayes' theorem as an election barrier).

We have already encountered this in Novosibirsk, when we collected signatures to participate in the elections to the Legislative Assembly.

To collect signatures in Novosibirsk, we created the Reaper system, which was focused on collecting signatures “in the field” and on cubes, managed the routes of collectors, took into account all signature sheets and made it possible to rank signatures based on the results of various checks.

Collectors in Novosibirsk brought more than 16 thousand signatures, from which we selected and submitted the best 11,722. Despite the strict selection, the working group of the election commission identified many “invalid signatures”, and the election commission refused to register the candidates. Read more about the absurd reasons for which signatures are invalidated.

The new system was built taking into account the accumulated experience in collecting signatures and their subsequent protection in the election commission.

Features of the new signature collection

Even more stringent conditions have been established for collecting signatures for nominating a presidential candidate:

No more than 315 thousand signatures are required;
- At least 300 thousand signatures must be recognized as valid;
- No more than 7,500 signatures from one region are counted;
- The short collection period (from December 27 to January 31) coincides with the long New Year holidays, when many people go on vacation.

Taking into account previous experience and new requirements, we have adopted the following basic principles.

All-Russian network of headquarters

Because of regional quotas, it was impossible to work in, say, the ten largest cities. 315 thousand signatures could be collected if at least 40 cities were covered. In sparsely populated regions, collecting signatures is more difficult, so in practice, for successful collection it was necessary to open headquarters in most regions of the country.

The forecast for the number of signatures at the time of successful completion of the collection shows that in large cities the number of people willing to sign would significantly exceed regional quotas. Moscow (127 thousand) and St. Petersburg (63 thousand) did not fit on the screen.

Collecting signatures only at headquarters

We would have to hire several thousand pickers to collect door to door. Anyone who has ever worked with paid collectors (or, for example, sociology students) knows that not all of them are equally sensitive to the procedure and not everyone overcomes the temptation to simply “draw” a signature or two. Careless filling leads to a large percentage of defects, and “drawing” signatures is such a common problem that the Central Election Commission provides for a check by a graphologist. Even the presence of a graphologist on staff and the demonstrative execution of several statements to the police cannot 100% rid the headquarters of “draftsmen” (we checked). In addition, the collector may add signatures not only out of malicious intent, but also, on the contrary, in order to “help the headquarters.”

We knew that when collecting “in the field,” we would definitely be introduced to “toxic collectors,” as was the case in Novosibirsk. Toxic collectors deliberately make mistakes in voter data (for example, they change one digit in a passport number). Their task is to increase the number of invalid signatures above the limit after which the election commission refuses registration. Novosibirsk spent a lot of effort to clean up toxic signatures. This is impossible to do when collecting throughout the country.

Only in stationary headquarters it was possible to ensure sufficient quality of signatures, conditions for accurately filling out signature sheets and their safety.

Multi-stage signature verification

Ideal signatures are a mathematical abstraction. The actual collection of signatures is a complex and difficult process. Even honest and well-trained assemblers make mistakes, and under conditions of lack of time, administrative pressure and provocations, there will be even more defects.

We have a lot of data about how errors occur. In our experience, in signature sheets collected in a completely honest manner, there will be about 10% of signatures that the election commission recognizes as invalid.

We had to submit not just good signatures, but signatures that the election commission would accept. This required several stages of verification and a ranking mechanism - in order to select and submit only those signatures that were most likely to pass the election commission's checks, no matter how absurd we may consider them.

Passport scan for each signature

Without a scan, all responsibility for the quality of the signature lies with the collector. If he accidentally or intentionally made a mistake in the passport number, we will never know.

From experience, we have found that only errors in rewriting passport data into the signature sheet and data entry errors easily exhaust the permissible 5% limit, even if signatures are collected in comfortable conditions and by conscientious collectors.

Having a scan of the document, we could carry out several independent stages of verification of the signature and make corrections.

In addition, our lawyers were preparing to fight for every signature in court. Last time there was a large category of rejected signatures, which we knew for sure: the signature corresponded to the passport, but we checked it against an outdated and error-filled database. A unified database and the availability of scans would allow lawyers to automate the process of preparing complaints in such cases.

Of course, it was possible to scan a passport only at headquarters, otherwise it would be impossible to ensure a sufficient level of security for personal data.

Synchronization with electronic database

All operations with signatures and signature sheets, all statuses and movements had to be reflected in the electronic database. The signature collection system had to monitor all stages of collection and identify errors. This is the only way we can maintain order (and peace of mind) when working with hundreds of thousands of physical objects.

What has been done in the new version of the system

• So that we have a place to collect signatures, we have deployed a network of regional headquarters. The IT infrastructure of the headquarters consists of several physical servers, a number of virtual machines, 70 routers, 230 cameras and 189 complete workstations. More than 250 people simultaneously use the system internally.
• In order to bring several hundred thousand people to the headquarters in a short collection period, we began registering voters in advance on the 20!8 website, where they pre-confirmed their data.
• To reduce the number of errors, we have created a system that allows independent verification of the correctness of filling out the subscription sheet. The system consists of several web applications and a mobile application for two platforms.
• To load data into the system, we assembled (and partially manufactured) a set of equipment for scanning passports, thought out a scheme for the secure transfer of personal data and implemented it at all headquarters.
• To ensure that the formatting of the address was correct from the point of view of the election commission, we launched a search in the FIAS database and, together with lawyers, seriously tinkered with it to take into account all the requirements of the law.
• In order to (partially) secure our headquarters and have additional arguments in the courts, we have established a 24-hour video surveillance and recording system.
• To test the infrastructure, mechanics, clarify data and prepare headquarters for collection, we conducted a large procedure for preliminary verification of voters, through which 81,750 people went through.
• We developed the appearance of the subscription sheet, a system for logistics of sheets at headquarters, as well as a system of physical storage and quick access for the central headquarters.

Core technologies of our web applications

Main backend language: Python.
Frontend: JavaScript, jQuery, React, D3.js.
Frameworks: Django (6 pcs), aiohttp (1 pc).
Database: PostgreSQL, Redis and others.
Full text search: Sphinx.
HTTP server: Nginx, Varnish.
Testing: Jenkins, Browserstack, RobotFramework, Locust.
Monitoring: Zabbix, Elasticsearch, Kibana, Sentry.
Deploy: Ansible and other tools.
Server configuration management: Chef.

Part one: Navalny 20!8 website

We had to bring several hundred thousand people to headquarters in a very limited period of time. To do this, we started registering supporters right on the day the campaign started. Recruiting and registering supporters is one of the main tasks of the Navalny 20!8 website, so there is a registration form on almost every page.

Since all this is needed not just for the sake of beautiful numbers, it was important for us to know that the registered supporters are real people, not bots, to be able to maintain contact with them and understand in which city they are registered (in order to predict the fulfillment of quotas by region). Therefore, registering on the site was quite complicated and required confirmation of the phone number. In order not to deceive ourselves and others, we included only people who filled out the entire form and confirmed their phone number as potential signatories. Therefore, on the main page, instead of more than a million (the total number of registrations), we now only have 706,513 “future signatures”.

From a website building point of view, this is a fairly ordinary product. The site is made in Python + Django + PostgreSQL, using a standard ORM and a standard admin panel. Over the course of a year and a half, the site went through several updates: sections were added, the operation of the registration form changed, texts and images on the pages changed. We tried not to complicate the design so that we could layout using standard blocks, thanks to which some sections went from idea to launch in three days.

About half of visitors to any modern website come from mobile devices. We tried to make the site convenient for everyone, so the layouts were drawn and laid out for correct display on any screen width, starting from 320px.

Headquarters map

The only complex interactive element that visitors see is a map of Russia with headquarters marked on it. When the number of headquarters exceeded 50, it became difficult to navigate on the map due to the close location of the markers in the European part of the country. Initially, the map was conceived as a purely decorative element, but suddenly it was filled with functionality, so for those who already appreciated the federal nature of the campaign and just want to find their city, we created a list mode.

The map is made using the wonderful and versatile d3.js library. We decided to write our own script rather than use standard Google Maps or Yandex.Maps because of the map projection. There are many ways to make a development of the Earth's ellipsoid on a plane. In the Mercator projection, objects are greatly stretched at northern latitudes, and we need more space in those areas where the main large cities are concentrated. In addition, in the Mercator projection, Russia looks rather strange. We chose the Albers-Siberia conic projection, which is more familiar from geography textbooks.

Russia of a healthy person (Albers conical projection) and Russia of a smoker (Mercator projection)

Content Management

The editorial section of the site is not very interesting. The usual Django admin panel is used with minimal customization. With limited development resources, it is more profitable to teach several admin users to use a standard tool than to spend time creating a truly convenient one.

Some solutions that make the editor's life easier were taken from other projects. For example, a tool for typography of texts on the client side. Our typograph is convenient because it easily connects to any text or string input field. Information about the state of autotypography (on/off) is stored as a non-printing character at the end of the line and does not depend on the backend in any way.

To work with complex content of posts and news, we use a block editor, which is also used in many other projects:

There are different types of blocks, each project has its own set. Each block contains content and may contain settings. The block data is stored in the database in the form of json, and the markup inside the text block is stored in markdown format.

For display, blocks are converted into the required format: HTML for a post, text for indexing, RSS or XML for Yandex.Zen, JSON for a mobile application, and so on. This way we get predictable results on any device with fairly complex content formatting.

The first version was based on the Sir Trevor code. Later, when Sir Trevor's spaghetti code became difficult to maintain, the editor was rewritten in React.

Analytics

The most interesting thing from a technical point of view happens in the admin area of ​​the site. From there we watched the flow of registrations.

At first, analytics was quite primitive: graphs of the number of registrations of various types over time. But we wanted to see the dynamics by region and track the impact of various events on the number of registrations. This is how the Long-awaited analytics appeared:


This screen contains summary information for the entire life of the site, a schedule for a certain period, and a list of events for this period. You can highlight a peak on the chart and try to understand what event caused it. Most often, this is the publication of another video with an investigation on Navalny’s YouTube channel. The biggest increase in signatures came from videos about the machinations of regional officials.

The chart is made in d3.js, and event filtering by time and headquarters is implemented using the Crossfilter library. This solution allows you to operate on the client side without interface delays with registration data over an interval of more than a year in 1-hour increments. Currently this is 12 megabytes of data (1.3 MB in gzip).

A small text report with key indicators of the registration base and successes for the previous day was automatically sent out daily to all project participants.

City and region

We also have a huge table where the main indicators of preparation for collecting signatures are listed for each region of Russia:

The numbers in this table did not want to converge at first. The total by city was significantly less than the number of registrations. It turned out that when filling out a questionnaire on the site, people unexpectedly often make mistakes in the name of their city or use non-standard names:

Moscow - 2.5% errors and 579 spelling variations;
- St. Petersburg - 12.6% errors and 767 spelling variations;
- Komsomolsk-on-Amur - more than 20% errors and abbreviations, 75 options.

An incorrect estimate of the number of supporters could lead to incorrect planning of the network of headquarters and campaign events. I had to think about how to turn user input of a city name into a standard region name. For such a simple form, I didn’t want to use auto-completion mechanisms according to KLADR or FIAS. Therefore, we took a list of the 700 largest cities in Russia, added a list of typical spellings (“spb”, “n-sk”) and did a loose search on them, ranking them by Levenshtein distance (this is a measure of the difference between two sets of characters).

We classified each city on the list into one of three categories based on the distance to the nearest headquarters: the headquarters is in the city, the headquarters is close (urban agglomeration), the headquarters is far away. The distance from the headquarters was taken into account when estimating the number of people who would arrive and sign at the right time. In the analytics, we separately counted all signatories and “available” ones (confirmed email, lives in the city with headquarters or nearby).

This graph shows how the campaign became increasingly regional over time. The share of new registrations from Moscow and St. Petersburg decreased from 35% to 15%.

SMS and mail

Another technical difficulty was sending SMS and letters. Gateways do not deliver messages very well, especially to foreign numbers. But we wanted the purest and most authentic base of supporters, so the second part of the registration form required phone number verification via SMS. For reliable sending, we rotated three gateways: if the message was not delivered, then it was sent again through another gateway. In addition, individual gateways could be turned off in case of failures on their side. SMS code deliverability rates are one of the parameters monitored:

The graph shows that the gateways failed twice. The share of delivered SMS dropped significantly on February 21 and April 17-18 due to failures in the message sending queue. And on July 15, we changed the layout of the registration form, this is also noticeable on the graph.

We send a large number of letters to a database of more than 700 thousand email addresses. Someone is subscribed to the news, someone should receive a notification about the event. In addition, each address must be confirmed according to the 2-opt-in rules (this is when the first letter contains a link that you need to click to confirm your subscription to the newsletter). At the beginning of the campaign, we used the ActiveCampaign service, but it was expensive and incredibly slow. When the database exceeded 300 thousand contacts, it became impossible to work. Therefore, we wrote our own CRM / mailing service, which allows you to create mailing lists and letter chains based on the required samples. Mailgun is currently used to deliver letters.

Deferred task queues

Sending mail or SMS through the API of third-party services is an operation that takes a significant amount of time. Such operations should be performed asynchronously so as not to slow down the user interface or put the entire application under load. Initially, all asynchronous tasks worked through Celery with Redis as a broker. Each email or SMS message created a task in the Celery queue, after which a free worker processed this task. But this approach turned out to be unreliable and too resource-intensive.

Once we received more than 10 thousand registrations in an hour (no, we were not shown on TV, it was a “+1” campaign). 10 Celery workers could not cope with this, users began to notice a significant delay in receiving SMS and mail.

After this incident, we abandoned Celery in favor of a simple queue based on PostgreSQL. Tasks from the queue were sorted by “daemons” in Python, one for each message delivery channel. Once every 10 seconds, the daemon took a batch of tasks from the queue and sent the data in one batch to the mailing API. Grouping tasks radically reduced the load on the server, and using a homemade queue made debugging and monitoring extremely simple.

Celery turned out to be too complex a tool for our task. It requires thoughtful configuration and monitoring through external utilities like Flower, which itself consumes a lot of resources. On other projects we try to use a simpler solution - RQ + Redis.

Comparison of complexity of RQ and Celery from an article about working with asynchronous tasks.

Development process

How does the process of creating the Navalny 20!8 website work from the developers’ point of view? We do not adhere to any one methodology, but use approaches from different systems. For example, managers set tasks in Trello with a structure similar to a Kanban board, and developers use individual Extreme Programming practices.

Approximately half of the team is located in the Moscow office, and the rest work remotely. Moscow employees can participate in campaign meetings so as not to work to better understand the overall picture, but we discuss the tasks of the IT department separately. Regular calls allow everyone to synchronize and understand the main direction of work at each moment.

Most of the project participants work on it full time, but some tasks were done by developers temporarily brought in from other projects, or even by volunteers. For example, volunteer Ilya almost completely created a map of headquarters for the main page.

The source code is stored in a git repository on the Bitbucket platform. A separate branch is created for each major new task. We do not create a staging server for each branch; they are all merged into develop to run on a single test server. After testing, the developer responsible for the task makes a pull request to the master. The team leader looks at the code and, if everything is good, starts the deployment. For large tasks, developers write detailed descriptions of what needs to be checked and what can go wrong during deployment.

The deployment is organized very simply. We have a tool that responds to a webhook from Bitbucket (or a button from its interface), takes the code from the desired branch, copies it to the server and runs the update script there. The script is formatted in a Makefile.

When you run “make update,” dependencies are updated, migrations are performed, static files are postprocessed, and, if everything went well, the uwsgi server is restarted. We try to make migrations so that they do not break the old code, so in case of deployment errors everything continues to work.

Development began on September 18, 2016. Since then, there have been 1228 commits, 200 pull requests, the deployment has been pushed into production over 600 times, and there have been 67 branches in the repository (most of them are now closed).

About design

In the project team, only two people constantly worked on the design (an art director with a product function and a designer), while both were actively involved in other campaign projects. Therefore, the approach to design was extremely utilitarian.

In the design of IT products, we are always guided by two basic principles:

1) Information for the most “lazy” and uninvolved user should be in the most visible place (this is how we, for example, determined the initial places of blocks and sections on the site);

2) The fewer people who use the final product, the less we try to decorate it (we save development resources) and the more input effort we can allow for each user (it is often more effective to train several people than to waste time implementing new features that will save user effort or will save you from mistakes).

That's why our low-user internal systems strive to look like a wireframe come to life, and everything a campaign supporter encounters is part of the overall visual communication, strictly subject to corporate style and common sense.

An IT system for collecting signatures is a very complex, multi-component project with limited resources, so the bulk of the designers’ work was done on paper, in meetings and in Google Docs, and not in a graphic editor (in our case, Sketch).

There are a lot of complex diagrams in the project that you just want to draw, and all the electronic tools for drawing diagrams that we found on the spot did not suit us. Sometimes we used draw.io, but more often we drew directly on paper. The most important diagrams hung on the project board. Paper “tickets” with questions for discussion at meetings were also attached there.

We collected prototypes from paper diagrams and scripts agreed upon with lawyers in marvelapp.com in order to once again check the logic and make sure that nothing was forgotten. Only after this the layouts were transferred to development.

Depending on the task, different research and design methods were used. So, before making the long-awaited analytics, we conducted a series of interviews with all potential users of the system (from the chief of staff to the person sending the mailings) and, based on their wishes, we were able to put together a very simple interface, which for a long time served as a campaign dashboard.

On one page we saw the flow of registrations, could see the events that influence it, and find out how our supporters are distributed across cities. We also collected ratings of cities by the number of signatories (this allowed us to monitor the effectiveness of the headquarters and told us whether we had chosen the right cities for opening new headquarters) and tabular analytics.

For the verification interfaces and the collection of signatures itself, the speed of the operator’s work was an absolute priority. The collection takes place under conditions of acute time pressure, so we tried to save every second and at the same time reduce the number of potential user errors.

According to our calculations, with the existing number of headquarters and subject to a continuous flow of people, each collector should have taken no more than 6 minutes per person - from “hello” to the completion of the collection procedure.

Verification and collection of signatures through an IT system is a procedure completely invented by us, so we chose MVP testing on real users of the system as the main method for testing our solutions. So we tested the basic protocol and the first verification interface on employees of the Moscow headquarters, and then went to three different cities (St. Petersburg, Chelyabinsk and Ulyanovsk) to observe real users in the process of work. For such projects, this is the best way to quickly make a list of things and user cases that might have been forgotten or not foreseen at the design and development stage.

After making minor changes to the interface, verification was launched at all campaign headquarters. As a result, we managed to reduce the processing time of one questionnaire to one and a half to two minutes per person.

Testing

RobotFramework was used for automated testing. To cover the most critical functionality of the project, acceptance and functional tests were written and their automatic launch was configured. Jenkins was used as a CI system.

The most important function of the site is user registration, which involves phone confirmation via SMS code. To test messages with codes, a GSM modem with a test SIM card and Asterisk was configured. The SMS code was sent to the mail, from where it was already available for testing.

Detected errors were added to Trello as tasks for developers.

Server infrastructure

The Navalny 20!8 website continues to operate and is gradually becoming the site of the voter strike campaign, so the information embargo has not yet been lifted, and the story will be short. The server part consists of three levels: backend, caching proxies and edge servers. All configurations are managed through chef, so a server with any role can be quickly installed on a new virtual machine.

The backend runs a database and application instances, each application on its own virtual machine and with its own IP. All servers exist in several copies, and the database is replicated in master-slave mode to another machine.

The proxy server has Varnish installed, which caches requests to certain addresses and various URL-dependent restrictions. If the backend fails, the site may work indefinitely from a proxy server; only the user registration mechanism will break.

Edge servers perform static caching and SSL termination (then the traffic goes through the VPN network). The essence of these servers is to distribute the bulk of traffic and protect the rest of the infrastructure from attacks. These are weak virtual machines with a gigabit channel in different data centers. The load is distributed by DNS balancing. Edge servers contain a minimum of configuration and, if necessary, can be easily installed in a few minutes. The maximum useful traffic we had on edge servers was 5 Gbps for several hours.

Images, styles, javascript, json data are stored in such a way that the file name includes a hash of the contents of this file (for example, style.28fa1c7b1761.css), so all these files can be cached forever on the server and in the browser. The bulk of traffic is sent from edge servers. Then only requests to content pages go through, and this is about 25 times less data.

Sometimes CloudFlare is connected instead of edge servers, but we try to return to our servers, since CloudFlare does not always have good accessibility from Russia. Some providers, even the largest ones, regularly begin to block their IP (traces of Roskomnadzor).

Conclusion

Collecting signatures in the traditional style (without a special IT system, with paper, pen and Excel tables) is like flying a balloon to the Moon: yes, if you take enough balloons, you can even take off and hide in the clouds, but still get to goals in this way is physically impossible.

In order to collect such signatures that the election commission would be forced to accept even from an undesirable candidate, we began to create this complex infrastructure. In this chapter, we talked about the task set before us and the preparation for solving it.

The next chapter talks about selecting and configuring headquarters network equipment, developing your own document scanner, and organizing video surveillance of headquarters premises.

The third chapter will describe the process of creating applications for collecting signatures and everything related to working with physical signature sheets.

The fourth chapter talks about project management, the team, the timeline and a little about the results.

Tags: Add tags

The first days after the launch of the campaign are very difficult, very full of current tasks. And although we have always been (and will be) supporters of maximum publicity in our work, we should not expect super-detailed reports right now. Nevertheless, I must say a few words.

What's happening now.
It’s all very simple: in a year we will need to collect 400-500 thousand signatures throughout the country (in order to select 300 thousand of them, with the condition: at least 7,500 each in 40 regions) within a couple of weeks of the New Year’s bustle. In order for there to be at least a theoretical chance of doing this, we now need to rebuild the entire infrastructure:
- so that these 400-500 thousand people sign up with us through the website, who will give all the data in advance and promise to sign up on D-day;
- create regional headquarters, recruit and train people who will prepare signature sheets and on D-Day will be able to super-quickly collect signatures from the 7,500 supporters who have signed up for the database; - so that there is money for this entire regional network, for renting premises and paying employees, for lawyers and for attracting new supporters; The approximate estimate provides for a budget in the region of 150-200 million rubles (we will publish the budget soon).

We started solving these problems the day before yesterday. On the one hand, it seems to be very successful. In the first two days - in just 48 hours - we registered the campaign on the website over 22,300 people(this is more than 7% of the minimum required 300 thousand), and attracted donations in the amount over 5 million rubles(this is more than 3% of the minimum required 150 million). It seems like if you extrapolate, it turns out that in a couple of months all goals will be achieved.

But you understand perfectly well that you cannot extrapolate. Each next person and ruble will be more difficult (and this is completely normal); there is a lot of work to be done. It was precisely understanding this that we launched the campaign exactly a year before the start of the “official” collection of signatures.

What is the headquarters doing now?
Accordingly, the headquarters is now preparing a structure that will ensure the solution of the tasks facing our campaign. Prepares answers to a thousand questions:
- how regional headquarters will be created, where, in what order, who will lead them,
- what propaganda materials will the volunteers receive (and already more than 6100 people not only promised candidate Navalny their signature in support of the nomination, but also promised to invest their volunteer efforts in the campaign) in order to use these materials to agitate the “undecided”,
- how we will ensure the safety of headquarters, volunteers, collectors, and the signatures themselves;
- what events will we hold in Moscow and in the regions...
And so on. The list is almost endless. Here we just wrote out a list of areas on the board - for each of these areas there will be goal setting, responsible people, a strategy and a plan for specific activities - this is already scary. But we will cope, not for the first time.

What questions are they asking us?
The most common and favorite question is “how to help”?
It's easy to help. See list of goals above.
- promise to sign
- send money
- make sure there are more signatures.

It is the latter that we will concentrate on in the near future. After all, we are asking for a signature in support of the nomination - not even in support of the candidate Navalny himself, but in support of the fact of his participation in the elections: in order to make presidential elections competitive for the first time in 20 years. It is not only Navalny’s supporters who can be persuaded to sign such a signature; The idea that real competition is needed in elections is shared by the overwhelming majority of Russians (we conducted a survey about this, we will also publish the data).
That's why we'll soon give volunteers and supporters the tools to go to family/friends/colleagues - even if they're skeptical - and convince them that they'll still benefit from signing for Navalny's nomination (even if they themselves are going to vote for Putin).

Well, they also ask a lot of questions about the program and other things. The candidate himself answers all these questions brilliantly; I have nothing special to add here.

Daddies, where we enroll supporters from various parts of vast Russia

What do people write to us about?
Lots of things. We read all the letters; We will definitely respond to everything that requires an answer.
The most pleasant and sweet type of letters are letters “I, Vasya Ivanov, am a lawyer, I live in Izhevsk, let me know when our headquarters opens - I will come to help.” We gratefully accept all such letters and put them in special folders (see the picture). And when we open a headquarters in Izhevsk, we will write to Vasya Ivanov and invite him to help.

And they also write: “I, Petya Zaitsev, am a programmer, I have so many hours a week for you.” And we also put these letters in special folders. And we will also invite everyone to help. Write letters, we read!

Well, the important thing: have a little patience. You've seen the list of directions. This elephant will have to be eaten in parts. We have a year of work ahead of us. You can’t open 50 regional headquarters in one day, create an entire line of propaganda materials, hold a hackathon for programmers and set up a propaganda call center - although, of course, you really want to do all this as quickly as possible. We will move step by step, month by month, according to a well-thought-out plan, within the framework of which everything will happen in due time. And gradually everyone who volunteered to help will get a real opportunity to help and contribute to

“For now this is a PR story”

Oppositionist Alexey has collected 300 thousand signatures required to register his candidacy for the 2018 Russian presidential elections. Will he now be allowed to participate in the elections?

According to the Law “On the Election of the President of the Russian Federation” (No. 19 - Federal Law of January 10, 2003), a self-nominated candidate (i.e., a candidate who is not nominated from a political party) must provide the Central Election Commission with at least 300 thousand signatures of voters, and each region should account for no more than 7,500 of them. Technologically, Navalny completed the task - he announced that he had already collected 335,782 signatures in no less than 40 regions of the country. However, they have no legal force.

“Signatures collected before nomination and before opening an electoral account are not valid,” Andrei Buzin, an expert in the field of election legislation, told us. Let's explain. According to the same law “On Presidential Elections,” the nomination of a candidate occurs no later than 20 days from the date of official publication of the decision to call elections. For now they are scheduled for the anniversary of the annexation of Crimea, March 18, 2018.

However, according to the Constitution, presidential elections will be officially called by the Federation Council no earlier than 100 days and no later than 90 days before voting day, that is, in December of this year. Accordingly, Alexei Navalny will be able to officially nominate his candidacy for the presidential elections and begin collecting signatures only in December. If a politician submits nomination documents on the same day that the Federation Council calls elections, then he will have from 55 to 45 days to collect signatures. If he collects the required amount within this period, the Central Election Commission will check their authenticity and decide on registration as a candidate.

Navalny himself is aware that the signatures collected now cannot be used when submitting documents to the CEC. On his website, he wrote that in order to “collect the required quantity quickly and efficiently at hour X,” each signature is an e-mail, phone number and a short questionnaire of a potential voter.

However, it is too early to talk about registering Navalny as a candidate. The question of whether he will even be able to nominate his candidacy for the presidential election is still unresolved. After the verdict in the retrial of the Kirovles case, the oppositionist found himself in a legal fork. On the one side? he was sentenced to imprisonment, which means that by law he has no right to participate in elections. On the other hand, he still has the opportunity to challenge this provision of the law in the Constitutional Court.

The head of the Center for Economic and Political Reforms, Nikolai Mironov, believes that Navalny collected signatures in order to show his political weight, and that he is capable of doing this in the future.

“This is a way of pressure,” said the MK political scientist. - I think that this is a signal to different social groups to support him, and to different sponsors. But we don’t know anything about the quality of these signatures.” The expert noted that a well-promoted politician can collect 300 thousand signatures, but this is very difficult. “As long as this story is outside the electoral process, it is for PR,” says the political scientist. - When the actual signatures will be collected, everything will depend on the election commissions. At some stage he may be cut off, but, as far as I understand, there is no ready-made scenario for Navalny’s participation in the elections.”

The functionary, disappointed in the blogger, spoke about the difficult situation at the headquarters.

At the blogger's headquarters Alexei Navalny, which continues to raise funds for the presidential campaign, despite the ban by the Central Election Commission and clarifications of the Constitutional Court, there is again confusion. A recent FBK functionary and human rights activist writes on his Facebook page about the management crisis in the protest ranks Vitaly Serkuanov. Serukanov explained his departure from Navalny’s team as “the need for self-respect.”

According to Vitaly Serkuanov, Navalny’s headquarters is unable to satisfy the demands of fund donors and publish statistics on signatures collected in the regions. The reason for the activist is obvious: the blogger lacks 250 thousand votes to be nominated, but getting the required number of supporters before the deadline will be an impossible task. The deadline for documents to be submitted to the CEC for registration ends on January 31, 2018 at 18:00. That is why, as Serukanov notes, Navalny’s team is changing tactics according to the principle Niccolo Machiavelli"End justifies the means". Unauthorized rallies on December 24 are planned as a tough stage in the transition from the failure of the campaign to the stage of a future boycott of the elections.

“Volkov (Navalny’s chief of staff) did not come up with anything new except to avoid answering questions about the reasons for the failure of the campaign, primarily tactical ones, through a sea of ​​detentions, arrests and negative publicity. Arouse the sympathy of the masses, fight back with administrative arrests, while ordinary participants will receive criminal sentences,” writes Serukanov.

Lawyer Ilya Craft, who conducted an independent investigation into the activities of FBK, in a commentary News Agency "Politics Today" noted that the number of disappointed Navalny supporters is naturally increasing.

The agency's interlocutor places former volunteers in this category Alexander Turovsky And Denis Lebedev. The first one was injured during a search at the blogger’s headquarters, but Navalny did not bother to mention his name. A similar story happened with Lebedev three years earlier. His leg was broken on one of his trips on FBK business, but the fund made it clear to the activist that they were not going to deal with his problems.

Remeslo is sure that Navalny’s headquarters understands perfectly well that they will not be able to account for the donations spent and collect the required number of signatures.

“There’s really no support. This situation shows that they cannot organize basic work, because these people have never worked anywhere or earned money through honest labor. Neither Volkov nor Navalny. That's why they are attracted to each other. If they had the necessary level of support, people would pour in non-stop. We collected these signatures even if Volkov and Navalny were completely untalented, but since they are also untalented and there is no level of support, then we get what we get,” commented Remeslo.