Ви виконали завдання, перевірили деталі й готові надіслати результат. Це той етап, де найчастіше втрачають винагороду не через слабку роботу, а через формальні помилки подання. Нижче — конкретні кроки, які допоможуть уникнути відмови й подати результат так, як очікують організатори.

Формат подання: що вимагають організатори

Кожен bounty має власні правила подання, і ваш перший крок — прочитати їх повністю, а не пробігти оком. Формат залежить від типу завдання, але є загальні вимоги, які зустрічаються майже скрізь.

Де шукати інструкцію

  • Опис bounty на платформі (Dework, OnlyDust, Superteam Earn чи інша).
  • Репозиторій проєкту на GitHub — файл README, папка contributing або окремий документ із умовами.
  • Discord-канал проєкту, розділ #bounties або #contributions.

Якщо інструкція суперечить сама собі в різних місцях, запитайте організаторів у Discord і зафіксуйте відповідь. Це убезпечить вас у разі спірних ситуацій.

Що зазвичай вимагають за типом роботи

Тип bounty Типовий формат подання
Код (Rust, Anchor, TypeScript) Pull request у вказану гілку, опис змін у PR, посилання на тестове покриття або скріншоти результату
Дизайн (UI, ілюстрації, брендинг) Figma-файл із доступом за посиланням, експорт у PNG/SVG, короткий опис рішень
Контент (статті, переклади, документація) Google Doc або Markdown-файл, зазначена кількість слів, дотримання style guide проєкту
Відео (навчальні посібники, огляди) Посилання на відео (YouTube, Loom), опис структури, тривалість згідно з вимогами
Community та маркетинг Скріншоти проведеної роботи, посилання на пости, звіт із метриками (охоплення, кількість учасників)

Памʼятайте: bounty — це часто конкурс. Організатор може прийняти кілька робіт, одну або жодної. Формат подання — це не формальність, а частина оцінки. Якщо ви проігноруєте вимоги до формату, вашу роботу можуть не розглядати взагалі.

Типові причини відмови

Більшість відмов не повʼязані з тим, що ви недостатньо вправні. Вони повʼязані з тим, як ви подали результат.

  • Не та гілка або не той репозиторій. Pull request відкритий у main замість вказаної гілки, або взагалі в інший репозиторій проєкту.
  • Відсутність опису змін. PR без коментаря — це чорна діра для ревʼюера. Навіть якщо код працює, без пояснень його можуть просто закрити.
  • Проігнорований style guide. Проєкт вказав шрифти, кольори, голос або структуру — ви зробили по-своєму. Для контенту це означає неправильний тон, для дизайну — відступ від брендбуку.
  • Неповний результат. Замість трьох запитаних екранів надіслано один. Замість статті на 1500 слів — на 800. Навіть якщо якість висока, завдання не виконано.
  • Порушення дедлайну. Подання після вказаної дати автоматично не розглядається у більшості випадків.
  • Плагіат або повторне використання роботи. Якщо ви подаєте матеріал, який уже публікували раніше для іншого проєкту, це майже гарантована відмова.
  • Немає звʼязку з вашим профілем. Ви подали роботу анонімно або з тимчасового акаунта, тоді як організатори вимагали привʼязку до Discord-профілю або гаманця.

Ці помилки виглядають дрібницями, але для організаторів вони є сигналом: людина не читала умови або не вміє працювати в команді.

Як перевірити свою роботу перед поданням

Не надсилайте результат одразу після завершення. Виділіть 15–30 хвилин на фінальну перевірку за чек-листом.

Загальна перевірка

  1. Перечитайте умови bounty ще раз. Відкрийте опис і проговоріть кожен пункт: чи виконано саме це?
  2. Перевірте формат. Вимагали Markdown — надішліть Markdown, не Google Doc. Вимагали PR у конкретну гілку — перевірте, куди ви відкрили PR.
  3. Перевірте повноту. Порівняйте свій результат із переліком очікуваних deliverables у завданні.
  4. Перевірте дедлайн. Зверніть увагу на часову зону, яку вказали організатори (UTC, EST тощо).

Перевірка за типом роботи

  • Код: запустіть тести локально, переконайтеся, що збірка проходить без помилок, перевірте, чи немає закоментованих фрагментів і console.log.
  • Дизайн: перевірте, чи всі шари названі зрозуміло, чи є експортні рамки, чи відповідають кольори й шрифти брендбуку.
  • Контент: прочитайте вголос, перевірте граматику, порахуйте слова, переконайтеся, що дотримано вказаний стиль і структуру.
  • Відео: перевірте звук, тривалість, чи видно інтерфейс, чи є вказані елементи (вступ, висновок, заклик до дії, якщо вимагали).
  • Community: переконайтеся, що скріншоти читабельні, посилання працюють, метрики підтверджені.

Фінальний тест «свіжим поглядом»

Відійдіть від роботи на 10–15 хвилин, а потім подивіться на неї так, ніби ви ревʼюер, який бачить її вперше. Чи зрозуміло, що саме ви зробили? Чи відповідає результат опису в PR чи коментарі? Якщо сумніваєтесь — уточніть або доповніть.

Що робити після подання

Подання результату — це не фініш, а перехід до етапу комунікації. Те, як ви поводитеся після відправки, впливає на репутацію не менше, ніж сама робота.

Перші дні після подання

  • Зачекайте розумний термін. Залежно від проєкту, розгляд може зайняти від кількох днів до двох тижнів. Якщо в умовах не вказано інше, не пишіть організаторам першого ж дня.
  • Слідкуйте за своїм PR або коментарем. Якщо ревʼюер залишив зауваження — реагуйте оперативно. Ігнорування коментарів до PR часто призводить до закриття завдання.
  • Будьте готові до правок. Просити внести зміни — це нормально, не означає, що вашу роботу відхилили. Відповідайте конструктивно, виправляйте й коментуйте, що саме змінено.

Якщо отримали відмову

Відмова — це не кінець, а інформація. Запитайте конкретну причину, якщо її не пояснили: що саме не відповідає вимогам, що можна покращити. Запишіть собі цей зворотний звʼязок — він стане частиною вашого професійного розвитку.

Не сперечайтеся з організаторами, навіть якщо ви впевнені у своїй правоті. Спокійний запит на уточнення створює враження професіонала. Емоційна реакція — навпаки.

Якщо результат прийнято

  • Переконайтеся, що отримали винагороду згідно з умовами (перевірте гаманець, переказ).
  • Запитайте дозвіл додати роботу до портфоліо й уточніть, як правильно зазначити проєкт.
  • Подякуйте організаторам у відповідному каналі — це простий крок, який запамʼятовується.
  • Зафіксуйте результат у своєму портфоліо: що зробили, який був процес, що навчилися.

Кожне подане bounty — це не лише спроба отримати винагороду, а й тренування професійної комунікації. Чим точніше ви подаєте результат і чемніше реагуєте на зворотний звʼязок, тим швидше переходите від разових завдань до постійної співпраці з командою.

Джерела