From 2d1ccae6b675ee553d36ec2e8fe89cfbd03e3fb5 Mon Sep 17 00:00:00 2001 From: "F. Rifat Hasan" Date: Mon, 23 Dec 2024 14:36:39 +0600 Subject: [PATCH] Replace hyphen to asterisk in building-community.md --- _articles/bn/building-community.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/_articles/bn/building-community.md b/_articles/bn/building-community.md index 4931b3d171..31ad87b193 100644 --- a/_articles/bn/building-community.md +++ b/_articles/bn/building-community.md @@ -26,16 +26,16 @@ As you build your community, consider how someone at the top of the funnel (a po 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 first issues**: To help new contributors get started, consider explicitly [labeling issues that are simple enough for beginners to tackle](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub will then surface these issues in various places on the platform, increasing useful contributions, and reducing friction from users tackling issues that are too hard for their level. +* **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 first issues**: To help new contributors get started, consider explicitly [labeling issues that are simple enough for beginners to tackle](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub will then surface these issues in various places on the platform, increasing useful contributions, and reducing friction from users tackling issues that are too hard for their level. [GitHub's 2017 Open Source Survey](http://opensourcesurvey.org/2017/) showed incomplete or confusing documentation is the biggest problem for open source users. 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 a 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. +* **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 a 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.