docs-issue-29 (#38)

## Summary

Branching rules and standards are updated.

docs/branch_standards.md

@@ -1,5 +1,9 @@
 # Branch Standards
 
+>[!IMPORTANT]
+> For contributions please fork the project and create pull request.
+> Only internal team is allowed to create branches.
+
 GitHub helps us manage our codebase efficiently by employing a
 structured branch management strategy that aligns with our diverse use
 cases. These branches ensure smooth coordination among development teams
@@ -16,51 +20,48 @@ contains two repositories;
 
 ##t
 
--   Feature Branches: feature-<Jira ticket number>
+-   Feature Branches: feature-issue-<issue number>
+
+-   Bugfix Branches: bugfix-issue-<issue number>
 
--   Bugfix Branches: bugfix-<Jira ticket number>
+-   Hotfix Branches: hotfix-issue-<issue number>
 
--   Hotfix Branches: hotfix-<Jira ticket number>
+-   Documentation Branches: docs-issue-<issue number>
 
-Contributors create their feature branches with Jira ticket number. As
+Contributors create their feature branches with issue number. As
 most features are expected to introduce new parameters in the inventory,
 the common approach is to create a similar named branch in both
 repositories (i.e. code and inventory).
 
 In both repositories:
 
 -   production branch (`main`) is locked to be updated manually. It can
-    be updated only thru Pull Request(PR) from development branch. The
-    main branch should always reflect the production-ready state of the
-    codebase. It should only contain code that has been thoroughly
-    reviewed, tested, and approved for deployment.
-
--   development branch(`devel`) serves as the main integration branch
-    where features are merged before being deployed to production.
-    Developers should base their feature branches off the development
-    branch.
+    be updated only thru Pull Request(PR). The main branch should always
+    reflect the production-ready state of the codebase. It should only
+    contain code that has been thoroughly reviewed, tested, and approved for deployment.
 
 -   feature branches should be self-contained. They need to be tested on
-    their own before merging to development. feature branches can be
-    merged to development thru Pull Request(s) following a review for
-    the request.
+    their own before merging. feature branches can be merged to main thru
+    Pull Request(s) following a review for the request.
 
 -   bugfix branches should address issues found during testing and
-    development. These branches should be tested and merged into
-    development branch.
+    development. These branches should be tested and merged through pull requests.
 
--   hotfix branch can be created directly from the master branch in the
+-   hotfix branch can be created directly from the main branch in the
     event of a critical bug or issue in production. Hotfixes should be
     kept minimal to reduce the risk of introducing new problems. Once
-    the hotfix is completed, it should be merged into both the master
-    and development branches.
+    the hotfix is completed, it should be merged into the main
+    through pull requests.
+
+-   documentation branch can be created directly from the main if a change is required.
+    documentation hanges should be updated with related branches.
 
 ![gitflow](images/branch_standard.jpg)
 
 ## Pull Requests
 
 When a developer completes work on a feature branch, they create a pull
-request (PR) to merge their changes into the development branch. Usually
+request (PR) to merge their changes into the main branch. Usually
 two merge requests are required, one for the code and one for the
 inventory repository. The PR should include a detailed description of
 the changes made, any relevant screenshots or documentation updates, and
@@ -89,7 +90,7 @@ functionality. CI checks should pass before a PR can be merged.
 
 ## Pull Request Merge
 
-Pull requests are merged automatically in development branch(`devel`)
+Pull requests are merged automatically in `main` branch
 when;
 
 * approval of 2 reviewers exist