diff --git a/_articles/bn/best-practices.md b/_articles/bn/best-practices.md
index b9bf9b6bb6..4ec6216d6a 100644
--- a/_articles/bn/best-practices.md
+++ b/_articles/bn/best-practices.md
@@ -61,10 +61,10 @@ If maintaining your project is part-time or purely volunteered, be honest about
 
 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 (_for example, "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 (_for example, "We only spend about 5 hours per week on this project"_)
+* 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 (_for example, "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 (_for example, "We only spend about 5 hours per week on this project"_)
 
 [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.