ZecHub

Зробити внесок

Пишіть · Перекладайте · Проєктуйте · Розробляйте

Зробити внесок:

Розсилка ZecWeekly

ZecWeekly — це розсилка, яка виходить щонеділі вранці. Вона містить усі новини, що відбулися протягом тижня в екосистемі Zcash. Новини щотижня відбираються членами спільноти, а всі відповідні посилання додаються до розсилки. Будь ласка, підпишіться на розсилку тут.

Зробити внесок

Найкраще працювати над внесками до розсилки, коли один учасник готує випуск за відповідний тиждень, стежить за поточним обговоренням винагороди або координації та надсилає pull request після того, як щотижневі посилання готові. Будь ласка, не надсилайте майбутній випуск до того, як ZecHub опублікує або підтвердить дату цього випуску. Ранні pull request часто не містять оновлень наприкінці тижня, конфліктують із призначеним куратором або мають неправильний дедлайн.

1. Підтвердіть поточний випуск

Перш ніж почати писати:

Перевірте ZEC Bounties щодо поточного завдання для розсилки.
Дочекайтеся призначення.
Випуски розсилки належать до діапазону XS у політиці щодо сум винагород. Значення ZEC в активній винагороді — це сума, а не будь-який старіший заголовок у посібниках з участі.

2. Зробіть форк репозиторію

Якщо ви новачок у GitHub, використовуйте цей робочий процес:

Відкрийте репозиторій ZecHub.
Натисніть Fork і створіть форк у своєму обліковому записі GitHub.
У своєму форку створіть нову гілку для випуску. Зрозуміла назва гілки буде корисною, наприклад digest-may-30-2026.
Переконайтеся, що ваш pull request буде спрямований на ZecHub/zechub як базовий репозиторій і на main як базову гілку.

Якщо ви використовуєте командний рядок, той самий робочий процес виглядає так:

Code-highlight

git clone https://github.com/YOUR-USERNAME/zechub.git
cd zechub
git checkout -b digest-month-day-year

Замініть YOUR-USERNAME на власне ім’я користувача GitHub. URL-адреса вище є заповнювачем і в такому вигляді не працюватиме.

3. Створіть файл розсилки

Використовуйте шаблон розсилки як відправну точку. Випуски розсилки мають зберігатися в папці newsletter.

Створюючи файл:

Дотримуйтеся формату назви файлу, зазначеного в issue або використаного в нещодавно прийнятих випусках.
Зберігайте той самий порядок розділів, що й у шаблоні, якщо завдання не вимагає іншого формату.
Додавайте посилання лише за відповідний тиждень.
Пишіть короткий і зрозумілий опис для кожного посилання, щоб читачі розуміли його важливість.
За потреби перекладайте або узагальнюйте неангломовні джерела англійською.
Перевірте кожне посилання перед відкриттям pull request.

4. Збирайте посилання у відповідний час

ZecWeekly зазвичай охоплює активність екосистеми Zcash за поточний тиждень і публікується наприкінці тижня. Найбезпечніший графік:

Починайте збирати посилання після публікації поточного випуску або завдання розсилки.
Ведіть чернетку, поки тиждень ще триває.
Надсилайте pull request близько до запитуваної дати подання, після перевірки оновлень наприкінці тижня.
Не надсилайте розсилку за майбутній тиждень до появи завдання на цю дату або до підтвердження ZecHub, що вам слід її підготувати.

Якщо в issue зазначено, що потрібно подати матеріал до певної дати, дотримуйтеся цієї дати. Якщо між цією сторінкою та поточним issue є суперечність, дотримуйтеся поточного issue.

5. Відкрийте pull request

Коли файл вашої розсилки готовий:

Зробіть commit своїх змін у форку.
Відкрийте pull request до ZecHub/zechub у гілку main.
Використайте назву, що відповідає випуску, наприклад Zcash Ecosystem Digest | May 30th.
Додайте посилання на issue в тілі pull request, щоб рецензенти могли пов’язати роботу із завданням.

Приклад тіла pull request:

Code-highlight

Closes #ISSUE_NUMBER

Summary:
- Adds the Zcash Ecosystem Digest for Month Day.
- Uses the newsletter template and the current issue deadline.
- Checks links and descriptions for the requested week.

Після відкриття pull request стежте за коментарями рецензентів. Якщо ZecHub попросить внести зміни, оновіть ту саму гілку замість відкриття другого pull request для того самого випуску.

Реальні приклади

Використовуйте ці злиті pull request розсилки як приклади прийнятих подань:

Merged ZecWeekly newsletter pull request example

Порівнюючи свою роботу з прикладом, зосередьтеся на розташуванні файлу, форматі назви, порядку розділів, описах посилань і тому, чи pull request посилається на правильне завдання.

Поширені помилки, яких слід уникати

Відкриття pull request до підтвердження дати випуску або завдання.
Робота над issue, який уже має пов’язаний pull request.
Надсилання pull request до власного форку замість ZecHub/zechub.
Використання неправильної назви файлу або розміщення файлу поза папкою newsletter.
Копіювання старого випуску без оновлення кожної дати, посилання й опису.
Додавання посилань за неправильний тиждень.
Залишення непрацюючих чи дубльованих посилань або тексту-заповнювача із шаблону.
Відкриття нового pull request після коментарів рецензентів замість оновлення початкової гілки.

Фінальний контрольний список

Перш ніж запитувати рецензію, переконайтеся, що:

Дата issue або завдання відповідає файлу вашої розсилки.
Жоден інший відкритий pull request уже не охоплює той самий issue або випуск.
Файл міститься в папці newsletter.
Розділи шаблону заповнені.
Кожне посилання працює та має корисний опис.
Тіло pull request містить посилання на правильний issue.
Ви готові внести зміни, якщо рецензенти їх запросять.

Попередні випуски

Архів ZecWeekly

Навігація

Зробити внесок:

Розсилка ZecWeekly

Зробити внесок

1. Підтвердіть поточний випуск

2. Зробіть форк репозиторію

3. Створіть файл розсилки

4. Збирайте посилання у відповідний час

5. Відкрийте pull request

Реальні приклади

Поширені помилки, яких слід уникати

Фінальний контрольний список

Попередні випуски

Розсилка ZecWeekly

Зробити внесок

1. Підтвердіть поточний випуск

2. Зробіть форк репозиторію

3. Створіть файл розсилки

4. Збирайте посилання у відповідний час

5. Відкрийте pull request

Реальні приклади

Поширені помилки, яких слід уникати

Фінальний контрольний список

Попередні випуски