...

Reporting an Issue

Backlog items for Hyperledger Indy projects are tracked in the Hyperledger Jira instance. To create, edit, or comment, you need a Linux Foundation ID.

A good bug report is easy for others to understand. If they cannot reproduce your issue, they are unlikely to be able to address it.

1. Before submitting an issue, search to see if someone has already reported something similar. If you find an unresolved duplicate issue, add to it any additional details you think can help.
2. Your bug report should include sections such as:
   1. Environment: The environment where you saw the issue.
      1. The operating system, where you obtained your software, how you installed it, etc
      2. Set the Jira field "Affects Version" to the version of the software you were running when you saw the issue. (Leave the "Fix Version" field alone until the code is done and assigned to a release.)
   2. Steps to Reproduce: step-by-step explanation of how to cause the problem from a clean installation of the software.
   3. Expected Behavior: The desired behavior that you expected to see.
   4. Observed Behavior: The problematic behavior that you saw.
   5. Notes: Any notes that you think would help the person investigating the issue.

...

1. It is preferable for you to start with a Jira issue before putting in significant effort.
   1. Get feedback on whether the community is interested in the feature.
   2. Solicit ideas on the best way to approach the implementation.
2. Consider submitting a HIPE
   1. If the change impacts more than one project, then a Hyperledger Indy Project Enhancement needs to be discussed.
3. Submit a Pull Request in GitHub with your architecture plan to the design folder of the repository you are changing.
1. The architects and maintainers will give you feedback and suggestions when accepting the design.
2. The design then becomes part of the developer documentation.
4. Submit a Pull Request in GitHub with your changes.
   
   1. Sign your commit to provide an attestation of the DCO.
   2. Don't forget to update all relevant tests, changes to CI / CD, documentation, translations, etc.
      1. API changes need to be reflected in all layers of the system within the repository you are updating. For example, LibIndy API improvements have to be reflected in the CLI and language bindings.
5. Wait
   1. CI will be run on your PR.
   2. Once CI passes, a maintainer will review your PR.
   3. If the maintainer asks for changes, you will need to respond.
   4. Once the maintainer is happy, the PR will be accepted and included in the next release.

Best practices when creating Pull Requests

1. Make a private fork of the repository you want to contribute to.
2. Assign the related Jira ticket to yourself and set it to "In Progress" so that others know you are working on it.
3. Write good code:
1. We prefer Test Driven Development.
2. Unit tests are required. Integration tests are encouraged.
3. Pay attention to the code standards documented in the repository where you are contributing.
   1. Observe best practices and style guidelines in the repository's "Coding-Conventions.md" file.
   2. Write idiomatic code for the language you’re using (e.g., pep8 PEP8 for python)
   3. Respect other stylistic and design choices until you build enough credibility to influence the project as a whole.
4. Understand the Apache 2 license: don’t contribute anything encumbered by copyright or patent issues.
5. Don’t add new dependencies without consulting a maintainer.
6. The CI pipeline is configured to fail on compiler warnings.
4. Confirm that all tests pass.
5. Don't mix unrelated improvements in the same Pull Requset.
6. Submit a Pull Request to the master branch of the upstream repository.
7. Move the Jira ticket to "Code Review" status.
8. Announce your PR on #indy-pr-review at chat.hyperledger.com (give the PR URL and Jira reference).
   1. The reviewer should assign the ticket to themselves.
   2. Especially engage the maintainers if the change is big, significant, or risky.
9. Monitor the pull request for comments from the reviewer.
10. Be patient.
    1. Our goal is to not let pull requests go for a week without some type of follow up from the maintainers.

...