diff --git a/_articles/bn/how-to-contribute.md b/_articles/bn/how-to-contribute.md
index 9ae6e4ed6e..ca56d93eeb 100644
--- a/_articles/bn/how-to-contribute.md
+++ b/_articles/bn/how-to-contribute.md
@@ -74,24 +74,24 @@ Even if you like to write code, other types of contributions are a great way to
 
 ### Do you like planning events?
 
-- Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)
-- Organize the project's conference (if they have one)
-- Help community members find the right conferences and submit proposals for speaking
+* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)
+* Organize the project's conference (if they have one)
+* Help community members find the right conferences and submit proposals for speaking
 
 ### Do you like to design?
 
-- Restructure layouts to improve the project's usability
-- Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability)
-- Put together a style guide to help the project have a consistent visual design
-- Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68)
+* Restructure layouts to improve the project's usability
+* Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* Put together a style guide to help the project have a consistent visual design
+* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68)
 
 ### Do you like to write?
 
-- Write and improve the project's documentation, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)
-- Curate a folder of examples showing how the project is used
-- Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://news.opensauced.pizza/about/)
-- Write tutorials for the project, [like PyPA's contributors did](https://packaging.python.org/)
-- Write a translation for the project's documentation, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
+* Write and improve the project's documentation, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)
+* Curate a folder of examples showing how the project is used
+* Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://news.opensauced.pizza/about/)
+* Write tutorials for the project, [like PyPA's contributors did](https://packaging.python.org/)
+* Write a translation for the project's documentation, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
@@ -103,28 +103,28 @@ Even if you like to write code, other types of contributions are a great way to
 
 ### Do you like organizing?
 
-- Link to duplicate issues, and suggest new issue labels, to keep things organized
-- Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765)
-- Ask clarifying questions on recently opened issues to move the discussion forward
+* Link to duplicate issues, and suggest new issue labels, to keep things organized
+* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765)
+* Ask clarifying questions on recently opened issues to move the discussion forward
 
 ### Do you like to code?
 
-- Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
-- Ask if you can help write a new feature
-- Automate project setup
-- Improve tooling and testing
+* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* Ask if you can help write a new feature
+* Automate project setup
+* Improve tooling and testing
 
 ### Do you like helping people?
 
-- Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit
-- Answer questions for people on open issues
-- Help moderate the discussion boards or conversation channels
+* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit
+* Answer questions for people on open issues
+* Help moderate the discussion boards or conversation channels
 
 ### Do you like helping others code?
 
-- Review code on other people's submissions
-- Write tutorials for how a project can be used
-- Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+* Review code on other people's submissions
+* Write tutorials for how a project can be used
+* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
 
 ### You don't just have to work on software projects!
 
@@ -132,9 +132,9 @@ While "open source" often refers to software, you can collaborate on just about
 
 For example:
 
-- @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome)
-- @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates
-- @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts)
+* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome)
+* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates
+* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts)
 
 Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience.
 
@@ -162,28 +162,28 @@ That said, many open source projects follow a similar organizational structure.
 
 A typical open source project has the following types of people:
 
-- **Author:** The person/s or organization that created the project
-- **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author)
-- **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.)
-- **Contributors:** Everyone who has contributed something back to the project
-- **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction
+* **Author:** The person/s or organization that created the project
+* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author)
+* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.)
+* **Contributors:** Everyone who has contributed something back to the project
+* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction
 
 Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a "team" page, or in the repository for governance documentation, to find this information.
 
 A project also has documentation. These files are usually listed in the top level of a repository.
 
-- **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source.
-- **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
-- **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to. A good example of an effective Contributing Guide would be the one from [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide).
-- **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
-- **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects like [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs).
+* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source.
+* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
+* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to. A good example of an effective Contributing Guide would be the one from [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide).
+* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
+* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects like [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs).
 
 Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.
 
-- **Issue tracker:** Where people discuss issues related to the project.
-- **Pull requests:** Where people discuss and review changes that are in progress whether its to improve a contributor's line of code, grammar usage, use of images, etc. Some projects, such as [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml), use certain GitHub Action flows to automate and quicken their code reviews.
-- **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations. A good example of this would be [CHAOSS' weekly Newsletter](https://chaoss.community/news/)
-- **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. A good example of this would be [EddieHub's Discord community](http://discord.eddiehub.org/).
+* **Issue tracker:** Where people discuss issues related to the project.
+* **Pull requests:** Where people discuss and review changes that are in progress whether its to improve a contributor's line of code, grammar usage, use of images, etc. Some projects, such as [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml), use certain GitHub Action flows to automate and quicken their code reviews.
+* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations. A good example of this would be [CHAOSS' weekly Newsletter](https://chaoss.community/news/)
+* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. A good example of this would be [EddieHub's Discord community](http://discord.eddiehub.org/).
 
 ## Finding a project to contribute to
 
@@ -215,15 +215,15 @@ If you're looking for existing issues you can fix, every open source project has
 
 You can also use one of the following resources to help you discover and contribute to new projects:
 
-- [GitHub Explore](https://github.com/explore/)
-- [Open Source Friday](https://opensourcefriday.com)
-- [First Timers Only](https://www.firsttimersonly.com/)
-- [CodeTriage](https://www.codetriage.com/)
-- [24 Pull Requests](https://24pullrequests.com/)
-- [Up For Grabs](https://up-for-grabs.net/)
-- [First Contributions](https://firstcontributions.github.io)
-- [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
-- [OpenSauced](https://opensauced.pizza/)
+* [GitHub Explore](https://github.com/explore/)
+* [Open Source Friday](https://opensourcefriday.com)
+* [First Timers Only](https://www.firsttimersonly.com/)
+* [CodeTriage](https://www.codetriage.com/)
+* [24 Pull Requests](https://24pullrequests.com/)
+* [Up For Grabs](https://up-for-grabs.net/)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://opensauced.pizza/)
 
 ### A checklist before you contribute
 
@@ -441,9 +441,9 @@ Before doing anything, do a quick check to make sure your idea hasn't been discu
 
 If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by doing the following:
 
-- **Raising an Issue:** These are like starting a conversation or discussion
-- **Pull requests** are for starting work on a solution.
-- **Communication Channels:** If the project has a designated Discord, IRC, or Slack channel, consider starting a conversation or asking for clarification about your contribution.
+* **Raising an Issue:** These are like starting a conversation or discussion
+* **Pull requests** are for starting work on a solution.
+* **Communication Channels:** If the project has a designated Discord, IRC, or Slack channel, consider starting a conversation or asking for clarification about your contribution.
 
 Before you open an issue or pull request, check the project's contributing docs (usually a file called CONTRIBUTING, or in the README), to see whether you need to include anything specific. For example, they may ask that you follow a template, or require that you use tests.
 
@@ -461,33 +461,33 @@ If you want to make a substantial contribution, open an issue to ask before work
 
 You should usually open an issue in the following situations:
 
-- Report an error you can't solve yourself
-- Discuss a high-level topic or idea (for example, community, vision or policies)
-- Propose a new feature or other project idea
+* Report an error you can't solve yourself
+* Discuss a high-level topic or idea (for example, community, vision or policies)
+* Propose a new feature or other project idea
 
 Tips for communicating on issues:
 
-- **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work.
-- **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.
-- **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.
+* **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work.
+* **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.
+* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.
 
 ### Opening a pull request
 
 You should usually open a pull request in the following situations:
 
-- Submit small fixes such as a typo, a broken link or an obvious error.
-- Start work on a contribution that was already asked for, or that you've already discussed, in an issue.
+* Submit small fixes such as a typo, a broken link or an obvious error.
+* Start work on a contribution that was already asked for, or that you've already discussed, in an issue.
 
 A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just open it as a "draft" or mark as a "WIP" (Work in Progress) in the subject line or "Notes to Reviewers" sections if provided (or you can just create your own. Like this: `**## Notes to Reviewer**`). You can always add more commits later.
 
 If the project is on GitHub, here's how to submit a pull request:
 
-- **[Fork the repository](https://guides.github.com/activities/forking/)** and clone it locally. Connect your local to the original "upstream" repository by adding it as a remote. Pull in changes from "upstream" often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. (See more detailed instructions [here](https://help.github.com/articles/syncing-a-fork/).)
-- **[Create a branch](https://guides.github.com/introduction/flow/)** for your edits.
-- **Reference any relevant issues** or supporting documentation in your PR (for example, "Closes #37.")
-- **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request.
-- **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. It's important to make sure your changes don't break the existing project.
-- **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
+* **[Fork the repository](https://guides.github.com/activities/forking/)** and clone it locally. Connect your local to the original "upstream" repository by adding it as a remote. Pull in changes from "upstream" often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. (See more detailed instructions [here](https://help.github.com/articles/syncing-a-fork/).)
+* **[Create a branch](https://guides.github.com/introduction/flow/)** for your edits.
+* **Reference any relevant issues** or supporting documentation in your PR (for example, "Closes #37.")
+* **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request.
+* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. It's important to make sure your changes don't break the existing project.
+* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
 
 If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.