[bn] Merge `dev-bn` branch into `main` branch

[sajibAdhi]

Describe your changes

Merge the dev-bn branch into the main branch.

Related issue number or link (ex: resolves #issue-number)

#410

Checklist before opening this PR (put x in the checkboxes)

• [x] This PR does not contain plagiarism
  • don’t copy other people’s work unless you are quoting and contributing it to them.
• [x] I have signed off on all commits
  • signing off (ex: git commit -s) is to affirm that commits comply DCO. If you are working locally, you could add an alias to your gitconfig by running git config --global alias.ci "commit -s".

[netlify[bot]]

✅ Deploy Preview for cncfglossary ready!

Name	Link
🔨 Latest commit	6ffe849a823f827eff6b0edebb78fe9c0f8c1b93
🔍 Latest deploy log	https://app.netlify.com/sites/cncfglossary/deploys/66e1176d2a734c0008538898
😎 Deploy Preview	https://deploy-preview-3301--cncfglossary.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[asem-hamid]

@sajibAdhi , The dev-bn branch is behind a lot of changes, and several files need to be updated.

/hold , until then

[github-actions[bot]]

Wait, please do not proceed with this yet.

[github-actions[bot]]

Wait, please do not proceed with this yet.

[jihoon-seo]

To who merge this PR: please use 'Squash and merge' method when merging.

[seokho-son]

@asem-hamid do you have a plan to unhold this PR?

@sajibAdhi just hope to let you know, this PR has many meaningless commits considering the number of changed files. We recommend localization approvers handle commit history well. (make a localization PR has one commit if possible). Please share this to he team approves. :)

FYI, This PR will be merged by squash merge method.

[asem-hamid]

@seokho-son No, actually, we are quite behind. We have a small team, so we have to move forward slowly.

Also, we are trying to follow the '1 commit per PR' rule now. However, those meaningless commits are there for historical reasons. In the early days, the team didn't follow the '1 commit per PR' policy strictly, so the dev-bn branch became a junkyard for these commits.

As a result, when we merge the dev-bn branch into the main branch, the maintainer has to use the 'merge by squash' method. Every time we do this, only one commit gets added to the commit history (in the main branch), and the rest of the commits become junk in the dev-bn branch. It has become a repetitive cycle.

To break this cycle, we can take the following step:

After merging this PR (by squash method), we can simply delete the dev-bn branch (if possible) and create a new branch (based on main) with the same name. We'll be careful so that we don't face this issue again.

Please correct me if I’m wrong and share your opinion.

[seokho-son]

Hi @asem-hamid

Deleting a branch that is already in use by multiple contributors is generally not a good practice in open source projects. It would be better to explore alternative approaches whenever possible.

Perhaps, instead of using rebase, you could synchronize the dev-bn branch with main using a merge, or clean up the branch using a different form of rebase with the --onto option. It’s important to test the strategy beforehand to ensure it works as intended.

[seokho-son]

Hi @nate-double-u I guess this PR was not ready considering this PR still has hold label from the team. Anyway, I think there is no issue for the branch management (this PR uses upstream branches only). :) But, I am not sure for the bn content itself, the bn team needs to check it. Hi @sajibAdhi @asem-hamid , please check the bn content in main branch if anything needs to be updated quickly)

[asem-hamid]

Those contents have already been checked by the team, and we were hoping to add more in this PR. But no worries, we can always include them later!

[nate-double-u]

Sorry about that—based on my conversations with you in slack @asem-hamid, i thought this was ready to go 😅

Deleting a branch that is already in use by multiple contributors is generally not a good practice in open source projects. It would be better to explore alternative approaches whenever possible.

While I generally agree with this advice, I wonder if some of these localization branches could be shorter lived. I know that there's a lot to collect in them, but I wonder if we might consider suggesting running these more like how K8s website runs their releases, creating a release PR that collects a set of updates, then merging them in on about a 3-4 month cadence, to then make a new dev branch that they work on for the next one.