🚀🎉 First off, thanks for taking the time to contribute! 🎉🚀 The following guidelines are for contributing to Edge Agent SDK TS. These are mostly guidelines. Use your best judgment, and feel free to propose changes to this document in a pull request.
What should I know before I get started?
Identus is a self-sovereign identity (SSI) platform and service suite for verifiable data and digital identity. Built on Cardano, as a distributed ledger, it offers the core infrastructure for issuing DIDs (Decentralized identifiers) and verifiable credentials alongside tools and frameworks to help expand your ecosystem. The complete platform is separated into multiple repositories:
- Cloud Agent - Repo that contains the cloud agent that provides self-sovereign identity services to build products and solutions.
- Mediator - Repo for the DIDComm V2 Mediator.
- Edge Agent SDK Swift - Repo for the Swift version of the SDK.
- Edge Agent SDK KMP - Repo for the Kotlin Multi-Platform version of the SDK.
Edge Agent SDK TS software development kit will help adoption within TS platforms (Browser/Node) by providing key functionalities. For more information about the SDK, please have a look at the Readme
Unsure where to begin contributing to Edge Agent SDK TS? You can start by looking through the Readme that provides all the steps to setup your environment.
As part of the Hyperledger project, all commits to Identus repos must by signed (cryptographically) and signed-off.
Getting started:
- Generate a gpg key (if you've not already done so)
- Tell git about your signing key
- Add your signing key to your Github account
- Set your sign-off signature
git config user.name "FIRST_NAME LAST_NAME" --global
git config user.email "MY_NAME@example.com" --globalFrom here you can add -sS to many commit related commands to sign your commits:
git commit -sS -m 'docs: add commit signing notes to CONTRIBUTING'Missed signing some commits? You can rebase + sign:
git rebase origin/main -sSOther resources:
- [Git Tools - Signing Your Work](https://git-scm.c(om/book/en/v2/Git-Tools-Signing-Your-Work)
The process described here has several goals:
- Maintain the SDK quality
- Fix problems that are important to users
- Engage the community in working toward the best possible product
- Enable a sustainable system for the SDK maintainers to review contributions
Please follow these steps to have your contribution considered by the maintainers:
- Sign your commits (see more info)
- Follow all instructions in the template
- Follow the styleguides
- After you submit your pull request, verify that all status checks are passing
What if the status checks are failing?
If a status check is failing, and you believe that the failure is unrelated to your change, please leave a comment on the pull request explaining why you believe the failure is unrelated. A maintainer will re-run the status check for you. If we conclude that the failure was a false positive, we will open an issue to track that problem with our status check suite.
While the prerequisites above must be satisfied before your pull request is reviewed, the reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be accepted.
This section guides you through submitting a bug report for Edge Agent SDK TS. Following these guidelines helps maintainers and the community understand your report 📝, reproduce the behaviour💻 💻, and find related reports 🔎.
Before creating bug reports, please check this list, as you might not need to create one. When creating a bug report, please include as many details as possible. Fill out the required template, the information it asks for helps us resolve issues faster.
Note: If you find a Closed issue that seems like the same thing you're experiencing, open a new issue and include a link to the original issue in the body of your new one.
- You might be able to find the cause of the problem and fix things yourself by Debugging. Most importantly, check if you can reproduce the problem in the latest version.
- Check the Readme ** if you have problems with the setup and the discussions for a list of common questions and problems.
- Perform a cursory search to see if the problem has already been reported. If it has and the issue is still open, add a comment to the existing issue instead of opening a new one.
Bugs are tracked as GitHub issues. Create an issue on that repository and provide the following information by filling in the template.
Explain the problem and include additional details to help maintainers reproduce the problem:
- Use a clear and descriptive title for the issue to identify the problem.
- Describe the exact steps which reproduce the problem in as many details as possible.
- Provide specific examples to demonstrate the steps. Include links to files or GitHub projects or copy/pasteable snippets which you use in those examples. If you're providing snippets in the issue, use Markdown code blocks.
- Describe the behaviour you observed after following the steps and point out what exactly the problem is with that behaviour.
- Explain which behaviour you expected to see instead and why.
- If you're reporting that the SDK crashed, include a crash report with a stack trace from the operating system. On macOS, the crash report will be available in
Console.appunder "Diagnostic and usage information" > "User diagnostic reports". Include the crash report in the issue in a code block, a file attachment, or put it in a gist and provide link to that gist. - If the problem wasn't triggered by a specific action, describe what you were doing before the problem happened and share more information using the guidelines below.
Provide more context by answering these questions:
- Did the problem start happening recently (e.g. after updating to a new version of the SDK), or was this always a problem?
- If the problem started happening recently, can you reproduce the problem in an older version of the SDK? What's the most recent version in which the problem doesn't happen?
- Can you reliably reproduce the issue? If not, provide details about how often the problem happens and under which conditions it usually happens.
This section guides you through submitting an enhancement suggestion for the SDK, including completely new features and minor improvements to existing functionality. Following these guidelines helps maintainers and the community understand your suggestion 📝 and find related suggestions 🔎.
Before creating enhancement suggestions, please check this list, as you might find out that you don't need to create one. When creating an enhancement suggestion, please include as many details as possible. Fill in the template, including the steps that you imagine you would take if the feature you're requesting existed.
- Most importantly, check if you're using the latest version.
- Perform a cursory search to see if the enhancement has already been suggested. If it has, comment on the existing issue instead of opening a new one.
Enhancement suggestions are tracked as GitHub issues. Create an issue on that repository and provide the following information:
- Use a clear and descriptive title for the issue to identify the suggestion.
- Provide a step-by-step description of the suggested enhancement in as many details as possible.
- Provide specific examples to demonstrate the steps. Include copy/pasteable snippets you use in those examples as Markdown code blocks.
- Describe the current behaviour and explain which behaviour you expected to see instead and why.
- Explain why this enhancement would be useful.
- List some other text editors or applications where this enhancement exists.
- Specify which version of the SDK you're using.
- Specify the name and version of the OS you're using.
Identus uses Conventional commits. Please always provide a commit following these specifications.
We have very precise rules over how our Git commit messages must be formatted. This format leads to easier to read commit history.
Each commit message consists of a header, a body, and a footer.
<header>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
The header is mandatory and must conform to the Commit Message Header format.
The body is mandatory for all commits except those of type "docs".
When the body is present, it must be at least 20 characters long and must conform to the Commit Message Body format.
The footer is optional. The Commit Message Footer format describes what the footer is used for and the structure it must have.
<type>(<scope>): <short summary>
│ │ │
│ │ └─⫸ Summary in present tense. Not capitalized. No period at the end.
│ │
│ └─⫸ Commit Scope: apollo|castor|pollux|mercury|pluto|domain|experience
│
└─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|test
The <type> and <summary> fields are mandatory, the (<scope>) field is optional.
Must be one of the following:
- build: Changes that affect the build system or external dependencies
- ci: Changes to the CI configuration files and scripts
- docs: Documentation only changes
- feat: A new feature
- fix: A bug fix
- perf: A code change that improves performance
- refactor: A code change that neither fixes a bug nor adds a feature
- test: Adding missing tests or correcting existing tests
The scope should be the name of the affected module or building block (as perceived by the person reading the changelog generated from commit messages).
The following is the list of supported scopes:
castorpolluxmercuryplutodomainexperience
Use the summary field to provide a succinct description of the change:
- use the imperative, present tense: "change" not "changed" nor "changes"
- don't capitalize the first letter
- no dot (.) at the end
Just as in the summary, use the imperative, present tense: "fix", not "fixed" nor "fixes".
Explain the motivation for the change in the commit message body. This commit message should explain why you are making the change. You can include a comparison of the previous behaviour with the new behaviour to illustrate the impact of the change.
The footer can contain information about breaking changes and deprecations and is also the place to reference GitHub issues, Jira tickets, and other PRs that this commit closes or is related to. For example:
BREAKING CHANGE: <breaking change summary>
<BLANK LINE>
<breaking change description + migration instructions>
<BLANK LINE>
<BLANK LINE>
Fixes ATL-<issue number>
or
DEPRECATED: <what is deprecated>
<BLANK LINE>
<deprecation description + recommended update path>
<BLANK LINE>
<BLANK LINE>
Related to ATL-<issue number>
Breaking Change section should start with the phrase "BREAKING CHANGE: " followed by a summary of the breaking change, a blank line, and a detailed description of the breaking change that includes migration instructions.
Similarly, a Deprecation section should start with "DEPRECATED: " followed by a short description of what is deprecated, a blank line, and a detailed description of the deprecation that also mentions the recommended update path.