diff --git a/_articles/uk-UA/building-community.md b/_articles/uk-UA/building-community.md
new file mode 100644
index 00000000000..feea7a9928a
--- /dev/null
+++ b/_articles/uk-UA/building-community.md
@@ -0,0 +1,276 @@
+---
+locale: en-US
+title: Building Welcoming Communities
+description: Building a community that encourages people to use, contribute to, and evangelize your project.
+class: building
+toc:
+ setting-your-project-up-for-success: "Setting your project up for success"
+ growing-your-community: "Growing your community"
+ resolving-conflicts: "Resolving conflicts"
+order: 4
+image: /assets/images/cards/building.png
+---
+
+## Setting your project up for success
+
+You've launched your project, you're spreading the word, and people are checking it out. Awesome! Now, how do you get them to stick around?
+
+A welcoming community is an investment into your project's future and reputation. If your project is just starting to see its first contributions, start by giving early contributors a positive experience, and make it easy for them to keep coming back.
+
+### Make people feel welcome
+
+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):
+
+
+
+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.
+
+Start with your documentation:
+
+* **Make it easy for someone to use your project.** [A friendly README](../starting-a-project/#writing-a-readme) and clear code examples will make it easier for anyone who lands on your project to get started.
+* **Clearly explain how to contribute**, using [your CONTRIBUTING file](../starting-a-project/#writing-your-contributing-guidelines) and keeping your issues up-to-date.
+
+Good documentation invites people to interact with your project. Eventually, someone will open an issue or pull request. Use these interactions as opportunities to move them down the funnel.
+
+* **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back.
+* **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project.
+* **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help.
+* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) it doesn't fit into the scope of the project, linking to relevant documentation if you have it.
+
+
+
+The majority of open source contributors are "casual contributors": people who contribute to a project only occasionally. A casual contributor may not have time to get fully up to speed with your project, so your job is to make it easy for them to contribute.
+
+Encouraging other contributors is an investment in yourself, too. When you empower your biggest fans to run with the work they're excited about, there's less pressure to do everything yourself.
+
+### Document everything
+
+
+
+When you start a new project, it may feel natural to keep your work private. But open source projects thrive when you document your process in public.
+
+When you write things down, more people can participate at every step of the way. You might get help on something you didn't even know you needed.
+
+Writing things down means more than just technical documentation. Any time you feel the urge to write something down or privately discuss your project, ask yourself whether you can make it public.
+
+Be transparent about your project's roadmap, the types of contributions you're looking for, how contributions are reviewed, or why you made certain decisions.
+
+If you notice multiple users running into the same problem, document the answers in the README.
+
+For meetings, consider publishing your notes or takeaways in a relevant issue. The feedback you'll get from this level of transparency may surprise you.
+
+Documenting everything applies to the work you do, too. If you're working on a substantial update to your project, put it into a pull request and mark it as a work in progress (WIP). That way, other people can feel involved in the process early on.
+
+### Be responsive
+
+As you [promote your project](../finding-users), people will have feedback for you. They may have questions about how things work, or need help getting started.
+
+Try to be responsive when someone files an issue, submits a pull request, or asks a question about your project. When you respond quickly, people will feel they are part of a dialogue, and they'll be more enthusiastic about participating.
+
+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):
+
+
+
+[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.
+
+Conversations about your project could also be happening in other places around the internet, such as Stack Overflow, Twitter, or Reddit. You can set up notifications in some of these places so you are alerted when someone mentions your project.
+
+### Give your community a place to congregate
+
+There are two reasons to give your community a place to congregate.
+
+The first reason is for them. Help people get to know each other. People with common interests will inevitably want a place to talk about it. And when communication is public and accessible, anybody can read past archives to get up to speed and participate.
+
+The second reason is for you. If you don't give people a public place to talk about your project, they will likely contact you directly. In the beginning, it may seem easy enough to respond to private messages "just this once". But over time, especially if your project becomes popular, you will feel exhausted. Resist the temptation to communicate with people about your project in private. Instead, direct them to a designated public channel.
+
+Public communication can be as simple as directing people to open an issue instead of emailing you directly or commenting on your blog. You could also set up a mailing list, or create a Twitter account, Slack, or IRC channel for people to talk about your project. Or try all of the above!
+
+[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) sets aside office hours every other week to help community members:
+
+> Kops also has time set aside every other week to offer help and guidance to the community. Kops maintainers have agreed to set aside time specifically dedicated to working with newcomers, helping with PRs, and discussing new features.
+
+Notable exceptions to public communication are: 1) security issues and 2) sensitive code of conduct violations. You should always have a way for people to report these issues privately. If you don't want to use your personal email, set up a dedicated email address.
+
+## Growing your community
+
+Communities are extremely powerful. That power can be a blessing or a curse, depending on how you wield it. As your project's community grows, there are ways to help it become a force of construction, not destruction.
+
+### Don't tolerate bad actors
+
+Any popular project will inevitably attract people who harm, rather than help, your community. They may start unnecessary debates, quibble over trivial features, or bully others.
+
+Do your best to adopt a zero-tolerance policy towards these types of people. If left unchecked, negative people will make other people in your community uncomfortable. They may even leave.
+
+
+
+Regular debates over trivial aspects of your project distracts others, including you, from focusing on important tasks. New people who arrive to your project may see these conversations and not want to participate.
+
+When you see negative behavior happening on your project, call it out publicly. Explain, in a kind but firm tone, why their behavior is not acceptable. If the problem persists, you may need to [ask them to leave](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) can be a constructive guide for these conversations.
+
+### Meet contributors where they're at
+
+Good documentation only becomes more important as your community grows. Casual contributors, who may not otherwise be familiar with your project, read your documentation to quickly get the context they need.
+
+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.
+
+
+
+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.
+
+Finally, use your documentation to make people feel welcome at every step of the way.
+
+You will never interact with most people who land on your project. There may be contributions you didn't receive because somebody felt intimidated or didn't know where to get started. Even a few kind words can keep someone from leaving your project in frustration.
+
+For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md):
+
+> We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue.
+
+### Share ownership of your project
+
+
+
+People are excited to contribute to projects when they feel a sense of ownership. That doesn't mean you need to turn over your project's vision or accept contributions you don't want. But the more you give credit to others, the more they'll stick around.
+
+See if you can find ways to share ownership with your community as much as possible. Here are some ideas:
+
+* **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.
+
+
+
+* **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.
+
+* If you've got a sizeable community, **send out a newsletter or write a blog post** thanking contributors. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) are two good examples.
+
+* **Give every contributor commit access.** @felixge found that this made people [more excited to polish their patches](http://felixge.de/2013/03/11/the-pull-request-hack.html), and he even found new maintainers for projects that he hadn't worked on in awhile.
+
+* If your project is on GitHub, **move your project from your personal account to an [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** and add at least one backup admin. Organizations make it easier to work on projects with external collaborators.
+
+The reality is that [most projects only have](https://peerj.com/preprints/1233.pdf) one or two maintainers who do most of the work. The bigger your project, and the bigger your community, the easier it is to find help.
+
+While you may not always find someone to answer the call, putting a signal out there increases the chances that other people will pitch in. And the earlier you start, the sooner people can help.
+
+
+
+## Resolving conflicts
+
+In the early stages of your project, making major decisions is easy. When you want to do something, you just do it.
+
+As your project becomes more popular, more people will take interest in the decisions you make. Even if you don't have a big community of contributors, if your project has a lot of users, you'll find people weighing in on decisions or raising issues of their own.
+
+For the most part, if you've cultivated a friendly, respectful community and documented your processes openly, your community should be able to find resolution. But sometimes you run into an issue that's a bit harder to address.
+
+### Set the bar for kindness
+
+When your community is grappling with a difficult issue, tempers may rise. People may become angry or frustrated and take it out on one another, or on you.
+
+Your job as a maintainer is to keep these situations from escalating. Even if you have a strong opinion on the topic, try to take the position of a moderator or facilitator, rather than jumping into the fight and pushing your views. If someone is being unkind or monopolizing the conversation, [act immediately](../building-community/#dont-tolerate-bad-actors) to keep discussions civil and productive.
+
+
+
+Other people are looking to you for guidance. Set a good example. You can still express disappointment, unhappiness, or concern, but do so calmly.
+
+Keeping your cool isn't easy, but demonstrating leadership improves the health of your community. The internet thanks you.
+
+### Treat your README as a constitution
+
+Your README is [more than just a set of instructions](../starting-a-project/#writing-a-readme). It's also a place to talk about your goals, product vision, and roadmap. If people are overly focused on debating the merit of a particular feature, it may help to revisit your README and talk about the higher vision of your project. Focusing on your README also depersonalizes the conversation, so you can have a constructive discussion.
+
+### Focus on the journey, not the destination
+
+Some projects use a voting process to make major decisions. While sensible at first glance, voting emphasizes getting to an "answer," rather than listening to and addressing each other's concerns.
+
+Voting can become political, where community members feel pressured to do each other favors or vote a certain way. Not everybody votes, either, whether it's the [silent majority](http://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in your community, or current users who didn't know a vote was taking place.
+
+Sometimes, voting is a necessary tiebreaker. As much as you are able, however, emphasize ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) rather than consensus.
+
+Under a consensus seeking process, community members discuss major concerns until they feel they have been adequately heard. When only minor concerns remain, the community moves forward. "Consensus seeking" acknowledges that a community may not be able to reach a perfect answer. Instead, it prioritizes listening and discussion.
+
+
+
+Even if you don't actually adopt a consensus seeking process, as a project maintainer, it's important that people know you are listening. Making other people feel heard, and committing to resolving their concerns, goes a long way to diffuse sensitive situations. Then, follow up on your words with actions.
+
+Don't rush into a decision for the sake of having a resolution. Make sure that everybody feels heard and that all information has been made public before moving toward a resolution.
+
+### Keep the conversation focused on action
+
+Discussion is important, but there is a difference between productive and unproductive conversations.
+
+Encourage discussion so long as it is actively moving towards resolution. If it's clear that conversation is languishing or going off-topic, jabs are getting personal, or people are quibbling about minor details, it's time to shut it down.
+
+Allowing these conversations to continue is not only bad for the issue at hand, but bad for the health of your community. It sends a message that these types of conversations are permitted or even encouraged, and it can discourage people from raising or resolving future issues.
+
+With every point made by you or by others, ask yourself, _"How does this bring us closer to a resolution?"_
+
+If the conversation is starting to unravel, ask the group, _"Which steps should we take next?"_ to refocus the conversation.
+
+If a conversation clearly isn't going anywhere, there are no clear actions to be taken, or the appropriate action has already been taken, close the issue and explain why you closed it.
+
+
+
+### Pick your battles wisely
+
+Context is important. Consider who is involved in the discussion and how they represent the rest of the community.
+
+Is everybody in the community upset about, or even engaged with, this issue? Or is a lone troublemaker? Don't forget to consider your silent community members, not just the active voices.
+
+If the issue does not represent the broader needs of your community, you may just need to acknowledge the concerns of a few people. If this is a recurring issue without a clear resolution, point them to previous discussions on the topic and close the thread.
+
+### Identify a community tiebreaker
+
+With a good attitude and clear communication, most difficult situations are resolvable. However, even in a productive conversation, there can simply be a difference in opinion on how to proceed. In these cases, identify an individual or group of people that can serve as a tiebreaker.
+
+A tiebreaker could be the primary maintainer of the project, or it could be a small group of people who make a decision based on voting. Ideally, you've identified a tiebreaker and the associated process in a GOVERNANCE file before you ever have to use it.
+
+Your tiebreaker should be a last resort. Divisive issues are an opportunity for your community to grow and learn. Embrace these opportunities and use a collaborative process to move to a resolution wherever possible.
+
+## Community is the ❤️ of open source
+
+Healthy, thriving communities fuel the thousands of hours poured into open source every week. Many contributors point to other people as the reason for working - or not working - on open source. By learning how to tap into that power constructively, you'll help someone out there have an unforgettable open source experience.
diff --git a/_articles/uk-UA/code-of-conduct.md b/_articles/uk-UA/code-of-conduct.md
new file mode 100644
index 00000000000..e13d732d6c0
--- /dev/null
+++ b/_articles/uk-UA/code-of-conduct.md
@@ -0,0 +1,106 @@
+---
+locale: en-US
+title: Your Code of Conduct
+description: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct.
+class: coc
+toc:
+ why-do-i-need-a-code-of-conduct: "Why do I need a code of conduct?"
+ establishing-a-code-of-conduct: "Establishing a code of conduct"
+ deciding-how-youll-enforce-your-code-of-conduct: "Deciding how you’ll enforce your code of conduct"
+ enforcing-your-code-of-conduct: "Enforcing your code of conduct"
+order: 8
+image: /assets/images/cards/coc.png
+---
+
+## Why do I need a code of conduct?
+
+A code of conduct is a document that establishes expectations for behavior for your project's participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for your community.
+
+Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time.
+
+A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don't agree with.
+
+## Establishing a code of conduct
+
+Try to establish a code of conduct as early as possible: ideally, when you first create your project.
+
+In addition to communicating your expectations, a code of conduct describes the following:
+
+* Where the code of conduct takes effect _(only on issues and pull requests, or community activities like events?)_
+* Whom the code of conduct applies to _(community members and maintainers, but what about sponsors?)_
+* What happens if someone violates the code of conduct
+* How someone can report violations
+
+Wherever you can, use prior art. The [Contributor Covenant](http://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift.
+
+The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](http://citizencodeofconduct.org/) are also two good code of conduct examples.
+
+Place a CODE_OF_CONDUCT file in your project's root directory, and link to it from your README, so it's visible to your community.
+
+## Deciding how you'll enforce your code of conduct
+
+
+
+You should explain how your code of conduct will be enforced **_before_** a violation occurs. There are several reasons to do so:
+
+* It demonstrates that you are serious about taking action when it's needed.
+
+* Your community will feel more reassured that complaints actually get reviewed.
+
+* You'll reassure your community that the review process is fair and transparent, should they ever find themselves investigated for a violation.
+
+You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group.
+
+Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+
+> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.*
+
+For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project).
+
+## Enforcing your code of conduct
+
+Sometimes, despite your best efforts, somebody will do something that violates this code. There are several ways to address negative or harmful behavior when it comes up.
+
+### Gather information about the situation
+
+Treat each community member's voice as important as your own. If you receive a report that someone violated the code of conduct, take it seriously and investigate the matter, even if it does not match your own experience with that person. Doing so signals to your community that you value their perspective and trust their judgment.
+
+The community member in question may be a repeat offender who consistently makes others feel uncomfortable, or they may have only said or done something once. Both can be grounds for taking action, depending on context.
+
+Before you respond, give yourself time to understand what happened. Read through the person's past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior.
+
+
+
+### Take appropriate action
+
+After gathering and processing sufficient information, you'll need to decide what to do. As you consider your next steps, remember that your goal as a moderator is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community's behavior and expectations moving forward.
+
+When somebody reports a code of conduct violation, it is your, not their, job to handle it. Sometimes, the reporter is disclosing information at great risk to their career, reputation, or physical safety. Forcing them to confront their harasser could put the reporter in a compromising position. You should handle direct communication with the person in question, unless the reporter explicitly requests otherwise.
+
+There are a few ways you might respond to a code of conduct violation:
+
+* **Give the person in question a public warning** and explain how their behavior negatively impacted others, preferably in the channel where it occurred. Where possible, public communication conveys to the rest of the community that you take the code of conduct seriously. Be kind, but firm in your communication.
+
+* **Privately reach out to the person** in question to explain how their behavior negatively impacted others. You may want to use a private communication channel if the situation involves sensitive personal information. If you communicate with someone privately, it's a good idea to CC those who first reported the situation, so they know you took action. Ask the reporting person for consent before CCing them.
+
+Sometimes, a resolution cannot be reached. The person in question may become aggressive or hostile when confronted or does not change their behavior. In this situation, you may want to consider taking stronger action. For example:
+
+* **Suspend the person** in question from the project, enforced through a temporary ban on participating in any aspect of the project
+
+* **Permanently ban** the person from the project
+
+Banning members should not be taken lightly and represents a permanent and irreconcilable difference of perspectives. You should only take these measures when it is clear that a resolution cannot be reached.
+
+## Encourage the behavior you want to see in the world 🌎
+
+When a project seems hostile or unwelcoming, even if it's just one person whose behavior is tolerated by others, you risk losing many more contributors, some of whom you may never even meet. It's not always easy to adopt or enforce a code of conduct, but fostering a welcoming environment will help your community grow.
diff --git a/_articles/uk-UA/finding-users.md b/_articles/uk-UA/finding-users.md
new file mode 100644
index 00000000000..3e21824fd9f
--- /dev/null
+++ b/_articles/uk-UA/finding-users.md
@@ -0,0 +1,162 @@
+---
+locale: uk-UA
+title: Пошук користувачів для вашого проекту
+description: Допопожіть своєму open source проекту рости, віддавши його до рук щасливих користувачів.
+class: finding
+toc:
+ Розповісти-світові: "Розповісти світові"
+ Придумати-послання: "Придумати послання"
+ Допоможіть-іншим-людям-знайти-і-стежити-за-вашим-проектом: "Допоможіть іншим людям знайти і стежити за вашим проектом"
+ go-where-your-projects-audience-is-online: "Go where your project’s audience is (online)"
+ go-where-your-projects-audience-is-offline: "Go where your project’s audience is (offline)"
+ build-a-reputation: "Build a reputation"
+order: 3
+image: /assets/images/cards/finding.png
+---
+
+## Розповісти світові
+
+Ніхто не змушує вас розповідати про свій open source проект одразу ж після запуску. Існує вдосталь поважних причин працювати над open source, не включаючи набуття популярності. Якщо ви все ж сподіваєтесь, що інші люди знайдуть ваш проект і скористаються ним, саме час розповісти всім про свою тяжку працю!
+
+## Придумати послання
+
+Перш ніж починати просувати свій проект, треба вміти пояснити що він робить і чим він важливий.
+
+Що робить ваш проект унікальним чи цікавим? Навіщо ви його створили? Дайте відповіді для себе самого і вам буде легше переконати інших.
+
+Пам'ятайте, що люди спершу підключаються як користувачі (а зрештою як і співавтори), тому що ваш проект вирішує їх проблеми. Розмірковуючи над його посланням і цінністю, спробуйте поглянути на нього з точки зору _їх_ потреб.
+
+Наприклад, @robb використовує шматки коду, щоб чітко донести чим його проект, [Cartography](https://github.com/robb/Cartography), корисний:
+
+
+
+Щоб краще ознайомитися з повідомленням подивіться на вправи ["Особистості та їх життєві шляхи"](http://mozillascience.github.io/working-open-workshop/personas_pathways/) Mozilla для розробників.
+
+## Допоможіть іншим людям знайти і стежити за вашим проектом
+
+
+
+Допомжіть людям знайти і запам'ятати ваш проект направивши їх до єдиного простору імен.
+
+**Майте чіткий нік для просування своєї роботи.** Нікнейм у Twitter, посилання на GitHub, або IRC-канал - це прості способи направити людей до свого проекту. Вони також дають спільноті, що стрімко зростає довкола вашого проекту, місце для зборів.
+
+Якщо ви поки не бажаєте заводити ці канали для свого проекту, просувайте власний нік на Twitter чи GitHub за будь-якої зручної нагоди. Наприклад, включайте їх до свого резюме чи до слайдів, які показуєте підчас виступів. Таким чином люди знатимуть як з вами зв'язатися чи знайти вашу роботу.
+
+
+
+**Поміркуйте над створенням сайту для свого проекту.** Вебсайт допоможе проекту стати привітнішим і легшим у навігації, особливо якщо має детальну документацію і уроки. Це дає зрозуміти, що проект активний і це допоможе аудиторії почуватися впевненішим використовуючи його. Використовуйте приклади, щоб користувачі зрозуміли як ним користуватися.
+
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), співавтор Django, сказав, що вебсайт був _"поки що найважливішим кроком, який ми зробили з Django на початку"_.
+
+Якщо ваш проект розміщено на GitHub, ви можете скористатися [GitHub сторінками](https://pages.github.com/) щоб легко створти вебсайт. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), та [Middleman](https://middlemanapp.com/) ось [кілька прикладів](https://github.com/showcases/github-pages-examples) чудових, складних вебсайтів.
+
+
+
+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!
+
+## Go where your project's audience is (online)
+
+Online outreach is a great way to share and spread the word quickly. Using online channels, you have the potential to reach a very wide audience.
+
+Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](http://stackoverflow.com/), [reddit](http://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work.
+
+
+
+See if you can find ways to share your project in relevant ways:
+
+* **Get to know relevant open source projects and communities.** Sometimes, you don't have to directly promote your project. If your project is perfect for data scientists who use Python, get to know the Python data science community. As people get to know you, natural opportunities will arise to talk about and share your work.
+* **Find people experiencing the problem that your project solves.** Search through related forums for people who fall into your project's target audience. Answer their question and find a tactful way, when appropriate, to suggest your project as a solution.
+* **Ask for feedback.** Introduce yourself and your work to an audience that would find it relevant and interesting. Be specific about who you think would benefit from your project. Try to finish the sentence: _"I think my project would really help X, who are trying to do Y_". Listen and respond to others' feedback, rather than simply promoting your work.
+
+Generally speaking, focus on helping others before asking for things in return. Because it is easy for anybody to promote a project online, there will be a lot of noise. Give people context for who you are, not just what you want, to stand out from the crowd.
+
+If nobody pays attention or responds to your initial outreach, don't get discouraged! Most project launches are an iterative process that can take months or years. If you don't get a response the first time, try a different tactic, or look for ways to add value to others' work first. These things take time and dedication.
+
+## Go where your project's audience is (offline)
+
+
+
+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.
+
+If you're [new to public speaking](http://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project.
+
+
+
+If you've never spoken at an event before, it's perfectly normal to feel nervous! Remember that your audience is there because they genuinely want to hear about your work.
+
+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.
+
+
+
+When you feel ready, consider speaking at a conference to promote your project. Conferences can help you reach more people, sometimes from all over the world.
+
+Look for conferences that are specific to your language or ecosystem. Before you submit your talk, research the conference beforehand to tailor your talk to its attendees and increase your chances of getting accepted. You can often get a sense of a conference's audience by looking at its speakers.
+
+
+
+## Build a reputation
+
+In addition to the strategies outlined above, the best way to invite people to share and contribute to your project is to share and contribute to their projects.
+
+Helping newcomers, sharing resources, and making thoughtful contributions to others' work will help you build a positive reputation. Then, people will have context for your work and be more likely to pay attention and share what you're doing.
+
+Sometimes, these relationships can even lead to official partnerships with the wider ecosystem.
+
+
+
+It's never too early, or too late, to start building your reputation. Even if you've launched your own project already, continue looking for ways to help others.
+
+There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and reputation building work never ends.
+
+
+
+## Keep at it!
+
+Sometimes, it takes a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of a magic bullet. Be patient, and keep sharing your work with those who appreciate it.