Create good first issue guidelines document

[exploreriii]

Problem

There is no javascript repository guideline as to what is considered a good first issue for the javascript sdk

We should know concretely what is considered a GFI, so the community can create suitable GFI

Solution

Create a document maybe here (?)
https://github.com/hiero-ledger/hiero-sdk-js/docs/GoodFirstIssues.md
or
https://github.com/hiero-ledger/hiero-sdk-js/GoodFirstIssues.md

and specify clearly what is considered an appropriate GFI and what is not

Alternatives

Alternatively, you can choose to inherit the generic hiero guidelines for a GFI but this may not apply specifically enough due to the nature of the javascript codebase and javascript coding priciples

[exploreriii]

@hiero-ledger/hiero-sdk-js-maintainers request information on what could be considered a GFI for this sdk, and I would be happy to work on this issue if it is desirable

For some ideas, here is a working document I am building for the python sdk

🧵 Small, Focused Source Changes

Adding or improving simple string helper functions

Implementing or improving str or repr methods

Fixing or clarifying edge cases in existing utility functions

Examples:

Improve formatting of a repr output

Make a string helper more robust or readable

🧩 Typing Improvements

Adding missing return type hints

Fixing incorrect or overly broad type annotations

Resolving basic type conflicts flagged by type checkers

Examples:

Change -> Any to a more specific return type

Fix mismatched return types in conditional branches

🔄 Refactors of Existing Examples

Refactoring an example for clarity or readability

Extracting repeated logic into helper functions

Renaming variables to be more descriptive

Allowed directions:

Split a large example into smaller, named functions

Combine a split example back into a single monolithic function for simplicity

❗ Note: This applies only to existing examples, not creating new ones.

📚 Documentation Improvements

Improving documentation in examples or source code

Clarifying confusing comments or outdated explanations

Adding missing explanations for non-obvious behavior

This includes:

Module-level docstrings

Function and method docstrings

Inline comments explaining intent (not obvious code)

🖨️ Print and Output Clarity

Improving clarity of print statements in examples

Making output more descriptive or user-friendly

Standardizing message formatting (e.g., prefixes, spacing)

Examples:

Replace ambiguous prints like "Done" with meaningful context

Add explanatory text before printed values

⚙️ Functional Improvements to Examples

Small functional improvements that better illustrate existing behavior

Adding missing steps that help users understand the workflow

Improving ordering or structure of example code

Examples:

Add an explicit setup step that was previously implied

Improve error-handling clarity in an example

🧪 Test Improvements (Additive Only)

Adding specific assertions to existing unit or integration tests

Extending current tests to cover an edge case

Improving test readability or naming

Examples:

Add an assertion for a previously untested branch

Improve test failure messages

❗ Tests should extend existing files, not introduce new test suites.

🚫 What We Do Not Consider Good First Issues

The following types of changes are out of scope for good first issues:

❌ New Examples

Creating entirely new examples

Adding new example files or workflows

These require deeper understanding of intended usage patterns.

❌ New Unit or Integration Tests

Creating new test files

Designing new test strategies or frameworks

Test creation often requires broader architectural context.

❌ Core DLT or Protocol Logic

Changes to to_proto / from_proto

Modifying serialization, deserialization, or protocol mappings

Any change that affects network or wire-level behavior

These areas are sensitive and require domain expertise.

❌ Cross-Cutting or Architectural Changes

Refactors spanning multiple modules or packages

Changes requiring understanding of multiple subsystems

Performance optimizations or concurrency changes

These are better suited for experienced contributors.

I can create a pull request with a proposal and perhaps with feedback we can get it right, if desired

[akshay-it23]

hi Hi 👋
I’d like to work on this issue and create the README file for the repository.
Please assign it to me. Thanks!

[exploreriii]

Hi @akshay-it23 I am unable to assign you, but will raise the attention to @hiero-ledger/hiero-sdk-js-maintainers to see if they approve to assign