Где живут ответы: языки, корпуса, сообщества

Два наблюдения, которые звучат банально и почти никогда не используются на практике.

Первое: у ответа есть язык, и языки не являются переводами друг друга. Запрос на русском и запрос на английском возвращают не один и тот же материал в разной упаковке, а два разных множества документов, написанных разными людьми по разным поводам.

Второе: большая часть технического знания вообще не записана. Она находится в головах людей, и добывается не поиском, а вопросом. Умение задать вопрос так, чтобы на него ответили, — такой же поисковый навык, как умение составить запрос.

Эта глава про оба наблюдения, потому что они об одном: ответ — не абстрактный текст в сети, а след, оставленный конкретным сообществом.

Корпуса не пересекаются так, как вы думаете

Практическая картина, устойчивая для большинства технических тем:

Три следствия, которые стоит принять как рабочие правила.

1. Нормативное — только в оригинале. Переведённая документация отстаёт от исходной на месяцы, а иногда на версии. Хуже того, при переводе теряется модальность: MUST и SHOULD превращаются в одно «нужно». Если вопрос нормативный, читать надо оригинал, даже если это тяжелее. Про язык таких документов — Инженерный английский.

2. Практическое — там, где живёт практика. Как настроить взаимодействие с локальным платёжным провайдером, что происходит с DNS у конкретного местного оператора, как ведёт себя оборудование, которое продаётся только в одном регионе, — на английском об этом не написал никто, потому что англоязычному сообществу это не нужно.

3. Другой корпус — это ещё и другой набор ошибок. Если по вашей проблеме в английском сегменте тишина, попробуйте искать на другом языке: возможно, с ней сталкиваются только те, у кого схожая инфраструктура.

Как искать на языке, которого вы не знаете

Хорошая новость: для технического поиска знание языка почти не требуется, потому что самая информативная часть текста интернациональна.

Приём первый: идентификаторы не переводятся. Имена функций, флаги, коды ошибок, сообщения из исходников одинаковы во всех корпусах. Запрос из одного латинского токена плюс одного слова на нужном языке работает отлично:

ETIMEDOUT 超时 重试        # китайский: таймаут, повтор
NullPointerException 原因   # китайский: причина
segmentation fault 原因     # японский: причина (кандзи те же)
connection refused 対処法   # японский: способ решения

Приём второй: код читается без языка. В статье на незнакомом языке блоки кода, конфигурации и вывод команд понятны полностью. Часто этого достаточно: вы видите конфигурацию, которая решает вашу задачу, а прозу можно пропустить или перевести.

Приём третий: машинный перевод страницы. Технические тексты переводятся машиной хорошо: терминология стандартна, конструкции простые. Ошибки перевода касаются связок, а не сути. Осторожность нужна с одним: переведённые сообщения об ошибках и названия опций надо возвращать в оригинал, иначе вы будете искать несуществующие строки.

Приём четвёртый — и самый важный практически: заставьте свою систему говорить по-английски.

# локализованное сообщение об ошибке невозможно найти в интернете —
# получаем оригинальное английское
LC_ALL=C command-that-fails
LANG=C git status

# для менеджера пакетов и системных утилит — то же самое
LC_ALL=C apt-get install foo
LC_ALL=C.UTF-8 systemctl status myservice

Это одна из самых окупаемых привычек в работе с локализованными системами. Русское, немецкое или китайское сообщение об ошибке в интернете обычно не встречается вовсе: в исходниках лежит английская строка, а всё остальное — результат подстановки перевода. Ищите английский оригинал.

Приём пятый: искать по коду ошибки, а не по тексту. errno 111, ORA-01555, SQLSTATE 23505, E0499 — числовые и буквенные коды одинаковы во всех локализациях и дают точную выдачу в любом корпусе.

Площадки локальных сообществ

Небольшая карта, чтобы знать, куда смотреть. Состав меняется, но структура устойчива.

Важная особенность, о которой стоит помнить: часть этих корпусов плохо индексируется привычными движками. Китайский сегмент лучше ищется китайскими поисковиками, японский — японскими. Если вы подозреваете, что ответ есть в конкретном сегменте, имеет смысл идти прямо на площадку и пользоваться её собственным поиском.

Ещё одна практическая деталь: интерфейс на английском экономит время не только при поиске ошибок. Названия пунктов меню, разделов консоли облака и настроек в локализованных интерфейсах переведены по-разному в разных версиях, и инструкции по ним не находятся. Переключение интерфейса рабочих инструментов на английский — разовое действие с постоянной отдачей.

Знание, которое не записано

Теперь вторая половина главы. Есть категория вопросов, на которые в вебе ответа нет и не будет:

• поведение системы в редкой комбинации версий;
• планы проекта («собираетесь ли вы поддерживать X»);
• причина странного решения, о которой не написали;
• опыт эксплуатации под нагрузкой, которой ни у кого больше нет;
• всё, что произошло за последние недели.

Это знание существует, но живёт в людях и в непубличных каналах. Единственный способ его получить — спросить. И здесь начинается навык, у которого есть техника.

Где физически находятся мейнтейнеры

Отдельно про чаты. Discord, Slack и Telegram стали основными каналами поддержки многих проектов, и у этого есть системное последствие: ответы, данные в чате, не индексируются и через месяц не существуют. Каждый следующий человек задаёт тот же вопрос заново. Если вы получили в чате хороший ответ, самое полезное, что можно сделать для всех, включая себя, — превратить его в issue, в правку документации или хотя бы в публичную заметку.

Как найти конкретного человека, который знает:

# кто писал этот файл и кто активен сейчас
git shortlog -sn --all -- path/to/file.go | head
git log --since='6 months ago' --format='%an' -- path/to/ | sort | uniq -c | sort -rn | head

# кто отвечает за область по договорённости проекта
cat CODEOWNERS .github/CODEOWNERS 2>/dev/null

# кто чаще всего отвечает в трекере по этой теме
# (поиск в трекере: is:issue commenter:USERNAME label:...)

Дальше — докладчики конференций по теме, авторы статей, авторы релевантных PR. В открытом коде почти всегда можно установить, кто именно знает ответ. Вопрос лишь в том, как его задать.

Как задать вопрос, чтобы на него ответили

Классический текст на эту тему — «How To Ask Questions The Smart Way» Эрика Реймонда и Рика Моэна; он местами резок, но по существу верен. Ниже — рабочая выжимка с поправкой на современные каналы.

Структура вопроса, которая работает:

1. Одна строка сути в заголовке: что не работает, в каком компоненте, в какой версии. Не «помогите», не «странная ошибка».
2. Контекст: что вы делаете и зачем. Три предложения максимум.
3. Версии и окружение: версия продукта, ОС, способ установки. Это первое, что спросят.
4. Минимальный воспроизводимый пример. Главный элемент. Не ваш проект, а сокращённый до десяти строк случай, который воспроизводит проблему.
5. Ожидаемое и наблюдаемое поведение — двумя строками, буквально.
6. Что вы уже пробовали и что нашли в поиске. Это уважение к времени отвечающего и одновременно защита от ответа «погуглите».

Минимальный пример — это не формальность. Пока вы его делаете, происходит одна из двух вещей: либо проблема находится сама (очень часто), либо у вас появляется точный артефакт, который отвечающий может запустить за десять секунд. Оба исхода хорошие. Формальные требования к такому примеру аккуратно описаны в руководстве Stack Overflow.

Чего делать не надо:

• Спрашивать разрешения спросить. «Привет, можно вопрос?» и молчание — это лишний круг ожидания (nohello.net).
• Задавать вопрос про своё решение вместо своей задачи. Классическая XY-проблема: вы спрашиваете, как сделать шаг, который сам по себе не нужен. Скажите, чего вы хотите добиться, — часто ответ будет «делайте иначе». Описание проблемы: xyproblem.info.
• Присылать скриншот текста. Текст присылают текстом: его можно искать, копировать и цитировать.
• Писать «срочно». Ваш дедлайн не является аргументом для человека, который отвечает бесплатно.
• Дублировать вопрос во все каналы одновременно.
• Исчезать после ответа. Отсутствие обратной связи — главная причина, по которой люди перестают отвечать.

Этикет открытого кода

Несколько правил, соблюдение которых заметно повышает вероятность ответа.

• Сначала поиск среди закрытых issue. В половине случаев ответ там, и это видно по вашему вопросу.
• Прочитайте CONTRIBUTING и шаблон issue. Их писали, чтобы вы не тратили чужое время.
• Разделяйте баг и вопрос. У многих проектов есть Discussions для вопросов и Issues для дефектов. Вопрос, оформленный как баг, раздражает.
• Не требуйте. Мейнтейнер, как правило, не обязан вам ничем.
• Пишите по-английски, если проект международный, даже если это тяжело. Короткие простые фразы лучше сложных; про язык таких сообщений — Инженерный английский: issue и баги.
• Возвращайтесь с результатом. «Помогло, причина была в таком-то параметре» — три строки, которые превращают ветку в источник для следующих ста человек.
• Отдавайте долг. Ответьте на чужой вопрос, который вы теперь знаете. Корпус, из которого вы черпаете, состоит из таких ответов.

Доклады и записи как источник

Отдельный слой, который недооценивают: конференционные доклады. Их профиль специфический — низкая плотность на минуту, но высокая доля того, чего нет в текстах: реальные цифры, реальные отказы, честные ответы на вопросы из зала.

Как с ними работать эффективно:

• Читайте слайды, а не смотрите видео. Слайды часто выкладывают отдельно; двадцать слайдов просматриваются за три минуты вместо сорока.
• Смотрите расшифровку. Автоматические субтитры позволяют искать по видео текстом и переходить сразу к нужной минуте.
• Секция вопросов ценнее доклада. В ней спрашивают ровно про то, что докладчик обошёл.
• Ищите не тему, а докладчика. Найдя человека, который делает то же, что вы, посмотрите все его выступления за несколько лет: там видно эволюцию решения и то, от чего он отказался.
• Программы конференций — карта области. Оглавление программы профильной конференции за три года показывает, что реально волнует индустрию, лучше любого обзора.

Что делать с непубличными каналами

Часть ответов лежит в местах, куда обычный поиск не заходит: закрытые Discord-сервера, корпоративные Slack, приватные рассылки, платные сообщества. Практическая позиция здесь такая:

• Вступать стоит выборочно. Каждый канал — постоянный расход внимания. Один-два по действительно ключевым для вас технологиям, не десять.
• Поиск внутри канала — первое действие. У большинства платформ поиск по истории работает, и он часто лучше, чем кажется.
• Не пересказывайте наружу то, что сказано в закрытом канале, без разрешения. Это не только этика, но и условие, на котором такие каналы существуют.
• Помните про асимметрию. Знание, живущее только в закрытом канале, недоступно тем, кто придёт после вас. Если ответ не конфиденциален, его стоит вынести в публичное место.

Как спрашивать внутри компании

Внутренний вопрос отличается тремя вещами: человек обязан ответить, у него мало времени и он знает контекст.

• Начинайте с того, что вы уже проверили. Это переводит разговор из «объясни мне всё» в «подтверди или поправь».
• Формулируйте вопрос как выбор, а не как открытую тему. «Я вижу два варианта, склоняюсь к первому, потому что…» получает ответ в разы чаще, чем «как правильно сделать?».
• Указывайте срочность честно и отдельно от вопроса.
• Пишите асинхронно по умолчанию. Разговор в реальном времени дорог для обеих сторон; про баланс — Асинхронная коммуникация.
• После ответа зафиксируйте его там, где ищут. Внутренний ответ, оставшийся в личных сообщениях, будет запрошен заново пять раз.

Когда ответили не то

Три частые ситуации и что с ними делать.

Ответили на другой вопрос. Обычно это значит, что вопрос был неоднозначен. Не спорьте — переформулируйте: «спасибо, я неточно спросил; мне нужно понять вот что», и добавьте различающую деталь. Раздражение здесь непродуктивно: вы получили информацию о том, как читается ваш текст.

Ответили «читайте документацию». Иногда справедливо, иногда нет. Продуктивная реакция: «я читал раздел X, там сказано вот это; мой случай отличается тем-то». Это переводит разговор на предметный уровень и показывает, что вы не экономите чужое время за свой счёт.

Ответили грубо. В части сообществ прямота и резкость — норма, а не оценка вас. Технически полезная часть ответа обычно всё равно там есть; извлеките её и игнорируйте тон. Если ответа нет вовсе — это сигнал сменить канал, а не спорить.

И отдельный случай: никто не ответил. Через несколько дней уместно один раз добавить в ветку новую информацию (не «ап», а именно новое: что вы попробовали, что выяснили). Это одновременно поднимает тему и показывает, что вы работаете. Если тишина продолжается — вопрос, скорее всего, слишком специфичен, и дальше остаются исходники и эксперимент.

Типичные ошибки

1. Считать, что перевод и оригинал — одно и то же. Корпуса разные, и по объёму, и по содержанию.
2. Искать по локализованному сообщению об ошибке. Сначала LC_ALL=C, потом поиск.
3. Не пробовать другой языковой сегмент, когда в основном пусто.
4. Читать переведённую документацию по нормативному вопросу. Модальность теряется при переводе.
5. Задавать вопрос до поиска по закрытым issue.
6. Спрашивать про своё решение вместо своей задачи.
7. Оставлять ответ в чате. Через месяц его не существует.
8. Не возвращаться с результатом. Это единственная плата, которую с вас просят.

Мини-практика

Возьмите проблему, которую вы недавно решали, и проверьте, как она выглядит в двух других корпусах.

1. Сформулируйте запрос из латинского идентификатора плюс одного слова на другом языке.
2. Посмотрите, есть ли ответы, которых не было в вашей основной выдаче.
3. Найдите в репозитории соответствующего проекта человека, который писал этот код.
4. Сформулируйте вопрос ему по структуре из этой главы — и, если вопрос действительно остался, задайте.

Даже если ответ не нашёлся, упражнение даёт калибровку: вы увидите, насколько корпуса на самом деле различаются, и перестанете считать пустую англоязычную выдачу доказательством отсутствия.

Мини-итог

• Языковые корпуса — разные множества документов, а не переводы; нормативное и научное живёт в английском, практическое и региональное — в локальных сегментах.
• Для поиска в незнакомом языке достаточно латинских идентификаторов, кодов ошибок и умения читать код; проза переводится машиной приемлемо.
• LC_ALL=C перед командой возвращает оригинальное сообщение об ошибке — привычка, экономящая часы.
• Часть знания вообще не записана: планы, редкие комбинации, причины решений, свежие события. Это добывается вопросом.
• Мейнтейнеры находимы: история коммитов, CODEOWNERS, комментарии в трекере, доклады.
• Хороший вопрос — это заголовок с версией, минимальный воспроизводимый пример, ожидаемое и наблюдаемое, список проверенного. Пока вы его готовите, проблема часто решается сама.
• Ответ, полученный в чате, исчезает; перенесите его в issue, документацию или заметку.
• Возврат с результатом — единственная плата, которую просит сообщество, и единственный способ, которым корпус пополняется.

Источники

• Eric S. Raymond, Rick Moen. How To Ask Questions The Smart Way — catb.org/~esr/faqs/smart-questions.html.
• Stack Overflow, «How to create a Minimal, Reproducible Example» — stackoverflow.com/help/minimal-reproducible-example.
• «The XY Problem» — xyproblem.info.
• «No Hello» — про открывающие сообщения без содержания: nohello.net.
• Nadia Eghbal. Working in Public: The Making and Maintenance of Open Source Software (Stripe Press, 2020) — про экономику внимания мейнтейнеров.
• Трек Инженерный английский — язык issue, обсуждений и асинхронной переписки.

Что дальше

Мы разобрали, где искать. Осталось не менее важное: когда прекратить. Когда перестать искать: цена поиска против цены проверки.