From c2822d280ad41490583d571c5bb820760fd248a0 Mon Sep 17 00:00:00 2001 From: Oleksandr Kovalchuk Date: Mon, 20 Feb 2017 23:01:26 +0200 Subject: [PATCH 01/14] Translate the first section of best-practices.md Translate the first section "what does it mean to be a maintainer" into Ukrainian --- _articles/uk-UA/best-practices.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/_articles/uk-UA/best-practices.md b/_articles/uk-UA/best-practices.md index 851d62c77c0..4aae4d51590 100644 --- a/_articles/uk-UA/best-practices.md +++ b/_articles/uk-UA/best-practices.md @@ -1,10 +1,10 @@ --- -locale: en-US -title: Best Practices for Maintainers -description: Making your life easier as an open source maintainer, from documenting processes to leveraging your community. +locale: uk-UA +title: Найкращі практики для супроводжуючих. +description: 'Зробіть своє життя, як супроводжуючого проекту з відкритим джерельним кодом, простішим: від документування процесів до використання спільноти.' class: best-practices toc: - what-does-it-mean-to-be-a-maintainer: "What does it mean to be a maintainer?" + what-does-it-mean-to-be-a-maintainer: "Що означає бути супроводжуючим?" documenting-your-processes: "Documenting your processes" learning-to-say-no: "Learning to say no" leverage-your-community: "Leverage your community" @@ -14,13 +14,13 @@ order: 5 image: /assets/images/cards/best-practices.png --- -## What does it mean to be a maintainer? +## Що означає бути супроводжуючим? -If you maintain an open source project that a lot of people use, you may have noticed you're coding less and responding to issues more. +Якщо ви супроводжуєте проект з відкритим джерельним кодом, який використовує чимало людей, ви помітите, що починаєте менше писати код і більше відповідати на інциденти. -In the early stages of a project, you're experimenting with new ideas and making decisions based on what you want. As your project increases in popularity, you'll find yourself working with your users and contributors more. +На ранніх етапах проекту ви експериментуєте з новими ідеями та прймаєте рішення, виходячи зі своїх бажань. Як тільки популярність проекту зросте, ви більше співпрацюватимете зі своїми користувачами та учасниками. -Maintaining a project requires more than code. These tasks are often unexpected, but they're just as important to a growing project. We've gathered a few ways to make your life easier, from documenting processes to leveraging your community. +Супровід проекту вимагає чогось більшого, ніж написання коду. Ці задачі часто непередбачувані, втім вони не менш важливі для проекту, що розвивається. Ми зібрали декілька способів, які полегшать ваше життя: від документування процесів до використання своєї спільноти. ## Documenting your processes From 3a41771ce551e4a31c089745af71f11e210d2c0f Mon Sep 17 00:00:00 2001 From: Oleksandr Kovalchuk Date: Tue, 21 Feb 2017 22:49:58 +0200 Subject: [PATCH 02/14] Use proper terms within translation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit супроводжуючий -> супровідник з відкритим джерельним кодом -> open-source --- _articles/uk-UA/best-practices.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/_articles/uk-UA/best-practices.md b/_articles/uk-UA/best-practices.md index 4aae4d51590..0574ef077df 100644 --- a/_articles/uk-UA/best-practices.md +++ b/_articles/uk-UA/best-practices.md @@ -1,10 +1,10 @@ --- locale: uk-UA -title: Найкращі практики для супроводжуючих. -description: 'Зробіть своє життя, як супроводжуючого проекту з відкритим джерельним кодом, простішим: від документування процесів до використання спільноти.' +title: Найкращі практики для супровідників. +description: 'Зробіть своє життя, як супровідника open-source проекту, простішим: від документування процесів до використання спільноти.' class: best-practices toc: - what-does-it-mean-to-be-a-maintainer: "Що означає бути супроводжуючим?" + Що-означає-бути-супровідником: "Що означає бути супровідником?" documenting-your-processes: "Documenting your processes" learning-to-say-no: "Learning to say no" leverage-your-community: "Leverage your community" @@ -14,9 +14,9 @@ order: 5 image: /assets/images/cards/best-practices.png --- -## Що означає бути супроводжуючим? +## Що означає бути супровідником? -Якщо ви супроводжуєте проект з відкритим джерельним кодом, який використовує чимало людей, ви помітите, що починаєте менше писати код і більше відповідати на інциденти. +Якщо ви супроводжуєте open-source проект, який використовує чимало людей, ви помітите, що починаєте менше писати код і більше відповідати на інциденти. На ранніх етапах проекту ви експериментуєте з новими ідеями та прймаєте рішення, виходячи зі своїх бажань. Як тільки популярність проекту зросте, ви більше співпрацюватимете зі своїми користувачами та учасниками. From 3a8ae8a4f5982582c4bb73327794b545fdf31983 Mon Sep 17 00:00:00 2001 From: Oleksandr Kovalchuk Date: Wed, 22 Feb 2017 01:30:28 +0200 Subject: [PATCH 03/14] Translate the second section of best-practices.md Document your processes --- _articles/uk-UA/best-practices.md | 60 +++++++++++++++---------------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/_articles/uk-UA/best-practices.md b/_articles/uk-UA/best-practices.md index 0574ef077df..c550ca72892 100644 --- a/_articles/uk-UA/best-practices.md +++ b/_articles/uk-UA/best-practices.md @@ -1,11 +1,11 @@ --- locale: uk-UA title: Найкращі практики для супровідників. -description: 'Зробіть своє життя, як супровідника open-source проекту, простішим: від документування процесів до використання спільноти.' +description: 'Зробіть своє життя, як супровідника open source проекту, простішим: від документування процесів до використання спільноти.' class: best-practices toc: Що-означає-бути-супровідником: "Що означає бути супровідником?" - documenting-your-processes: "Documenting your processes" + Задокументуйте-свої-процеси: "Задокументуйте свої процеси" learning-to-say-no: "Learning to say no" leverage-your-community: "Leverage your community" bring-in-the-robots: "Bring in the robots" @@ -16,66 +16,66 @@ image: /assets/images/cards/best-practices.png ## Що означає бути супровідником? -Якщо ви супроводжуєте open-source проект, який використовує чимало людей, ви помітите, що починаєте менше писати код і більше відповідати на інциденти. +Якщо ви супроводжуєте open source проект, який використовує чимало людей, ви помітите, що починаєте менше писати код і більше відповідати на інциденти (issues). На ранніх етапах проекту ви експериментуєте з новими ідеями та прймаєте рішення, виходячи зі своїх бажань. Як тільки популярність проекту зросте, ви більше співпрацюватимете зі своїми користувачами та учасниками. Супровід проекту вимагає чогось більшого, ніж написання коду. Ці задачі часто непередбачувані, втім вони не менш важливі для проекту, що розвивається. Ми зібрали декілька способів, які полегшать ваше життя: від документування процесів до використання своєї спільноти. -## Documenting your processes +## Задокументуйте свої процеси -Writing things down is one of the most important things you can do as a maintainer. +Записувати різні речі — це одна з найважливіших речей, що ви, як супровідник, можете зробити. -Documentation not only clarifies your own thinking, but it helps other people understand what you need or expect, before they even ask. +Документування не лише допоможе вам краще сформулювати думки, а також допоможе іншим людям зрозуміти, що їм потрібно або чого очікувати, ще до того, як вони спитають. -Writing things down makes it easier to say no when something doesn't fit into your scope. It also makes it easier for people to pitch in and help. You never know who might be reading or using your project. +Записування спростить відмову, якщо щось не входить у ваші рамки. Також це допоможе іншим зробити перший крок і приєднатися до співпраці. Ви ніколи не знаєте, хто читає чи використовує ваш проект. -Even if you don't use full paragraphs, jotting down bullet points is better than not writing at all. +Якщо ви не пишете розгорнуті абзаци, занотовувати основні моменти все одно краще, ніж не писати узагалі нічого. -### Write down your project's vision +### Запишіть своє бачення проекту -Start by writing down the goals of your project. Add them to your README, or create a separate file called VISION. If there are other artifacts that could help, like a project roadmap, make those public as well. +Для початку запишіть мету свого проекту. Додайте її до файлу README або створіть окремий файл із назвою VISION (БАЧЕННЯ). Якщо є й інші матеріали, які можуть допомогти (наприклад, дорожня карта проекту), зробіть їх також публічними. -Having a clear, documented vision keeps you focused and helps you avoid "scope creep" from others' contributions. +Наявність чіткого, задокументованого бачення дозволить вам залишатися сфокусованим та уникнути так званого "посунення рамок" внаслідок внесків (contributions) інших людей. -For example, @lord discovered that having a project vision helped him figure out which requests to spend time on. As a new maintainer, he regretted not sticking to his project's scope when he got his first feature request for [Slate](https://github.com/lord/slate). +Наприклад, @lord зрозумів, що наявність бачення проекту допомагає йому визначатися, на які запити витрачати час. Він, як новий супровідник, шкодує, що не притримувався рамок проекту, коли отримав перший запит щодо [Slate](htts://github.com/lord/slate). -### Communicate your expectations +### Повідомляйте про свої очікування -Rules can be nerve-wracking to write down. Sometimes you might feel like you're policing other people's behavior or killing all the fun. +Написання правил часто дратує. Інколи ви навіть можете почуватися наче контролюєте поведінку інших людей або псуєте їм усі веселощі. -Written and enforced fairly, however, good rules empower maintainers. They prevent you from getting dragged into doing things you don't want to do. +Втім, записані та чесно застосовувані, хороші правила посилюють супровідників. Вони не дають вам бути затягнутим у ті речі, які ви не бажаєте робити. -Most people who come across your project don't know anything about you or your circumstances. They may assume you get paid to work on it, especially if it's something they regularly use and depend on. Maybe at one point you put a lot of time into your project, but now you're busy with a new job or family member. +Більшість із тих людей, які знаходять ваш проект, нічого не знають ані про вас, ані про ваші обставини. Вони можуть вважати, що ви отримуєте платню за роботу над проектом, особливо якщо самі цим частенько послуговуються і залежать від цього. Можливо, ви колись приділяли багато часу своєму проекту, але зараз сильно зайняті на новій роботі або з новим членом своєї сім'ї. -All of this is perfectly okay! Just make sure other people know about it. +Це цілком нормально! Лишень переконайтеся, що інші люди знають про це. -If maintaining your project is part-time or purely volunteered, be honest about how much time you have. This is not the same as how much time you think the project requires, or how much time others want you to spend. +Якщо супровід проекту відбувається час від часу або цілком на волонтерських засадах, будьте чесними щодо того, скільки часу ви маєте. Це не те саме, що і час, який, на вашу думку, цей проект потребує, або час, який ви хотіли б на нього витрачати. -Here are a few rules that are worth writing down: +Ось декільки правил, які варто написати: -* How a contribution is reviewed and accepted (_Do they need tests? An issue template?_) -* The types of contributions you'll accept (_Do you only want help with a certain part of your code?_) -* When it's appropriate to follow up (_ex. "You can expect a response from a maintainer within 7 days. If you haven't heard anything by then, feel free to ping the thread."_) -* How much time you spend on the project (_ex. "We only spend about 5 hours per week on this project"_) +* Як розглядаються та приймаються внески (_Чи потрібні тести? Шаблон для створення інциденту?_) +* Види внесків, які ви приймете (_Можливо, ви бажаєте допомоги лише з конкретним фрагментом вашого коду?_) +* Коли доречно повторювати запит (_напр. "Очікуйте відповідь від супровідника протягом 7 днів. Якщо до того часу ви нічого не почуєте, не соромтеся нагадати про себе в обговоренні."_) +* Скільки часу ви приділяєте проекту (_напр. "Цьому проекту ми приділяємо приблизно 5 годин на тиждень"_) -[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) are several examples of projects with ground rules for maintainers and contributors. +[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), та [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md), — ось декілька прикладів проектів, що мають основоположні правила для супровідників та учасників. -### Keep communication public +### Комунікуйте публічно -Don't forget to document your interactions, too. Wherever you can, keep communication about your project public. If somebody tries to contact you privately to discuss a feature request or support need, politely direct them to a public communication channel, such as a mailing list or issue tracker. +Не забудьте записувати і взаємодії також. Усюди, де це можна, тримайте комунікації щодо проекту публічними. Хтось намагається написати вам особисто для обговорення функціональності або необхідної допомоги — ввічливо направте їх у публічний канал обговорень, такий як поштова розсилка або реєстр інцидентів (issue tracker). -If you meet with other maintainers, or make a major decision in private, document these conversations in public, even if it's just posting your notes. +Якщо ви особисто зустрічаєтеся з іншими супровідниками або приймаєте важливі рішення, задокументуйте ці обговорення публічно, навіть якщо це лише публікування ваших нотаток. -That way, anybody who joins your community will have access to the same information as someone who's been there for years. +Таким чином, будь-хто, хто долучиться до вашої спільноти, володітиме тією ж інформацією, що й людина, яка брала участь у проекті впродовж років. ## Learning to say no From 057706fadc39f1e54582265ee5bbd349faf4db19 Mon Sep 17 00:00:00 2001 From: Oleksandr Kovalchuk Date: Wed, 22 Feb 2017 11:40:52 +0200 Subject: [PATCH 04/14] Improve translation of the second section Better translation for part-time or purely volounteering --- _articles/uk-UA/best-practices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_articles/uk-UA/best-practices.md b/_articles/uk-UA/best-practices.md index c550ca72892..717d26c43ae 100644 --- a/_articles/uk-UA/best-practices.md +++ b/_articles/uk-UA/best-practices.md @@ -58,7 +58,7 @@ image: /assets/images/cards/best-practices.png Це цілком нормально! Лишень переконайтеся, що інші люди знають про це. -Якщо супровід проекту відбувається час від часу або цілком на волонтерських засадах, будьте чесними щодо того, скільки часу ви маєте. Це не те саме, що і час, який, на вашу думку, цей проект потребує, або час, який ви хотіли б на нього витрачати. +Якщо супровід проекту відбувається частково або повністю на волонтерських засадах, будьте чесними щодо того, скільки часу ви маєте. Це не те саме, що і час, який, на вашу думку, цей проект потребує, або час, який ви хотіли б на нього витрачати. Ось декільки правил, які варто написати: From 09c11a779acbb6356252c91823ed276c24d83fc0 Mon Sep 17 00:00:00 2001 From: Oleksandr Kovalchuk Date: Fri, 3 Mar 2017 01:25:08 +0200 Subject: [PATCH 05/14] Translate subsection 1 of Learning to Say no section Translate the introduction paragraphs in "Learning to say no" section --- _articles/uk-UA/best-practices.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/_articles/uk-UA/best-practices.md b/_articles/uk-UA/best-practices.md index 717d26c43ae..4f9ae79f829 100644 --- a/_articles/uk-UA/best-practices.md +++ b/_articles/uk-UA/best-practices.md @@ -6,7 +6,7 @@ class: best-practices toc: Що-означає-бути-супровідником: "Що означає бути супровідником?" Задокументуйте-свої-процеси: "Задокументуйте свої процеси" - learning-to-say-no: "Learning to say no" + Навчіться-казати-ні: "Навчіться казати «ні»" leverage-your-community: "Leverage your community" bring-in-the-robots: "Bring in the robots" its-okay-to-hit-pause: "It’s okay to hit pause" @@ -77,15 +77,15 @@ image: /assets/images/cards/best-practices.png Таким чином, будь-хто, хто долучиться до вашої спільноти, володітиме тією ж інформацією, що й людина, яка брала участь у проекті впродовж років. -## Learning to say no +## Навчіться казати «ні» -You've written things down. Ideally, everybody would read your documentation, but in reality, you'll have to remind others that this knowledge exists. +Отже, ви все записали. В ідеальному світі усі прочитають вашу документацію, але в реальному вам доведеться нагадувати іншим про існування цих знань. -Having everything written down, however, helps depersonalize situations when you do need to enforce your rules. +Утім, наявність інформації у письмовому вигляді дає можливість знеособити ситуації, коли вам необхідно забезпечити дотримання правил. -Saying no isn't fun, but _"Your contribution doesn't match this project's criteria"_ feels less personal than _"I don't like your contribution"_. +Непросто казати «ні». Але відповідь _"Ваш внесок не відповідає критеріям проекту"_ є менш особистою, ніж _"Мені не до вподоби ваш внесок"_. -Saying no applies to many situations you'll come across as a maintainer: feature requests that don't fit the scope, someone derailing a discussion, doing unnecessary work for others. +Вам доведеться казати «ні» у багатьох ситуаціях, з якими ви, як супровідник, будете мати справу. Наприклад, запити функціоналу, які виходять за рамки проекту; люди, котрі зводять обговорення нанівець; виконання непотрібної роботи для інших. ### Keep the conversation friendly From f76db1a51bf56b18499db0cca528bf805e674c3c Mon Sep 17 00:00:00 2001 From: Oleksandr Kovalchuk Date: Sun, 12 Mar 2017 01:06:01 +0200 Subject: [PATCH 06/14] Use locale folders for image assets --- _articles/en-US/best-practices.md | 2 +- _articles/en-US/building-community.md | 8 ++++---- _articles/en-US/finding-users.md | 8 ++++---- _articles/en-US/legal.md | 2 +- _articles/en-US/metrics.md | 6 +++--- _articles/en-US/starting-a-project.md | 4 ++-- _articles/uk-UA/building-community.md | 8 ++++---- _articles/uk-UA/finding-users.md | 8 ++++---- _articles/uk-UA/legal.md | 2 +- _articles/uk-UA/metrics.md | 6 +++--- _articles/uk-UA/starting-a-project.md | 4 ++-- .../{ => en-US}/best-practices/celery.png | Bin .../contributor_funnel_mikemcquaid.png | Bin .../cookiecutter_submit_pr.png | Bin .../django_new_contributors.png | Bin .../building-community/middleman_pr.png | Bin .../{ => en-US}/finding-users/cartography.jpg | Bin .../images/{ => en-US}/finding-users/lena.jpg | Bin .../finding-users/public_speaking.jpg | Bin .../finding-users/vagrant_homepage.png | Bin .../{ => en-US}/legal/repo-create-name.png | Bin .../images/{ => en-US}/metrics/clone_graph.png | Bin .../repo_contributors_specific_graph.png | Bin .../metrics/repo_traffic_graphs_tooltip.png | Bin .../Contributing-guidelines.jpg | Bin .../repository-license-picker.png | Bin assets/images/uk-UA/best-practices/celery.png | Bin 0 -> 21930 bytes .../contributor_funnel_mikemcquaid.png | Bin 0 -> 123483 bytes .../cookiecutter_submit_pr.png | Bin 0 -> 75327 bytes .../django_new_contributors.png | Bin 0 -> 71018 bytes .../uk-UA/building-community/middleman_pr.png | Bin 0 -> 170564 bytes .../images/uk-UA/finding-users/cartography.jpg | Bin 0 -> 345965 bytes assets/images/uk-UA/finding-users/lena.jpg | Bin 0 -> 28638 bytes .../uk-UA/finding-users/public_speaking.jpg | Bin 0 -> 93499 bytes .../uk-UA/finding-users/vagrant_homepage.png | Bin 0 -> 218015 bytes assets/images/uk-UA/legal/repo-create-name.png | Bin 0 -> 31792 bytes assets/images/uk-UA/metrics/clone_graph.png | Bin 0 -> 62384 bytes .../repo_contributors_specific_graph.png | Bin 0 -> 34511 bytes .../metrics/repo_traffic_graphs_tooltip.png | Bin 0 -> 56140 bytes .../Contributing-guidelines.jpg | Bin 0 -> 27803 bytes .../repository-license-picker.png | Bin 0 -> 21417 bytes 41 files changed, 29 insertions(+), 29 deletions(-) rename assets/images/{ => en-US}/best-practices/celery.png (100%) rename assets/images/{ => en-US}/building-community/contributor_funnel_mikemcquaid.png (100%) rename assets/images/{ => en-US}/building-community/cookiecutter_submit_pr.png (100%) rename assets/images/{ => en-US}/building-community/django_new_contributors.png (100%) rename assets/images/{ => en-US}/building-community/middleman_pr.png (100%) rename assets/images/{ => en-US}/finding-users/cartography.jpg (100%) rename assets/images/{ => en-US}/finding-users/lena.jpg (100%) rename assets/images/{ => en-US}/finding-users/public_speaking.jpg (100%) rename assets/images/{ => en-US}/finding-users/vagrant_homepage.png (100%) rename assets/images/{ => en-US}/legal/repo-create-name.png (100%) rename assets/images/{ => en-US}/metrics/clone_graph.png (100%) rename assets/images/{ => en-US}/metrics/repo_contributors_specific_graph.png (100%) rename assets/images/{ => en-US}/metrics/repo_traffic_graphs_tooltip.png (100%) rename assets/images/{ => en-US}/starting-a-project/Contributing-guidelines.jpg (100%) rename assets/images/{ => en-US}/starting-a-project/repository-license-picker.png (100%) create mode 100644 assets/images/uk-UA/best-practices/celery.png create mode 100644 assets/images/uk-UA/building-community/contributor_funnel_mikemcquaid.png create mode 100644 assets/images/uk-UA/building-community/cookiecutter_submit_pr.png create mode 100644 assets/images/uk-UA/building-community/django_new_contributors.png create mode 100644 assets/images/uk-UA/building-community/middleman_pr.png create mode 100644 assets/images/uk-UA/finding-users/cartography.jpg create mode 100644 assets/images/uk-UA/finding-users/lena.jpg create mode 100644 assets/images/uk-UA/finding-users/public_speaking.jpg create mode 100644 assets/images/uk-UA/finding-users/vagrant_homepage.png create mode 100644 assets/images/uk-UA/legal/repo-create-name.png create mode 100644 assets/images/uk-UA/metrics/clone_graph.png create mode 100644 assets/images/uk-UA/metrics/repo_contributors_specific_graph.png create mode 100644 assets/images/uk-UA/metrics/repo_traffic_graphs_tooltip.png create mode 100644 assets/images/uk-UA/starting-a-project/Contributing-guidelines.jpg create mode 100644 assets/images/uk-UA/starting-a-project/repository-license-picker.png diff --git a/_articles/en-US/best-practices.md b/_articles/en-US/best-practices.md index a25f505454c..613472faf79 100644 --- a/_articles/en-US/best-practices.md +++ b/_articles/en-US/best-practices.md @@ -120,7 +120,7 @@ If you don't want to accept a contribution: You shouldn't need more than 1-2 sentences to respond. For example, when a user of [celery](https://github.com/celery/celery/) reported a Windows-related error, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383): -![celery screenshot](/assets/images/best-practices/celery.png) +![celery screenshot](/assets/images/en-US/best-practices/celery.png) If the thought of saying no terrifies you, you're not alone. As @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/): diff --git a/_articles/en-US/building-community.md b/_articles/en-US/building-community.md index feea7a9928a..9c567b5dd86 100644 --- a/_articles/en-US/building-community.md +++ b/_articles/en-US/building-community.md @@ -21,7 +21,7 @@ A welcoming community is an investment into your project's future and reputation One way to think about your project's community is through what @MikeMcQuaid calls the [contributor funnel](https://speakerdeck.com/mikemcquaid/the-open-source-contributor-funnel): -![contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png) +![contributor funnel](/assets/images/en-US/building-community/contributor_funnel_mikemcquaid.png) As you build your community, consider how someone at the top of the funnel (a potential user) might theoretically make their way to the bottom (an active maintainer). Your goal is to reduce friction at each stage of the contributor experience. When people have easy wins, they will feel incentivized to do more. @@ -81,7 +81,7 @@ Try to be responsive when someone files an issue, submits a pull request, or ask Even if you can't review the request immediately, acknowledging it early helps increase engagement. Here's how @tdreyno responded to a pull request on [Middleman](https://github.com/middleman/middleman/pull/1466): -![middleman pull request](/assets/images/building-community/middleman_pr.png) +![middleman pull request](/assets/images/en-US/building-community/middleman_pr.png) [A Mozilla study found that](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) contributors who received code reviews within 48 hours had a much higher rate of return and repeat contribution. @@ -131,7 +131,7 @@ Good documentation only becomes more important as your community grows. Casual c In your CONTRIBUTING file, explicitly tell new contributors how to get started. You may even want to make a dedicated section for this purpose. [Django](https://github.com/django/django), for example, has a special landing page to welcome new contributors. -![django new contributors page](/assets/images/building-community/django_new_contributors.png) +![django new contributors page](/assets/images/en-US/building-community/django_new_contributors.png) In your issue queue, label bugs that are suitable for different types of contributors: for example, [_"first timers only"_](https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.g1k01jy05), _"good first bug"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) make it easy for someone new to your project to quickly scan your issues and get started. @@ -159,7 +159,7 @@ See if you can find ways to share ownership with your community as much as possi * **Resist fixing easy (non-critical) bugs.** Instead, use them as opportunities to recruit new contributors, or mentor someone who'd like to contribute. It may seem unnatural at first, but your investment will pay off over time. For example, @michaeljoseph asked a contributor to submit a pull request on a [Cookiecutter](https://github.com/audreyr/cookiecutter) issue below, rather than fix it himself. -![cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) +![cookiecutter issue](/assets/images/en-US/building-community/cookiecutter_submit_pr.png) * **Start a CONTRIBUTORS or AUTHORS file in your project** that lists everyone who's contributed to your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md) does. diff --git a/_articles/en-US/finding-users.md b/_articles/en-US/finding-users.md index e00ae2a158e..e470606d9ce 100644 --- a/_articles/en-US/finding-users.md +++ b/_articles/en-US/finding-users.md @@ -28,7 +28,7 @@ Remember that people get involved as users, and eventually contributors, because For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful: -![cartography readme](/assets/images/finding-users/cartography.jpg) +![cartography readme](/assets/images/en-US/finding-users/cartography.jpg) For a deeper diver into messaging, check out Mozilla's ["Personas and Pathways"](http://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas. @@ -61,7 +61,7 @@ If you don't wish to set up these channels for your project yet, promote your ow If your project is hosted on GitHub, you can use [GitHub Pages](https://pages.github.com/) to easily make a website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) are [a few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites. -![vagrant homepage](/assets/images/finding-users/vagrant_homepage.png) +![vagrant homepage](/assets/images/en-US/finding-users/vagrant_homepage.png) Now that you have a message for your project, and an easy way for people to find your project, let's get out there and talk to your audience! @@ -91,7 +91,7 @@ If nobody pays attention or responds to your initial outreach, don't get discour ## Go where your project's audience is (offline) -![public speaking](/assets/images/finding-users/public_speaking.jpg) +![public speaking](/assets/images/en-US/finding-users/public_speaking.jpg) Offline events are a popular way to promote new projects. It's a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers. @@ -110,7 +110,7 @@ If you've never spoken at an event before, it's perfectly normal to feel nervous As you write your talk, focus on what your audience will find interesting and get value out of. Keep your language friendly and approachable. Smile, breathe, and have fun.