Правила хакатона: код, ИИ, помощь и спорные ситуации
Что определить в правилах хакатона до старта: готовый код, применение ИИ, помощь менторов, сроки, оценка и рассмотрение спорных случаев.
·4 мин чтения·
Что вы узнаете
Список решений о готовом коде, ИИ и помощи менторов.
Порядок фиксации версии правил, дедлайна и приёма проектов.
Вопросы для разбора спорной оценки и конфликтов интересов.
Правила хакатона должны позволять команде заранее понять, что разрешено, что нужно раскрыть и как будет приниматься решение при споре. Опубликуйте их до начала конкурсной работы и сохраните версию. Устное объяснение на открытии может дополнить документ, но не заменяет его.
Ниже перечень организационных решений для регламента. Условия участия, права на материалы, обработку данных и договорные обязательства необходимо согласовать под конкретное событие и юрисдикцию. Универсальная статья не подменяет такой документ.
Определите участие и состав команды
Укажите требования к участникам, допустимый размер команды и возможность работать одному. Если есть специальные категории, объясните, кто им соответствует и как это проверяется. Формулировка «для новичков» без определения может привести к разным ожиданиям.
Опишите порядок приглашения, замены и выхода участников. Установите, до какого момента состав можно менять и кто подтверждает изменение. Отдельно решите, могут ли организаторы, волонтёры и менторы участвовать в конкурсной оценке.
Для онлайн-формата уточните обязательные этапы присутствия. Если команда должна подключаться к проверке или финальному показу, она должна знать об этом при регистрации. Пропуск необязательной лекции не должен внезапно становиться нарушением.
Проведите границу конкурсной работы
Укажите начало и окончание времени разработки. Объясните, какие подготовительные действия разрешены: изучение документации, установка окружения, поиск команды или сбор идеи. Не оставляйте слово «подготовка» без примеров, если оно влияет на допуск.
Отдельно решите вопрос готового кода. Библиотека, общий шаблон приложения и ранее собранный продукт имеют разный объём чужой или прошлой работы. Регламент должен объяснять допустимые варианты и способ их раскрытия.
Попросите команды обозначить, что существовало до события и что изменилось во время него, если ваш формат допускает развитие заготовки. Если допуска нет, сформулируйте его прямо. История коммитов может помогать разбору, но сама по себе не описывает весь процесс создания проекта.
Опишите применение ИИ
Разделите помощь в работе и модель внутри продукта. Генерация кода, редактура презентации, создание изображений и вызов модели в приложении могут требовать разных условий. Укажите разрешённые способы, ограничения по данным и требования к раскрытию.
Не ограничивайтесь словом «честно». Дайте пример нужной записи: какой инструмент использован, для какой части, что команда проверила и где остаются ограничения. Если требуется журнал запросов или иное подтверждение, укажите формат заранее.
В рекомендациях MLH по правилам также выделено раскрытие готовых компонентов и применения ИИ. Их условия относятся к собственному формату; организатор должен принять и опубликовать правила именно своего конкурса.
Установите границы внешней помощи
Ментор может объяснить подход, помочь найти ошибку или обсудить решение. Но разрешённый объём участия в реализации определяет регламент. Участники должны понимать, где консультация превращается в выполнение конкурсной работы за команду.
Решите, как учитывать помощь людей вне официальной команды. Если разрешены внешние консультации, объясните, что нужно раскрывать. Если они запрещены, опишите границу так, чтобы обычное чтение документации не попадало в неопределённую зону.
Назначьте канал вопросов по правилам. Ответ, влияющий на условия соревнования, публикуйте для всех. Персональная переписка с одним участником не должна создавать скрытое преимущество или исключение.
Определите комплект и момент сдачи
Перечислите обязательные поля, файлы, ссылки и уровень доступа. Укажите длительность видео, если она ограничена, и требования к живому показу. Назовите точный часовой пояс дедлайна и состояние заявки, которое считается успешной подачей.
Объясните, можно ли редактировать материалы после отправки до дедлайна и что разрешено после его наступления. Исправление опечатки, восстановление доступа и доработка функции требуют разных решений. Если процедура исключений предусмотрена, она должна иметь владельца.
Согласуйте порядок фиксации технического сбоя. Участнику нужен канал обращения и перечень подтверждений, которые можно безопасно предоставить. Само обращение не гарантирует продления, если правила не устанавливают такого условия.
Собрать эти договорённости в документ поможет шаблон регламента Stavleak. Замените поля на условия вашего события и согласуйте спорные пункты до публикации.
Подготовьте процедуру спорного случая
Определите, кто принимает сообщение, кто рассматривает факты и кто утверждает решение. Сохраните предмет обращения, материалы, объяснение команды и основание результата. Не разбирайте неподтверждённые обвинения в общем чате как уже установленный факт.
Дайте команде возможность пояснить обстоятельства в рамках согласованного процесса. Одного необычно качественного демо недостаточно для вывода о заранее готовом проекте. Проверка должна опираться на конкретное правило и доступные свидетельства.
Укажите возможные последствия и порядок уведомления. Различайте техническую ошибку, неполное раскрытие и подтверждённое нарушение. Решение должно быть последовательным для сопоставимых случаев, а не зависеть от известности команды.
Проверьте регламент на пограничных примерах
До публикации разберите несколько сценариев:
Участник использует собственный шаблон, созданный до события.
ИИ написал функцию, которую команда изменила и проверила.
Ментор прислал небольшой фрагмент кода во время консультации.
Видео загрузилось вовремя, но обработка закончилась позже.
Судья консультировал проект и затем получил его на оценку.
Сервис приёма заявок недоступен перед окончанием подачи.
Если ответ зависит от устного мнения конкретного организатора, уточните документ. Затем свяжите правила с критериями оценки и формой подачи. Участник должен видеть согласованный процесс от регистрации до результата.
