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

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

Ниже можно увидеть схему жизненного цикла иссуев, а после нее будет подробное описание основных этапов.

• Требуется проверка
  • Дополнительные этапы проверки иссуя
• Требуется проработка
• Геймдизайн
• Разработка
• Пулл Реквесты
• Критерии оценки сложности иссуев

Первый этап любой иссуи - они все создаются с такой плашкой. На этом этапе любой человек с доступом к управлению плашками (разработчик, геймдизайнер, тестер и т.д.) должен сделать следующие вещи, после чего снять плашку "нужна проверка":

1. Иссуй адекватный? Убедиться, что иссуя относится к билду, а также соответствует правилам сообщества и гитхаба. Если это не выполняется, то иссуй следует сразу закрыть, написав причину в комментариях. Если баг не баг, то можно повесить плашку "так и хотели". Также можно повесить плашку "wtf"
2. Баг/улучшение выбрано правильно? Проверить правильно ли стоит плашка "баг" или "предложение". Баг - это исправление ошибок в существующих механиках, предложение - новые механики или расширение/перепил старых.
3. Есть подходящие плашки-области? Посмотреть какие плашки областей могут относится к иссуе и повесить их (ИИ, медицина, режимы и т.д.).
4. Есть дубликаты? Проверить что на гитхабе уже нет похожих иссуев. Если есть, то написать об этом в комментарии со ссылкой на предыдущую такую же багу (в формате #1234), добавить плашку "дубликат" и закрыть иссуй. Если в иссуе предоставлена дополнительная информация, которая может помочь разобраться с предыдущей иссуей, об этом стоит упоминуть в первоначальной иссуе. Плашки областей, которые мы вешаем прошлым этапом, очень хорошо помогают выявлять дубликаты, т.к. искать среди них гораздо проще, чем сразу по всем иссуям билда.
5. Уточнить описание и название. Если есть возможность написать более понятно то, что написал игрок - это стоит сделать. Если описание автора совсем плохое и нужно переписать его полностью, то можно оставить его в виде цитаты в конце описания.
6. Нужны спрайты? Если нужны, повесить плашку "спрайты".
7. Баг: достаточно ли информации? Если иссуя - баг, то оценить насколько он реальный. Если есть основания полагать, что бага не существует, или сложно понять в чем конкретно заключается баг, то надо уточнить это у автора в комментариях и повесить "требуется информация", пока автор не ответит и ситуация не прояснится.
8. Улучшение: касается геймдизайна? Если это улучшение, то оценить, касается ли улучшение игрового экспириенса игроков (все, чего касаются игроки. Педальных кнопок, например, не касаются). Если касается, то вешаем плашку "геймдизайн".

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

1. Оценка приоритета (только для OnyxBay Owner, главы разработки и глав серверов). Если все очень плохо - наивысший приоритет. Если игроки сталкиваются с этим каждый день и баг мешает каким-то основным механикам - повышенный приоритет, если мелочь, типо цвет галстука поменять, то пониженный.
2. Оценка сложности (только для разработчиков и главы разработки). Зависит от времени, которое нужно потратить на решение проблемы. Если примерно сразу понятно где смотреть и что там одна строчка - это просто. Если нужно трогать БД или писать/перерыть много кода - сложно. Для улучшений оценивать сложность нужно после проработки и одобрения геймдизами (если нужно).

Этот этап касается только улучшений. Сюда все улучшения попадают если модератор, OnyxBay Owner или разработчик считают, что по иссую есть вопросы. Эти вопросы обязательно должны быть заданы в комментариях!

Соответственно чтобы снять эту плашку и перейти к следующему этапу, нужно предоставить ПОДРОБНУЮ проработку фичи, ответив на все заданные вопросы и вопросы, которые могут возникнуть позже. Что поменять, насколько поменять, с каким конкретно шансом что-то должно происходить. Какие нужны спрайты, в каких случаях эти спрайты должны показываться.

Например, вы хотите добавить новый режим? Как часто этот режим должен появляться? Какие цели у этого режима? Какие роли? Какую экипировку получают эти новые роли, где они спавнятся? Какие условия завершения раунда? Какой урон должна наносить новая вундервафля, которую вы хотите добавить в этот режим? Должна ли она станить?

В общем в результате, после проработки, разработчик должен прийти и просто реализовать вашу идею. Он не должен думать "а мне поставить шанс 10 или 30%", он не должен искать спрайты - он должен просто прийти и написать код, чтобы он в точности выполнял то, что написано в иссуе.

1. Кто? Проработкой, в первую очередь, должен заниматься автор идеи. Если идея брошена автором, то проработкой занимаются, в основном, геймдизайнеры.
2. Что должно получиться в итоге? В результате проработки ОПИСАНИЕ иссуи (то есть первый пост) должен содержать достаточную информацию о том, как должна выглядеть иссуя в результате с точки зрения игрока. После проработки иссуя попадает овнерам на аппрув, а после этого разработчикам для реализации.
3. Я не могу изменять описание иссуи. Если у вас нет прав менять описания иссуев, но вы хотите прорабатывать идеи - прорабатывайте их в комментариях. Люди, которые активно помогают с этой частью, могут писать заявки на геймдизайнера, чтобы получить нормальные права.
4. Спрашивайте заранее. Перед проработкой можно уточнить у овнеров подойдет ли идея в общем, чтобы не прописывать мелкие детали идеи, которая не будет реализована ни в каком виде. Однако, на данный момент идеи принимаются довольно либерально и если вы не предлагаете что-то излишне экзотическое, скорее всего это будет принято.
5. Как проработать еще лучше. Чтобы лучше проработать идею - можно попросить кодеров/овнеров позадавать наводящие вопросы. В конце концов именно им реализовывать/одобрять и если они посчитают идею недостаточно проработанной - они могут вернуть обратно плашку с дополнительными вопросами и попросить проработать до конца.
6. Заканчиваем проработку. Если вы считаете, что иссуя проработана и не вызовет вопросов у разработчиков или овнеров касательно того что должно получиться в итоге - снимайте плашку. Дальше она попадает либо овнерам на подтверждение, либо сразу к разработчикам, если подтверждение не требуется.

Плашка "геймдизайн" вешается только на те иссуи, которые затрагивают игровой экспириенс игроков.

OnyxBay Owner-ы должны проверять все иссуи с плашкой "геймдизайн" и высказываться за/против принятия улучшения в билд, если иссуя проработана и не вызывает вопросов к автору иссуи (нет плашек "требуется проработка", "нужна информация" и т.д.). Если иссуя недостаточно проработана, то нужно вешать плашку "требуется проработка", чтобы ей занялись геймдизайнеры.

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

Чтобы попасть в разработку у иссуи не должно быть плашек "требуется проверка", "требуется проработка", "нужна информация". Если иссуя - это предложение с плашкой "геймдизайн", то у нее должна быть плашка "одобрено".

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

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

Все Пулл Реквесты так или иначе проходят такие же проверки. Проверяется адекватность, нужность, а если касается геймдиза - проходит этап одобрения и так далее. Чтобы не потратить время впустую и не стать обладателем отклоненного ПРа рекомендуется заливать ПРы только связанные с какими-то иссуями, которые уже попали на этап разработки.

Улучшение уже существующих механик или различные комбинации существующих механик. Не надо лезть в какой-то совсем уж говнокод, не надо работать с БД.

Примеры:

• Призраки на фотографиях #1166 - залезть в код фотоаппарата и немного подкрутить проверки на инвиз. Уникальная задача, как это делать подсмотреть негде, поэтому не простой, а обычный.
• Крысы разносят вирусы #1031 - объединить механику мышей с их укусами и вирусов.
• Хил для священника #1123 - запихать в священника немного функционала их медицины. Медицина - неоч простая штука, поэтому не простой, а средний.

Сюда относятся новые механики, иссуи которые требуют работу с БД или улучшения которые затрагивают сразу несколько областей разработки. Также к этой сложности можно отнести иссуи, которые объективно потребуют минимум 8 часов работы среднего разработчика (1 свободный день).

Примеры:

• Вернуть классическую базу данных СБ #1020 - скопипастить код из старого билда, интегрировать в новый код программ
• Революция: захват областей #975 - новая механика
• Механика варнингов #1247 - новая механика
• Рефакторинг /decl/observ/proc/raise_event #1953 - оптимизация системы ивентов, которая много где используется и требует аккуратности

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

Примеры:

• Возможность автоджоббана для АВД #997 - новая механика, работа с БД, пилить сложные формы, интерфейсы пилить. Тут мб даже имело смысл обновить сложность до нереальной, т.к. слишком много всего.

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

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

• Простой - < часа
• Обычный баг - 1-2 часа
• Сложный баг - 4 часа
• Очень сложный баг - 8 часов
• Нереальный баг - > 1 дня