docs: added workflow training (#938)

Signed-off-by: exploreriii <133720349+exploreriii@users.noreply.github.com>

Author: exploreriii

CHANGELOG.md

@@ -7,7 +7,7 @@ This changelog is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.
 ## [Unreleased]
 
 ### Added
-
+- Added docs/sdk_developers/training/workflow: a training for developers to learn the workflow to contribute to the python SDK.
 - Added Improved NFT allowance deletion flow with receipt-based status checks and strict `SPENDER_DOES_NOT_HAVE_ALLOWANCE` verification.
 - Add `max_automatic_token_associations`, `staked_account_id`, `staked_node_id` and `decline_staking_reward` fields to `AccountUpdateTransaction` (#801)
 - Added docs/sdk_developers/training/setup: a training to set up as a developer to the python sdk

docs/sdk_developers/training/workflow/01_supporting_infrastructure.md

@@ -0,0 +1,61 @@
+## Supporting Infrastructure When Developing for the Python SDK
+
+For the best development experience and smoother support, we strongly recommend installing the following tools when developing for the Python SDK:
+
+Recommended Tools
+- [ ] GitHub Desktop
+- [ ] Visual Studio Code
+    - [ ] Pylance
+    - [ ] GitHub Copilot
+
+However, what may work best for you might be different. 
+
+### Github Desktop
+GitHub Desktop is a free, user-friendly application that provides a visual interface for Git and GitHub. Instead of running Git commands in a terminal, GitHub Desktop lets you perform common tasks through an intuitive UI.
+
+It allows you to:
+- Clone, fork, and manage repositories without using the command line
+- Easily create and switch branches
+- Visualize commit history and branches in a clear, interactive timeline
+- Stage and push local changes with a click
+- Resolve merge conflicts with guided prompts
+
+Overall, GitHub Desktop makes Git simpler, safer, and more visual, which is great for maintaining clean, branched pull requests and staying aligned with the rest of the Python SDK team.
+
+### VS Studio Code
+VS Code is a workpace that enables:
+
+- Easy project navigation
+- Easy file organisation
+- Access to a large ecosystem of extensions that plug-in, including Pylance and Github Copilot
+
+It’s the recommended editor for working within this SDK.
+
+#### Pylance
+Pylance is a high-performance language server for Python that:
+
+- Improves code quality
+- Identifies errors early
+- Helps you resolve issues faster
+
+For example, Pylance will underline this in red indicating it is incorrect with a reason:
+```python
+from hiero_sdk_python.account.token_id import TokenId
+```
+This is incorrect because token_id.py does not live in /account! Instead, it lives in /tokens
+
+Read our [Pylance Installation Guide](../../pylance.md)
+
+#### Github Copilot
+Github Copilot is an AI coding-assistant tool.
+
+GitHub Copilot supports your workflow by:
+- Suggesting code snippets and patterns
+- Helping predict correct imports
+- Maintaining consistent naming and formatting
+- Speeding up development
+
+Additionally, since we have Copilot enabled as an automatic reviewer, once you enable Copilot as a reviewer, it will review your pull requests submitted to the Python SDK. This helps maintainers merge changes more quickly and is a great benefit to the project.
+
+
+

docs/sdk_developers/training/workflow/02_forking_python_sdk.md

@@ -0,0 +1,35 @@
+## Forking the Python SDK
+
+To begin contributing to the Python SDK, you’ll first need your own copy of the repository.
+
+Forking creates a personal, editable version of the SDK under your own GitHub account, where you can safely experiment and prepare pull requests without impacting the Python SDK.
+
+### Steps to Fork the Python SDK
+
+1. Navigate to the Python SDK Repository
+
+Open the [Official Python SDK repository on GitHub](https://github.com/hiero-ledger/hiero-sdk-python)
+
+2. Create Your Fork
+Make sure you are logged in to Github. Then, in the top-right of the repository page, click Fork.
+
+GitHub will prompt you to confirm:
+- The destination account (your profile)
+- The name you want to give your fork (you can keep the default)
+
+Click Create fork.
+
+Your new fork will appear at:
+`https://github.com/<your-username>/<repository-name>`
+This is your copy of the Python SDK. You can also access it from your repository section on github online.
+
+
+3. Clone Your Fork Locally
+
+You now have an online copy of the Python SDK but you also need a local copy to work on the code.
+
+Using GitHub Desktop (recommended):
+1. Open GitHub Desktop.
+2. Go to File → Clone Repository
+3. Select the fork you just created under the “Your Repositories” tab.
+4. Choose a folder location on your machine and click Clone.

docs/sdk_developers/training/workflow/03_staying_in_sync.md

@@ -0,0 +1,32 @@
+## Syncing Your Repo with the Upstream Python SDK
+
+Development at the Python SDK can be fast meaning new changes are added frequently.
+
+It is important to frequently pull new changes at the Python SDK to your local repository to ensure you are working on the most updated code and avoid merge_conflicts.
+
+To do this:
+
+1. Link the Upstream Python SDK Remote with yours
+Link your fork to the upstream original Python SDK repository so you can easily bring in new updates from main.
+
+```bash
+git remote add upstream https://github.com/hiero-ledger/hiero-sdk-python.git
+```
+
+Then verify it is correctly set:
+```bash
+git remote -v
+```
+
+You should now see:
+origin → your fork
+upstream → the official Python SDK repo
+
+2. Before starting work and during a pull request, always fetch new changes:
+git checkout main
+git fetch upstream
+git pull upstream main
+
+Then rebase on your working branch to apply the new changes:
+git checkout mybranch
+git rebase main -S

docs/sdk_developers/training/workflow/04_assigning_issues.md

@@ -0,0 +1,12 @@
+## Getting Assigned to an Issue
+
+It is important to be assigned an issue before starting work on it or creating a pull request.
+
+We recommend Good First Issues for developers new to the Python SDK. These are easier and better documented tasks.
+
+To do that, 
+1. Select a `Good First Issue` that interests you and is not yet assigned at [Python SDK Issues](https://github.com/hiero-ledger/hiero-sdk-python/issues)
+2. Write a comment at the bottom of the issue page asking "I want to be assigned to this issue"
+3. A maintainer will shortly assign you to the issue
+
+Congratulations! You are assigned and can now get started on the work.

docs/sdk_developers/training/workflow/05_working_branches.md

@@ -0,0 +1,21 @@
+## Working on a Newly Assigned Issue in a Branch
+
+Once you are assigned to an issue, you can get started working on it.
+
+We require developers to work on a new branch for each new issue they are working on. This helps to avoid major sync issues and keep history clean.
+
+Before you create a branch, remember to pull in all recent changes from main:
+```bash
+git checkout main
+git fetch upstream
+git pull upstream main
+```
+
+Then create a branch:
+```bash
+git checkout -b my-new-branch-name
+```
+
+Commit all your changes on this new branch, then publish your branch and submit a pull request.
+
+

docs/sdk_developers/training/workflow/06_commit_message_requirements.md

@@ -0,0 +1,35 @@
+## Commit Message Requirements for the Python SDK
+At the Python SDK we require commits to be descriptive and conventionally named in order to keep helpful records.
+
+### Descriptive Commits
+A descriptive commit is one that summarises in words what was just commited.
+
+This is correct:
+
+```bash
+git commit -S -s -m "fix: fixed receipt status error catching in get_name"
+```
+
+This is incorrect:
+
+```bash
+git commit -S -s -m "looks like its mostly working now"
+```
+
+### Conventional Commits
+Read about conventional commit messages here: [Conventional Commmits](https://www.conventionalcommits.org/en/v1.0.0/#summary)
+
+This is correct:
+```bash
+git commit -S -s -m "chore: changelog entry to TokenCreateTransaction"
+```
+
+This is incorrect:
+```bash
+git commit -S -s -m "feat: changelog entry to TokenCreateTransaction"
+```
+
+This is incorrect:
+```bash
+git commit -S -s -m "changelog entry to TokenCreateTransaction"
+```

docs/sdk_developers/training/workflow/07_signing_requirements.md

@@ -0,0 +1,22 @@
+## DCO and GPG Verified Commit Signing Requirements for the Python SDK
+At the Python SDK we require **each** commit in a pull request to be:
+- DCO signed (this is achieved with a -s flag)
+- GPG key signed (this is achieved with a -S flag and a GPG key set up and tied to Github)
+
+To pass our workflows and be merge-ready.
+
+Therefore, use Terminal or a Command Line Interface when creating each commit and ensure the message is:
+```bash
+git commit -S -s -m "prefix: your commit message"
+```
+For example:
+```bash
+git commit -S -s -m "chore: changelog entry for TokenCreateTransaction"
+```
+
+**WARNING**: using the default commit button on Github desktop or VS Studio will result in un-signed commits.
+
+**WARNING** any merge or rebase operations will cause a loss of signing status unless you preserve signing: `git rebase main -S`
+
+Read more about signing and how to set up a GPG key at:
+[Signing Guide](../../signing.md)

docs/sdk_developers/training/workflow/08_breaking_changes.md

@@ -0,0 +1,56 @@
+## Breaking Changes and the Python SDK
+
+Breaking changes are generally not acceptable in Python SDK development. This is because they can:
+- Stop existing Python SDK users’ code from working
+- Force users to spend time and resources updating their applications
+- Remove functionality that users may rely on, with no equivalent replacement
+
+Breaking changes damage trust with our users and should be avoided whenever possible.
+
+### Identifying Whether Your Pull Request Introduces a Breaking Change
+
+Even if an issue does not mention breaking changes, a pull request may still introduce one.
+
+Common examples include:
+- Removing or renaming an existing function or class
+- Changing the return type or structure of a function or method
+- Modifying the parameters a function accepts (adding, removing, or changing types)
+- Refactoring a function or class in a way that changes its behaviour, even subtly
+- Changing default values or altering side effects
+
+When preparing a pull request, always evaluate whether any existing user code would stop working as a result of your changes even if its 'better'.
+
+For example - before:
+```python
+def transfer_tokens(account_id: str, amount: int):
+    ...
+```
+
+For example - after - breaking:
+```python
+def transfer_tokens(account_id: AccountId, amount: int, memo: str = None):
+    ...
+```
+User code passing a string account_id now fails, and adding a required memo parameter breaks all existing calls.
+
+
+## What to Do If a Breaking Change Is Unavoidable
+
+Breaking changes should be avoided, but in rare cases they are necessary.
+
+Examples include:
+- Correcting significant errors or faulty behaviour
+- Implementing new standards or APIs (such as HIPS)
+- Replacing deprecated functionality that cannot be maintained
+
+If a breaking change must occur:
+- Clearly communicate it in your commit messages and changelog.
+- Provide a detailed explanation in the changelog.
+- When possible, implement or propose backwards compatibility solutions (deprecation warnings, transitional methods, alternative APIs, etc.).
+
+Example changelog entry:
+
+`BREAKING CHANGE: transfer_tokens() now requires an AccountId object instead of a string.`
+
+
+Breaking changes are typically scheduled for major releases, giving users time to prepare and migrate safely.

docs/sdk_developers/training/workflow/09_changelog_entry.md

@@ -0,0 +1,17 @@
+## Changelog Entry Requirements for the Python SDK
+At the Python SDK we require a changelog entry in order to keep helpful records of what was added, changed, fixed or a breaking change for each release.
+
+Key steps:
+1. Open 'CHANGELOG.md' found at the project root
+2. Add your bullet point entry under [UNRELEASED] and the appropriate subheader (Added, Changed, Fixed or Breaking Change)
+
+Phrase it conventionally.
+
+For example:
+
+##[UNRELEASED]
+
+### Added
+- Added `.github/workflows/merge-conflict-bot.yml` to automatically detect and notify users of merge conflicts in Pull Requests.
+
+[Read more](../../changelog_entry.md) about creating changelog entries