Проверка задания ментором

Студент выполняет задание в приватном репозитории.
Студент создает и оформляет Pull Request до дедлайна.
До выставления финальной оценки ментором, студент может продолжать реализовывать фичи.
Ментор проверяет PR, оставляет свои замечания и рекомендации по качеству кода и реализованной функциональности. Указывает предварительную оценку в комментарии.
- Оценка выставляется ментором на основании критериев оценки указанных для каждого задания
- При выставлении оценки учитывается весь реализованный функционал. Например, студент выполнил минимальные требования не на 100 процентов, но выполнил часть дополнительных - все требования должны учитываться
- Ментор может выставить предварительную оценку авансом, с учетом того, что студент исправит все замечания ментора
Студент в течении 5 дней исправляет замечания ментора.
- Если комментарии ментора к PR предполагают ответ студента - студент пишет ответ
- Если студент вкоммитал правки, он должен оставить комментарий о том, что именно было вкоммитанно/исправлено
По результатам исправления ментор выставляет окончательную оценку в Score (RS APP > Submit-review).
- Ментор сам решает снимать баллы или нет за функциональность реализованную студентом после дедлайна.
- Если студент не исправил замечания ментора по качеству кода, ментор может дополнительно снизить оценку. Размер штрафа на усмотрение ментора, максимум -50 баллов.

Требования к Pull Request (PR)

Pull Request - это место для обсуждения кода. Он не должен выглядеть как монолог студента или ментора. Будьте культурными, уважайте время и работу друг друга.

Pull Request не должен содержать:

Закомментированного кода
Лишних файлов, автосгенерированного кода, node_modules и т.д.

Описание Pull Request должно содержать следующую информацию:

Ссылка на задание.
Скриншот результата выполнения задания (страница созданного приложения или сайта). Скриншот добавляем в Pull Request в виде изображения. Для добавления в Pull Request изображения, его можно просто перетянуть с компьютера.
Ссылка на задеплоенную версию вашего приложения или сайта. Для деплоя можно использовать:
- при наличии приватного репозитория школы - gh-pages
- при отсутствии приватного репозитория школы или при невозможности разместить приложение на gh-pages приватного репозитория школы, приложение можно разместить на netlify.com, либо на другом подобном хостинге.
- для демоверсий, размещённых на netlify, название сайта даётся по схеме: имя гитхаб аккаунта - название таска.
Дата сдачи / дата дедлайна.
Ваша самопроверка с предварительной оценкой.

Пример оформления

1. Task: https://github.com/rolling-scopes-school/tasks/blob/master/tasks/fancy-weather.md
2. Screenshot:
   ![](https://docs.rs.school/images/fancy-weather.png)
3. Deploy: https://chakapega-fancy-weather.netlify.com/
4. Done 28.05.2020 / deadline 31.05.2020
5. Score: 220 / 300
- Вёрстка, дизайн, UI (15/30)
  - [x] минимальная ширина страницы, при которой она отображается корректно – 320 рх (10)
  - [±] внешний вид приложения внешне соответствует макету или является его улучшенной версией (5/10)   
  - [ ] приложение корректно отображается для любого выбранного языка (0)
- В блоке "Погода за сегодня" отображаются следующие данные (15/20)
  - [x] данные о погоде и местоположении пользователя (10)
  - [±] часы, обновляющие время каждую секунду (5/10) 
 ...

Пример проверки студенческого PR ментором

Проверка оформления - PR, коммиты, deployment.

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

Базовые проверки - линтер, сборка

Линтер настроен согласно требованиям задания, все проверки проходят без ошибок
Нет выключенных правил линта, попытаться выяснить для чего это было сделано и можно ли этого избежать.
Проект собирается без ошибок
Нет console.log в production коде
Нет закомментированного кода

Проверка функциональности - работа приложения

Все основные функции работают корректно
Отсутствуют ошибки в консоли
Запросы отрабатывают корректно
Реализована функциональность согласно требованиям задания

Code review - качество кода, архитектура

Для проверки качества кода можно использовать матреиал из репозитория mentor-resources. Часть этих рекомендаций должны быть включены в конфигурацию Eslint и Typescript согласно требованиям задания.

UI/UX проверка - дизайн и пользовательский опыт

Соответствие макету (если был)
Адаптивность (если требуется)
Кликабельные элементы визуально выделены
Обратная связь при взаимодействии (hover, active)

Детально процесс проведения код ревью описан в checklist.

Инструменты автоматизации проверки

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

Bash-скрипт автоматической проверки

Файл: templates/scripts/auto-check.sh

Подробнее: Документация по скрипту

AI агент для комплексного code review

Используйте AI агентов (Claude, ChatGPT и т.п.) для глубокого анализа кода с использованием промпта. Подробно о том, как его использовать для код ревью прочитать в чеклисте здесь.

Дедлайны для студентов

Дедлайны всех тасков указаны в расписании курса.
Если студент не успел сдать задание вовремя, ментор по своему желанию может применить следующие штрафы:
- -10 баллов к оценке при опоздании до 3 дней включительно
- -30% процентов к оценке при опоздании до 7 дней включительно
- -70% процентов к оценке при опоздании более чем на неделю
- по усмотрению ментора, при наличии уважительной причины (больница, армейские сборы и т.д.)
- При применении штрафных коэффициентов, округление происходит в пользу студента

Дедлайны для менторов

Ожидается, что ментор проверяет работу студента в течении одной-двух недель после сдачи работы студентом. Но чем раньше, тем лучше. Даты дедлайнов для студентов указаны в расписании.