Устранение ошибок


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

Разборы ошибок — это неформальные встречи, для которых не требуется публиковать повестку до встречи или резюме после неё.

Обязанности и доступ

Провести разбор ошибок может любой желающий. Чтобы провести регулярный запланированный разбор ошибок, добавьте своё имя пользователя WordPress.orgWordPress.org Сайт сообщества, на котором пользователи создают и публикуют код WordPress. Здесь можно скачать исходный код ядра, плагинов и тем WordPress, а также принять участие в обсуждениях и организации сообщества. https://wordpress.org/ в один из свободных слотов встреч в таблице ведущих разборов ошибок. Представители команды производительности ядра отвечают за то, чтобы у предстоящих встреч был назначен ведущий. Если для предстоящей встречи ведущий не назначен, им следует обратиться в канал #core-performance с вежливой просьбой к кому-нибудь стать волонтёром.

Для проведения разбора ошибок нет никаких технических требований, кроме наличия учётной записи WordPress.org и учётной записи в WordPress SlackSlack Slack — это платформа для группового обмена сообщениями и совместной работы https://slack.com/. У сообщества WordPress есть собственный канал Slack: https://make.wordpress.org/chat/. В идеале у вас должен быть доступ к использованию команды /here в канале #core-performance в Slack, но это не является обязательным требованием.

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

Проведение разбора ошибок

Разбор ошибок команды производительности ядра — это не встреча в традиционном смысле. Формат предполагает, что ведущий разбора ошибок, один человек (меняющийся для каждого запланированного разбора ошибок), последовательно работает с конкретным тикетом WordPress Core TracTrac Trac — это место, где участники создают задачи об ошибках или запросах на новые функции, подобно GitHub.https://core.trac.wordpress.org/. или «отчётом» о задаче Performance Lab. Это неформальная встреча со свободной структурой.

Отчёт — это список конкретных тикетов Trac / задач GitHubGitHub GitHub — это веб-сайт, предлагающий онлайн-размещение репозиториев git, которыми другие разработчики могут легко делиться, копировать и изменять. Публичные репозитории можно размещать бесплатно, а для частных репозиториев требуется платная подписка. GitHub представил концепцию «pull request», благодаря которой изменения кода, выполненные участниками в ветках, могут быть проверены и обсуждены до их объединения владельцем репозитория. https://github.com/, которыми можно публично поделиться с другими посредством URLURL Конкретный веб-адрес веб-сайта или веб-страницы в интернете, например URL веб-сайта www.wordpress.org. Несколько примеров:

Ведущий разбора ошибок должен выбрать отчёт для работы (из приведённого выше списка или любой другой отчёт, относящийся к производительности) и поделиться соответствующим URL в Slack. Затем ведущему следует предложить всем наблюдающим самостоятельно проверить соответствующие тикеты позже и при необходимости оставить дополнительный комментарий, если у них возникнут вопросы или сомнения относительно решения, принятого ведущим разбора ошибок.

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

Ведущий разбора ошибок также может делиться в канале Slack всем, что считает полезным. При этом, поскольку разбор ошибок не является традиционной встречей, нет необходимости ждать мнения других участников, которые могут присутствовать в канале.

В идеале каждый разбор ошибок должен длиться не менее часа, хотя ведущий, конечно, может продолжить, если захочет. Закончив разбирать тикеты, он должен сообщить об этом в Slack, официально завершив разбор ошибок.

Примеры сообщений

Не стесняйтесь копировать и вставлять эти сообщения либо игнорировать их и писать свои собственные. Эти примеры приведены только для справки и ни в коем случае не являются руководством или обязательными к использованию.

Начало разбора ошибок

  • /here Привет! Я собираюсь начать разбор ошибок, посвящённый производительности: <bug-scrub>.
  • Сегодня я буду работать с тикетами из следующего отчёта: <report-url>
  • По мере просмотра списка я буду оставлять обновления или комментарии по каждому тикету.
  • Если вы сейчас здесь, пожалуйста, тоже просмотрите эти тикеты и поделитесь своими мыслями. Это можно сделать либо в ответ на моё обновление по тикету, либо, если я ещё не дошёл до тикета, оставить комментарий к нему или отправить сообщение прямо здесь, в канале.

Окончание разбора ошибок

  • На этом сегодняшний разбор ошибок завершён. Напоминаю, что любой желающий может провести подобный разбор ошибок в любое время. Если у вас есть вопросы, не стесняйтесь обращаться.
  • Спасибо всем, кто был рядом, и до встречи через 2 недели!
  • </bug-scrub>