Get best of the week

Automation of a journalist. Part 2. Working with speakers

Look for the first part of the article here . In the second part, I talk about what tools I use when interacting with speakers.

image

If it is greatly simplified, the task of a technical journalist is to get some unique experience (understanding in a certain technical field) from the head of a profile specialist and present it in a form that is simple for mastering by a certain readership. You can talk about open source publications and from your head for a long time, but in reality, a technical journalist with few exceptions is not a specialist in the field of which he writes. And even if he is a specialist, then it would be nice to go to some points and clarify with someone. So in any case, someone needs expertise. The degree of simplicity of the subsequent presentation depends on the readers. And by the way, I sincerely believe that the copyright for the same experience should remain with the specialist, otherwise he will simply refuse to communicate with the journalist a second time ...

Communication is far from the first stage of text preparation. Therefore, at first a small digression on the work process.

Timeline Article Preparation


When creating almost any text on my profile, you can highlight the following milestones:

  • the emergence of a high-level task, for example, attracting specialists to turn over penguins to vacancies;
  • allocation of a platform where the task will be solved (if this is not corporate journalism, but a conditionally independent editorial board with its own publication, then everything is clear with the platform initially);
  • . , . , - ( ), . , , ;
  • . . , , . , ;
  • ;
  • ;
  • ;
  • ( );
  • .

An idealized process is spelled out above. In fact, it sometimes turns inside out, but in general the same steps remain, even if they are not formalized.

For example, if you work with a corporate blog, one of the main tasks is to provide an incoming stream of internal expertise, i.e. the turn of those who want to ā€œwriteā€ an article (to participate in writing it as a speaker). How this is done is a separate conversation, but in fact the blog editor (and sometimes a technical journalist, if all in one person) builds some kind of relationship with technical experts - sources of expertise. If the process is going well, the experts themselves come with ideas. And then the work starts somewhere in the region of 4 points, and the first 3 editor / journalist has to think up on the go, so that the topic chosen by the specialist will be useful for the customer.

Let's say the best penguin flipper comes to you and says that it has revealed a tendency that lame penguins with a yellow spot on their feet have to turn over more often. And this is a revolution in the industry, because itā€™s easier for them to immediately hang up beacons than to arrange a detour every time. The task of the editor / journalist is to come up with how this topic can be ā€œsuperimposedā€ on the previously stated high-level tasks and on which platform it is better to appear on. That is, 1-3 list items are not missing, they are simply implemented in a slightly different order.

Usually, work is on a dozen articles in parallel. Each of them is at its own stage. And each of my articles is exactly one entry in RTM, which simply evolves over time. Tags change tags, links and text information are added to notes, etc. When the article is released, the task in RTM closes, and the article goes to the archive, which I will talk about next time.

Returning to today's topic - we are talking about paragraph 5 and what happened here or failed to automate.

Communication tools


We figured out the timing for the interview last time. After an oral agreement, a meeting is created in the Calendar, which is worked out in advance by reminders and is copied to what follows. In half the situations (depending on the style of communication with the speaker) I try to confirm the conversation about a day before the appointed time, otherwise everything happens.

I came across a lot of editors who outsource interviews - write a list of questions and send someone less ā€œexpensiveā€ (in terms of ā€œrubles per hourā€) to speak on this list. In my opinion, interviews in technical articles are a thing that cannot be given to the side. Preliminary questions almost always reveal a poor topic. Judge for yourself: you need to ask about what you only know about from general publications on the Internet ... at the same time, you need to get the unique experience of a particular person about whom nothing is written exactly anywhere. During the conversation, you have to use all your previous experience to clarify the topic right on the go, to reveal those interesting points that suddenly surfaced. Otherwise, you will have to return to the speaker more than once, and not all experts love this.

Communication details are important, so I try to record 100% of interviews and meetings. The leased cloud is not particularly ā€œpocketā€ and does not occupy a place in the apartment, so I can store audio recordings for almost all of my work. Naturally, I try to warn the speakers that the recording is in progress. Sometimes they themselves ask which of us will write.

The main difficulty of recording is the communication tools zoo. The teams and individual speakers I work with use to call Slack, Hangouts, Telegram, Skype (or Skype for Business, which is available to me only through a web plug-in), Zoom, Viber, WhatsApp and even VKontakte with Facebook. Some still use a regular telephone. Not all of these tools allow you to write calls out of the box.

To secure possible unpleasant situations, I have configured recording wherever possible - this is the main part of automation:

  • The smartphone writes calls at the touch of a button (from some numbers, from where the tasks most often ā€œarriveā€ to me, it always says that itā€™s easier to clear the store every 3-4 months than later recall the details of the task formulated somewhere in the middle of a conversation on an abstract topic) .
  • Last year, Skype finally implemented the recording of calls within the system, and I actively use it. Sorry, you can not write Skype Out.
  • For other messengers, I have configured software that writes everything that happens on the computer. The software is launched manually, sometimes it is buggy, therefore I will not advise a specific tool.
  • For personal interviews, I use the recorder on the phone.

Until recently, I even rented a virtual telephone exchange with a city number - also for the purpose of recording calls. I used it when Skype disabled external plugins for recording, but I havenā€™t started it yet. Most of the calls I had at that time were via Skype Out to intercity, so in fact I just temporarily changed my service provider.

At one time, I tried to switch to this PBX entirely in order to ā€œget ridā€ of my mobile number. But not one of the tested smartphone applications performed well in poor communication conditions - and I sometimes visit such places. Plus, my mobile number knows too many working contacts. Therefore, the rented room is finalizing the last days. But the virtual PBX remained (just in case).

Collection of records


I have so far failed to fully automate the collection of records in the repository.

Each recording tool saves information in its own way. This doubly complicates life, when in the process of talking you have to switch between tools (Internet failure - call back on the phone). It would seem that you can set up automatic copying of all calls, but tons of telephone spam, calls about interview transfers and other related records will quickly fill up the repository with garbage, so that it will lose its meaning.

From a smartphone, recordings of important conversations have to be sent immediately manually to Yandex.Disk or to your own e-mail (depending on the number and size of files). From Skype, again, you have to manually download the records to the computer and upload them to the desired folder on Yandex.Disk. Skype does not allow you to automate the process.
Software for recording a screen with sound itself adds the recordings to the right place, and this is the only automation available to me.

Iā€™m dumping the interviews that are now in work into the Dropbox folder inside Yandex.Disk. I have been using Yandex.Disk for a couple of years to transfer files between all workstations. A ā€œcloud in a square" (Dropbox inside Yandex) is needed to ensure logging of work. Yandex.Disk does not know how to integrate with IFTTT, but not refuse it because of this. About 2 years ago, I already transferred a terabyte of data from a foreign cloud to Yandex for almost a month ... then there was no logging task yet, but I donā€™t want to repeat the move just because of it (and otherwise, Yandex suits me). Dropbox, however, was registered with me for interaction with one of the customers, so I used it to configure logging.

Why is logging necessary?

When the number of cases does not go through the roof, I attach the link to the file to the task in RTM - in the center for storing such entities as ā€œarticles in workā€. If for some reason I didnā€™t do it right away, then I have to look for the necessary files. I set up all my recording tools so that they add the date and time of the call, as well as the interlocutorā€™s contact (for example, mobile phone number) to the file name. So the search comes down to identifying the date of the call. It is not always possible to use the interlocutorā€™s contact, because sometimes we switch between tools. But the date and time remain the same.

To simplify the search, I made through IFTTT a separate calendar journal, which is automatically written to:

  • . Android-. - , . : , . .. , , , - . .
  • notes about conversations saved in Dropbox. When a file is added to the folder, IFTTT makes a mark on the calendar and throws a link to this file. So if you look at the main calendar and the journal calendar at the same time, you can establish an unambiguous correspondence between the recording file and the call that passed on a certain day.

Despite these ā€œprotocol difficultiesā€, I still try to manually tie the interview to RTM right after the conversation. Itā€™s faster than doing a ā€œdog searchā€ later.

By the way, I had to work in teams where information about the interview is poured into a large Google spreadsheet. And this in my case is inconvenient. In the teams, additional bureaucracy was justified by the fact that the interviews were conducted alone, and the texts were written by completely different people. I had to build a repository differently. I will tell you how it works for me next time.

More articles:


All Articles