[Beginner]: Refactor good first issue and good first issue candidate guidelines to be more welcoming/friendly

[exploreriii]

🐥 Beginner Friendly

This issue is intended for contributors who have previously completed a Good First Issue in Hiero and are at a beginner level.
We recognize that gaining confidence and building skills are equally important steps in the open-source contributor journey.
The purpose of this issue—and others listed under Find a beginner issue—is to provide a supportive, low-pressure environment where you can learn, practice, and grow your contribution skills with confidence.

👾 Description of the issue

We would like to improve our current good first issue candidate guidelines and good first issue guidelines, which are our root documents that help us understand how to best classify issues by difficulty.

These documents are practical, but, can be made friendlier, which is important as they might be read not just by maintainers but also issue creators and developers

💡 Proposed Solution

Aggressively edit
docs/maintainers/good_first_issue_candidate_guidelines.md
docs/maintainers/good_first_issues_guidelines.md

Strike a fine balance between practicality yet approachability

👩‍💻 Implementation Steps

Aggressively edit
docs/maintainers/good_first_issue_candidate_guidelines.md
docs/maintainers/good_first_issues_guidelines.md

We have recently created some friendlier examples for the hiero website and also the cpp sdk:
https://github.com/hiero-ledger/hiero-website/pull/115/changes
https://github.com/hiero-ledger/hiero-sdk-cpp/tree/main/docs/maintainers

The style and content can be used for inspiration, improving on our guidelines

✅ Acceptance Criteria

To be able to merge a pull request for this issue, we need:

• Assignment: You must be assigned to the issue, comment: /assign in the issue to get assigned see guide
• Changelog Entry: Correct changelog entry see guide
• Signed commits: commits must be DCO and GPG key signed see guide
• All Tests Pass: our workflow checks like unit and integration tests must pass
• Issue is Solved: The implementation fully addresses the issue requirements as described above
• No Further Changes are Made: Code review feedback has been addressed and no further changes are requested

📋 Step-by-Step Contribution Guide

• Assignment: You must be assigned to the issue, comment: /assign in the issue to get assigned see guide
• Fork, Branch and Work on the issue: Create a copy of the repository, create a branch for the issue and solve the problem. For instructions, please read our Contributing guide file. Further help can be found at Set-up Training and Workflow Training.
• DCO and GPG key sign each commit : each commit must be -s and -S signed. An explanation on how to do this is at Signing Guide
• Add a Changelog Entry : your pull request will require a changelog. Read Changelog Entry Guide to learn how.
• Push and Create a Pull Request : Once your issue is resolved, and your commits are signed, and you have a changelog entry, push your changes and create a pull request. Detailed instructions can be found at Submit PR Training, part of Workflow Training.
• You did it 🎉: A maintainer or committer will review your pull request and provide feedback. If approved, we will merge the fix in the main branch. Thanks for being part of the Hiero community as an open-source contributor ❤️

IMPORTANT You will ONLY be assigned to the issue if you comment: /assign
IMPORTANT Your pull request CANNOT BE MERGED until you add a changelog entry AND sign your commits each with git commit -S -s -m "chore: your commit message" with a GPG key setup.

🤔 Additional Information

For more help, we have extensive documentation:

• SDK Developer Docs
• SDK Developer Training

Additionally, we invite you to join our community on our Discord server.

We also invite you to attend each Wednesday, 2pm UTC our Python SDK Office Hour and Community Calls. The Python SDK Office hour is for hands-on-help and the Community Call for general community discussion.

You can also ask for help in a comment below!

[github-actions]

@coderabbitai plan

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Fetch details of issue #1421
gh issue view 1421 --repo hiero-ledger/hiero-sdk-python --json title,body,labels,assignees,state

Length of output: 6275

---

🏁 Script executed:

#!/bin/bash
# Read the current good first issue guideline documents
echo "=== good_first_issue_candidate_guidelines.md ==="
cat docs/maintainers/good_first_issue_candidate_guidelines.md

echo -e "\n\n=== good_first_issues_guidelines.md ==="
cat docs/maintainers/good_first_issues_guidelines.md

# Fetch reference material from hiero-website PR #115
echo -e "\n\n=== Reference from hiero-website PR #115 ==="
gh pr view 115 --repo hiero-ledger/hiero-website --json files --jq '.files[] | select(.path | contains("good_first_issue") or contains("CONTRIBUTING")) | {path: .path}'

# List maintainer docs from hiero-sdk-cpp
echo -e "\n\n=== Reference from hiero-sdk-cpp maintainer docs ==="
gh api repos/hiero-ledger/hiero-sdk-cpp/contents/docs/maintainers --jq '.[] | select(.type == "file") | .name'

Length of output: 10425

---

🏁 Script executed:

#!/bin/bash
# Fetch reference content from hiero-website PR #115
echo "=== hiero-website: guidelines_good_first_issue_candidates.md ==="
gh api repos/hiero-ledger/hiero-website/contents/.github/maintainers/guidelines_good_first_issue_candidates.md --jq '.content' | base64 -d

echo -e "\n\n=== hiero-website: guidelines_good_first_issues.md ==="
gh api repos/hiero-ledger/hiero-website/contents/.github/maintainers/guidelines_good_first_issues.md --jq '.content' | base64 -d

echo -e "\n\n=== hiero-sdk-cpp: guidelines-good-first-issues.md ==="
gh api repos/hiero-ledger/hiero-sdk-cpp/contents/docs/maintainers/guidelines-good-first-issues.md --jq '.content' | base64 -d

echo -e "\n\n=== hiero-sdk-cpp: guidelines-good-first-issue-candidates.md ==="
gh api repos/hiero-ledger/hiero-sdk-cpp/contents/docs/maintainers/guidelines-good-first-issue-candidates.md --jq '.content' | base64 -d

Length of output: 9348

---

Task: Refactor good first issue guidelines to be more welcoming and friendly

Based on the reference materials from the hiero-sdk-cpp repository and the issue requirements, I'll create a plan to refactor both documentation files to strike a better balance between practicality and approachability. The goal is to transform the current formal, defensive tone into a welcoming, supportive voice while maintaining all essential technical information.

High-Level Changes:

• Adopt conversational, empathetic tone inspired by C++ SDK guidelines
• Replace restrictive "NOT ALLOWED" language with constructive guidance
• Add context about why guidelines exist (to help contributors succeed)
• Simplify structure while maintaining comprehensive content
• Frame rules as supportive guidance rather than gatekeeping
• Acknowledge contributor perspective throughout

---

---

⏳ Preparing changes...

[Abhijeet2409]

/assign

[exploreriii]

Thanks! Please review the C++ example carefully, it should be as similar to that as possible please 👍 Thanks again