Skip to content

test BIΒ #4

@DeathGun44

Description

@DeathGun44

πŸ§‘β€πŸŽ“ Beginner Issue

Welcome! This is a Beginner Issue designed to help you learn the codebase.

🏁 When this issue is complete, you will have:

βœ… Researched a file or method in detail
βœ… Followed SDK patterns to implement a solution
βœ… Researched and identified appropriate programming constructs to solve the problem
βœ… Created basic tests
βœ… Delivered a clean, review-ready pull request

🐞 Problem Description

πŸ’‘ Expected Solution

πŸ” Research Pointers

πŸ› οΈ Implementation Notes

🧠 Beginner Contributors β€” Prerequisites & Expectations

Caution

Beginner issues are low-risk but we expect a working solution.

Important

We recommend completing at least 3 good first issues before attempting a beginner issue.

Difficulty:

  • Requires building knowledge of the specific file(s)
  • Beginner to intermediate Coding skills

Tip

You should be comfortable with:

  • Forking, branching, committing (with DCO + GPG signing), and opening a pull request without a tutorial
  • Reading beginner to intermediate code you did not write and following its patterns
  • Handling simple merge conflicts
  • Keeping your fork up to date with main by rebasing
  • Looking things up on your own before asking for help

If any of that feels unfamiliar, good first issues might still be the most rewarding path for you right now β€” find one here.
You can always come back when you are ready.

⚠️ AI Usage Policy

  • AI can help you understand the codebase and the problem
  • Using AI to generate code for beginner issues is strictly discouraged
  • Using AI as the main source of research is strictly discouraged, refer to language and library documentation, protobuf definitions and other SDKs.

⏱️ Timeline & Workflow

  • Typical time: ~1 Week / ~8 hours.
    🧩 Difficulty: Manageable but requires investigation and testing
    πŸŽ“ Best for: Beginner contributors

  • πŸ”΄ Completing a beginner issue in 1–3 hours is a red flag.

Tip

Suggested: share your proposed implementation approach as a comment before writing code to get early feedback and avoid wasted effort.

πŸ§ͺ Testing Requirements

Important

At the beginner level, testing will be necessary but a small component.
The methods you implement should be verified (happy path at least)

How you test depends on the type of change.

Source code changes (e.g. in src/):

  • Write basic unit tests
  • Run tests locally: uv run pytest tests/unit/<specific_file>_test.py -v
  • Integration tests will run automatically when you push

GitHub Actions / workflow changes (e.g. in .github/): Guide

  • Test by merging to your fork's main and simulating the scenario

Example script changes (e.g. in examples/):

  • Run the example script and confirm output matches expected behavior
  • You will need a Hedera Portal account for testnet credentials

πŸ›‘οΈ Quality & Review Standards

Beginner PRs must be working and follow best practices.

  1. Working: The implementation must solve the problem and meet the acceptance criteria.
  2. SDK Best Practices: The solution should fit well with existing SDK patterns and abstractions.
  3. Testing: basic unit and possibly integration tests to demonstrate the implementation works as expected.

⚠️ Breaking changes

  • Watch for any changes that could impact existing users, even if they seem small.

πŸ€– AI notes

  • AI has gaps or incorrect understanding of repo-specific patterns, logic, and protobuf schemes.

βœ… PR Quality Checklist

Before opening your PR, confirm:

  • I have spent the majority of my time researching the problem and building my understanding of the codebase and methods.
  • My implementation works and is tested (if applicable).
  • Every line of code is personally understood and explainable.
  • My changes address what the issue asked for β€” nothing more, nothing less
  • I have applied appropriate linting, code quality, and formatting tools used in this repo.

Before requesting a review, confirm:

  • I did not modify files unrelated to this issue
  • Clean git history β€” no rebase artifacts, merge commits, or unrelated files
  • My commits are signed: git commit -S -s -m "chore: description" β€” Signing guide
  • I added a CHANGELOG.md entry (if appropriate) under [Unreleased] β€” Changelog guide
  • I have included appropriate tests and all CI checks pass.

πŸ“‹ Workflow quick reference

You have done this before β€” here are the links if you need them:

Step Guide
Claim this issue Comment /assign below
Sync with main Rebasing guide
Open a PR and link this issue PR guide
Resolve merge conflicts Merge conflicts guide

πŸ“š Resources & Support

πŸ†˜ Stuck?

Tip

Comment on this issue: and describe what you have tried. A maintainer will respond.

Python SDK References:

References:

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions