diff --git a/.editorconfig b/.editorconfig index d9393ed..49dcbbf 100644 --- a/.editorconfig +++ b/.editorconfig @@ -14,8 +14,18 @@ indent_size = 4 [*.{rs,go}] indent_size = 4 +[*.{kt,kts}] +indent_size = 4 + +[*.java] +indent_size = 4 + [*.md] trim_trailing_whitespace = false +indent_size = unset + +[LICENSE] +indent_size = unset [Makefile] indent_style = tab diff --git a/.git-blame-ignore-revs b/.git-blame-ignore-revs new file mode 100644 index 0000000..aa4e7ba --- /dev/null +++ b/.git-blame-ignore-revs @@ -0,0 +1,3 @@ +# style: auto-fix markdown formatting and fix broken table +# Mass formatting. No logic changes. +33fb67d62513845ee758ed176dd6749c390f118f diff --git a/.markdownlint-cli2.yaml b/.markdownlint-cli2.yaml new file mode 100644 index 0000000..cb4c979 --- /dev/null +++ b/.markdownlint-cli2.yaml @@ -0,0 +1,12 @@ +# markdownlint-cli2 configuration — canonical Identus baseline +# https://github.com/DavidAnson/markdownlint-cli2 +# +# Repos should prepend this baseline and append repo-specific ignores. + +# Ignore patterns (common across all repos) +ignores: + - ".claude/**" + - "**/node_modules/**" + - "**/target/**" + - "**/build/**" + - "CHANGELOG.md" diff --git a/.markdownlint.yml b/.markdownlint.yml index 60f19d0..5c52345 100644 --- a/.markdownlint.yml +++ b/.markdownlint.yml @@ -1,17 +1,61 @@ -# markdownlint configuration +# markdownlint configuration — canonical Identus baseline # https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md +# +# Repos may append additional relaxations below this baseline. +# Rules disabled here were needed in 5+ repos during the org-wide rollout. default: true # Allow long lines (common in tables, URLs, and generated content) MD013: false -# Allow multiple top-level headings (common in multi-section docs) +# Allow heading increment jumps (h1 → h3) +MD001: false + +# Allow duplicate headings (common in multi-section docs) +MD024: false + +# Allow multiple top-level headings MD025: false -# Allow inline HTML (needed for badges, details/summary, etc.) +# Allow any ordered list numbering style +MD029: false + +# Allow inline HTML (needed for badges, details/summary, admonitions) MD033: false -# Allow duplicate headings in different sections -MD024: - siblings_only: true +# Allow bare URLs +MD034: false + +# Allow emphasis used as headings +MD036: false + +# Allow code blocks without language specifier +MD040: false + +# Allow first line to not be a heading (centered logos in READMEs) +MD041: false + +# Allow any heading style (atx and setext) +MD003: false + +# Allow any list style (dash, asterisk, plus) +MD004: false + +# Allow inconsistent list indentation +MD005: false + +# Allow any list indentation +MD007: false + +# Allow trailing punctuation in headings +MD026: false + +# Allow link fragments that don't match headings (common with HTML anchors) +MD051: false + +# Allow non-descriptive link text like "[here]" +MD059: false + +# Allow compact and misaligned table styles +MD060: false diff --git a/.yamllint.yml b/.yamllint.yml index 189ed94..baa2885 100644 --- a/.yamllint.yml +++ b/.yamllint.yml @@ -1,4 +1,9 @@ --- +# yamllint configuration — canonical Identus baseline +# +# Repos may append additional relaxations or ignore patterns below. +# Rules here were needed in 7+ repos during the org-wide rollout. + extends: default rules: @@ -11,3 +16,27 @@ rules: # Relaxed comment indentation comments-indentation: disable + + # Don't require document start marker (---) + document-start: disable + + # Relaxed bracket/brace spacing (common in Docker Compose port mappings) + brackets: + min-spaces-inside: 0 + max-spaces-inside: 1 + braces: + min-spaces-inside: 0 + max-spaces-inside: 1 + + # Allow 1 space before inline comments + comments: + min-spaces-from-content: 1 + + # Relaxed indentation (k8s manifests, Helm charts use various styles) + indentation: + spaces: consistent + indent-sequences: whatever + + # Allow trailing blank line at end of file + empty-lines: + max-end: 1 diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 2ecbd3c..6716a78 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -12,7 +12,6 @@ As a contributor, here are the guidelines we would like you to follow: - [Guidelines for Closing Issues](#closing) - [Triage process and labels](#triage) - [Releasing Identus ecosystem](#releasing) - ## Developer Certificate of Origin (DCO) @@ -26,7 +25,6 @@ If you find a bug in the source code, you can help us by [submitting an issue](# Even better, you can [submit a Pull Request](#submit-pr) with a fix. - ## Missing a Feature? You can *request* a new feature by [submitting an issue](#submit-issue) to our GitHub Repository. @@ -39,7 +37,6 @@ If you would like to *implement* a new feature, please consider the size of the * **Small Features** can be crafted and directly [submitted as a Pull Request](#submit-pr). - ## Submission Guidelines ### Submitting an Issue @@ -80,6 +77,7 @@ Before you submit your Pull Request (PR) consider the following guidelines: ```shell git commit --all ``` + Note: the optional commit `-a` command line option will automatically "add" and "rm" edited files. 10. Push your branch to GitHub: @@ -131,6 +129,7 @@ The following general rules are applied to all commits: We have very precise rules over how our Git commit messages must be formatted. This format leads to: + 1. Automation of releases and changelog generation 2. Easy to read commit history @@ -170,6 +169,7 @@ The and fields are mandatory, the () field is optional. The `` and `` fields are mandatory, the `()` field is optional. Commit message with `!` to draw attention to breaking change: + ```text feat!: send an email to the customer when a product is shipped ``` @@ -252,9 +252,11 @@ To ensure consistency throughout the source code, keep these rules in mind as yo * All **must be documented**. ## Guidelines for Closing Issues -To ensure a smooth and productive issue management process that respects all contributors' efforts and maintains project clarity, we kindly request that you follow these guidelines when closing issues. It is important always to maintain a polite and respectful tone when interacting with others in the issues section. Additionally, please acknowledge contributions and provide clear explanations for decisions. + +To ensure a smooth and productive issue management process that respects all contributors' efforts and maintains project clarity, we kindly request that you follow these guidelines when closing issues. It is important always to maintain a polite and respectful tone when interacting with others in the issues section. Additionally, please acknowledge contributions and provide clear explanations for decisions. ### Resolution + Issues should be closed when: - The original bug has been fixed. @@ -262,6 +264,7 @@ Issues should be closed when: - A question has received a definitive answer. ### Non-Actionable Issues + Close an issue if: - It duplicates an existing open issue. @@ -269,94 +272,116 @@ Close an issue if: - The issue lacks sufficient information, and the original reporter has not responded to requests for clarification. ### Stale Issues + Issues that have not had any activity for 30 days should be tagged as stale. After 60 days, they should be considered for closure to prevent clutter. ### Verification Before Closing + Ensure that the resolution actually addresses the issue effectively. Involve others in testing or reviewing the solution when necessary. ### Communication + Always leave a comment explaining the reason for closing the issue. This helps provide clarity and context to all participants. ### Who Should Close Issues + - The Original Reporter: May close the issue if they are satisfied with the resolution. - Maintainers/Contributors: Those with write permissions can close issues as described above. ### Labeling + It is recommended to apply appropriate resolution labels such as `triage:out-of-scope`, `triage:cant-repro`, `triage:duplicate`, `triage:stale` or `triage:wont-fix` to closed issues. This aids in tracking and analysis. # Triage process and labels + Main part of adding and updating labels is done through the triage process by a triage team or the implementation team, which are both part of maintainers. This is to make sure an issue is at an acceptable level (description, clarity) before it is assigned to be analysed. In Identus, we are aiming that all the components are using same labels to bring convenience in review and coherence. This will necessit education within the maintainers community. We believe adding labels will have little impact on the engineers daily routine. Labels are categorised with a prefix that will help showing the info in the same order on a labeled issue: + - `triage`: this gives the action requested from the triage team. It will help to filter during the triage - `type`: to mark which category belongs an issues (e.g: bug, enhancement) - `priority`: reflects the severity and order in which issues should be addressed, more from the business impact rather than the technical difficulty - `component`: the team may set this label once the issue is analysed, to indicate which components are impacted -## Labels definition +## Labels definition + The triage labels that are defined and additional process details are precised in the following table: -| Label | Description | Additional process | + +| Label | Description | Additional process | |--------------------|----------------------------------------------------------------------------|--------------------------------------| | triage:needs-fix | This confirms that the bug is ready to be analysed further by the maintainer | `Assignees` = the team's lead (then the team's lead will assign further) | | triage:query | Additional info is needed in order to analyse and fix (e.g: steps to reproduce are missing) | `Assignees` = Whoever needs to reply to the query | -| triage:good-first-issue | This indicates to the community that this issue would be a good candidate to start with | -| triage:help-wanted | The issue will not be taken in priority and maintainers are requested contributors to join and work on this issue | +| triage:good-first-issue | This indicates to the community that this issue would be a good candidate to start with | | +| triage:help-wanted | The issue will not be taken in priority and maintainers are requested contributors to join and work on this issue | | | triage:stale | For issues that are seen once or have no paradigm to reproduce. The triage will then decide what action to do in order to progress. For example, asking the community on Discord if similar issue was seen, or asking QA to make dedicated tests to reproduce. This defect is under monitoring and after a few (four) weeks, the triage team will update the comment and might decide to close the issue | Triage team adds a comment to describe the next steps and `Assignees` is set accordingly | -| triage:cant-repro | It indicates the issue cannot be reproduced or was not seen for a long time | If triage is ok, the issue is closed | +| triage:cant-repro | It indicates the issue cannot be reproduced or was not seen for a long time | If triage is ok, the issue is closed | | triage:duplicate | Indicates the issue is duplicate of an existing one that shall be referred in the comment | If triage is ok, the issue is closed | | triage:wont-fix | The decision is to accept the issue as is and not to work on this issue | If triage is ok, the issue is closed | | triage:out-of-scope | Indicates the implementation is following the specification or an existing ADR (to be referred in the analyse) and awaiting confirmation by triage | If triage is ok, the issue is closed | -| type:bug | It should follow the template 'Bug report'. It could be a degradation in performance for a component or the whole ecosystem | -| type:docs | For a change or issue only related to documentation | -| type:enhancement | For a new feature or improvement of an existing feature. It might follow the template 'Feature request' but might also be a refactoring and technical debt | -| type:support | The reporter is asking for support from maintainers more than anything else | -| type:roadmap | This issue will appear in the project roadmap https://github.com/orgs/hyperledger/projects/48 | -| type:ci | Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) | -| type:test | Adding missing tests or correcting existing tests. This could be for a unit test, an integration test, a validation test | -| priority:critical | A large number of users or stakeholders are impacted, performance drained, crash, feature blocked, reproducible, interoperability, legal & regulatory, standard non-compliancy, security breach | -| priority:major | feature is working but some use cases, feature is not stable, regression, frequently seen, reproducible | -| priority:minor | no impact on the feature, not reproducible, not frequently seen, UI & cosmetics | -| component:cloud-agent | After analyse, the Cloud Agent is impacted by this issue | -| component:mediator | After analyse, the Mediator is impacted by this issue | -| component:SDK-swift | After analyse, the SDK Swift is impacted by this issue | -| component:SDK-KMP | After analyse, the SDK KMP is impacted by this issue | -| component:SDK-TS | After analyse, the SDK TS is impacted by this issue | -| component:node | After analyse, the Node is impacted by this issue | -| component:crypto-lib | After analyse, the Cryptographic library is impacted by this issue | -| component:infra | After analyse, the Infrastructure is impacted by this issue | +| type:bug | It should follow the template 'Bug report'. It could be a degradation in performance for a component or the whole ecosystem | | +| type:docs | For a change or issue only related to documentation | | +| type:enhancement | For a new feature or improvement of an existing feature. It might follow the template 'Feature request' but might also be a refactoring and technical debt | | +| type:support | The reporter is asking for support from maintainers more than anything else | | +| type:roadmap | This issue will appear in the project roadmap https://github.com/orgs/hyperledger/projects/48 | | +| type:ci | Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) | | +| type:test | Adding missing tests or correcting existing tests. This could be for a unit test, an integration test, a validation test | | +| priority:critical | A large number of users or stakeholders are impacted, performance drained, crash, feature blocked, reproducible, interoperability, legal & regulatory, standard non-compliancy, security breach | | +| priority:major | feature is working but some use cases, feature is not stable, regression, frequently seen, reproducible | | +| priority:minor | no impact on the feature, not reproducible, not frequently seen, UI & cosmetics | | +| component:cloud-agent | After analyse, the Cloud Agent is impacted by this issue | | +| component:mediator | After analyse, the Mediator is impacted by this issue | | +| component:SDK-swift | After analyse, the SDK Swift is impacted by this issue | | +| component:SDK-KMP | After analyse, the SDK KMP is impacted by this issue | | +| component:SDK-TS | After analyse, the SDK TS is impacted by this issue | | +| component:node | After analyse, the Node is impacted by this issue | | +| component:crypto-lib | After analyse, the Cryptographic library is impacted by this issue | | +| component:infra | After analyse, the Infrastructure is impacted by this issue | | ## Triage process + - Triage team should consist of a small number (three) of maintainers whose roles are covering technical and product aspects. Other experts might be invited at their discretion. - We assume that at the beginning, a triage call will be needed and set by the triage team to get the triage kicked off and thus momentum will be gained. - At the discretion of the triage team, some part of the triage might be executed in asynchronous way. It is also taking a decision on the issues that are not progressing or lacking of interest. But above all, it is alerting and making sure the critical issues are prioritised to the community interest. - The triage process and using the same labels in all repositories is to ensure consistency ### 1. Initial Triage + When a new issue is created, it should go through an initial triage process. This involves: + - Ensure the issue description is clear and has all necessary information (steps to reproduce, expected vs. actual behaviour, screenshots, etc.): if not, place the triage label, assign to the reporter and add a comment. - Labels: Assign the appropriate `type`, `priority`, and `triage` labels based on the issue's details. - Ownership: Assign the issue to a team member or the team's lead. + ### 2. Prioritisation + Regularly review and prioritise issues, typically in a meeting or in async way. This involves: + - Reviewing labels: Ensure that labels reflect the current state of the project. - Re-assessing priority: Adjust priorities based on new information, changes in project scope, or external factors. + ### 3. Assignment and Progress Tracking + - Track the progress of issues using status labels or using the Github board - Regular updates: Ensure assignees provide regular updates on their progress and any blockers they encounter. + ### 4. Review and Resolution + - Once an issue is addressed, it should go through a review process (PR review) - Resolution: indicate with the triage label the resolution: `triage:wont-fix`, `triage:duplicate`, etc., to indicate how the issue was resolved. + ### 5. Closure + After an issue is resolved and verified and the issue is closed on GitHub. > [!NOTE] -> The outcome of the triage may be shared on Discord annoucement channel (or a dedicated triage channel), highlighting: -> - Critical issues -> - Outstanding actions - +> The outcome of the triage may be shared on Discord annoucement channel (or a dedicated triage channel), highlighting: +> +> - Critical issues +> - Outstanding actions # Releasing Identus + As per [README](./README.md), Identus is consisting of several core components that are validated as an ecosystem and a node and corresponding documentation. This section is describing the release process. The release manager is the owner of this process and is a chosen maintainer. 1. System release candidate @@ -365,15 +390,18 @@ As per [README](./README.md), Identus is consisting of several core components t 4. Release finalization ## Step1 - System release candidate + When an ecosystem release is planned, each component should have a release candidate confirmed with the component owner: it thus shall have an existing `pre-release` release note for that component tag: if not, the release manager should ping the component owner to create the corresponding component release note. -### Individual component release +### Individual component release + Note that all components of Identus are released and tested independently. It means that each component has its own independent release cycle and versioning; Each component contains unit and integration tests to confirm that everything works as expected. This is possible because all components are designed to be backward compatible and are tested against the latest version of other components. > [!NOTE] > When a new version of a component is released, it is automatically published to the registry (npm, GitHub, etc) and is ready to be used by other components. ### Ecosystem release candidate + It is then formed by the sum of the component release candidates and ready to be run under the system level tests. There are e2e tests that check the compatibility of the components with each other. ## Step2 - Quality Assurance (QA) validation @@ -381,6 +409,7 @@ It is then formed by the sum of the component release candidates and ready to be Quality Assurance should guarantee that all components versions are working properly within the released version on a pre-production environment (*the environment TBC if it is SIT*). This process consists in: + - Adhoc and manual testing - Running regression and e2e for all components - Updating any regression test if required @@ -389,6 +418,7 @@ This process consists in: **Running end-to-end tests:** The SDKs e2e are the system level testing, which are the most important for the release. + - Using SIT environment - Check the environment is using the correct version (Cloud Agent, Mediator, Node) - Run the SDKs e2e tests @@ -407,7 +437,9 @@ With the support of QA, one maintainer (*TBC until now, it was the QA enginner b *TBC: potentially a compatibility table is updated.* ## Step3 - Create the ecosystem release note and get it approved + For a release `vx.y`: + - In the Identus repo [hyperledger/identus](https://github.com/hyperledger/identus/), check the latest released version; it should be `Identus va.b` format. E.g `Identus v2.12`. - Click on `Release` and `Draft a new release` button - In `Choose a tag` button, create the tag `vx.y` @@ -425,14 +457,15 @@ For a release `vx.y`: - *Option2: create a dedicated PR with the list of the component owners and QA lead are reviewers. The release note is approved when all the reviewers have approved the PR.* - Having the checkbox would help to add checklist, such as the Quick Start Guide is executed, compatibility table is updated, a security scanning (automatic or manual) at component level was executed, ... - ## Step4 - Publish, deployment and announcement -### For components, section to be added + +### For components, section to be added + ### Documentation Website -- To deploy the documentation into production, +- To deploy the documentation into production, - Find the `portal version` of the Documentation Portal from the latest [release](https://github.com/hyperledger/identus/releases). - - In atala-prism-docs repository, run the [workflow](https://github.com/input-output-hk/atala-prism-docs/actions/workflows/deployment.yml). + - In atala-prism-docs repository, run the [workflow](https://github.com/input-output-hk/atala-prism-docs/actions/workflows/deployment.yml). - To deploy it, click the `Run Workflow` button and set the `version to deploy` with the `portal version` and set the `Environment to trigger update on` value to `production` - Click the green button. To check if the right version was deployed, go to the public site, [https://docs.atalaprism.io/](https://docs.atalaprism.io/), and check that the Agent API version is the one that is found in the [release](https://github.com/hyperledger/identus/releases) (the same file you used in the step 1). @@ -443,4 +476,3 @@ Once the release entry has been approved, the ecosystem release may be announced - **Discord Hyperledger** - `identus-maintainers` channel https://discord.com/channels/905194001349627914/1226983777687965707 - **Discord Hyperledger** - `identus-announcements` channel https://discord.com/channels/905194001349627914/1230596020790886490 - diff --git a/DCO.md b/DCO.md index 5ad7825..0e65dde 100644 --- a/DCO.md +++ b/DCO.md @@ -3,6 +3,7 @@ Identus requires all contributions to acknowledge the Developer Certificate of Origin (DCO) and be signed with a PGP key. These measures protect the project's integrity and ensure that everyone involved understands the code's origin and licensing. ## Table Of Contents + - [DCO](#dco) - [How to sign-off](#how-to-sign-off) - [Setting up your signoff](#setting-up-your-signoff) @@ -12,7 +13,6 @@ Identus requires all contributions to acknowledge the Developer Certificate of O - [Setting up PGP](#setting-up-pgp) - [Troubleshooting](#troubleshooting) - ## DCO The DCO is a way to confirm that you are able to submit your contribution to our repository under the license of the repository, and for the contribution to be redistributed under that same license. By adding a "Signed-off-by" line to your commit messages, you acknowledge the following: @@ -51,7 +51,7 @@ Add a line like this to each commit message in your pull request: ```text Signed-off-by: Your Legal Name -``` +``` The text can either be manually added to your commit body, or you can add either `-s` or `--signoff` to your usual git commit commands. @@ -95,7 +95,7 @@ If you've pushed your changes to GitHub already you'll need to force push your b ### DCO Failures -The project uses a DCO bot for all GitHub pulls to verify that each commit is signed off. When you create your pull request, it will automatically be verified by this bot. +The project uses a DCO bot for all GitHub pulls to verify that each commit is signed off. When you create your pull request, it will automatically be verified by this bot. If your Pull Request fails the DCO check, it's necessary to fix the entire commit history in the PR. Although this is a situation we'd like to avoid the best practice is to squash the commit history to a single commit, append the DCO sign-off as described above or interactively in the rebase comment editing process, and force push. For example, if you have 2 commits in your history (Note the ~2): @@ -112,6 +112,7 @@ git push origin --force PGP (Pretty Good Privacy) is a method for encrypting and signing data. By signing your commits with PGP, you add another layer of security and verification. ### Setting up PGP + 1. Install gnupg * Linux: `sudo apt-get install gnupg` * Mac: `brew install gnupg` @@ -120,24 +121,31 @@ PGP (Pretty Good Privacy) is a method for encrypting and signing data. By signin 2. Generating a key In case you've already generated your PGP key pair before, you need to import a private key + ```bash gpg --import private.key ``` + If you have not generated your PGP key pair yet + ```bash gpg --full-generate-key ``` + and follow the instructions, make sure to associate this key with your email address. For key size, choose 4096 3. Using the key * **Local setup**: Set up git to automatically sign every commit with your PGP key, first get your GPG key id + ```bash gpg --list-keys ``` + will list all the keys you have available. copy the id of the key associated with your email address. configure git to use this key to sign every commit automatically + ```bash git config user.signingkey && git config commit.gpgsign true @@ -146,9 +154,11 @@ PGP (Pretty Good Privacy) is a method for encrypting and signing data. By signin ``` * **Remote setup**: You need to add the public key to Github, so that it can verify commits signed by the associated private key. Export your public key: + ```bash gpg --armor --export firstname.lastname@example.com ``` + This will output the key into your terminal. Copy the whole key (including -----BEGIN PGP PUBLIC KEY BLOCK----- and -----END PGP PUBLIC KEY BLOCK----- part) and add it [into your account](https://github.com/settings/keys) *NOTE:* Make sure to add your email address into [your github account emails](https://github.com/settings/emails) and confirm it. Github will allow you to add public keys associated with any email, but if this email is not added into your emails, it assumes that you are not the owner of this email address, and even if commits are signed with a proper private key, they will not be verified. @@ -156,14 +166,18 @@ PGP (Pretty Good Privacy) is a method for encrypting and signing data. By signin ### Troubleshooting In case commiting a change fails with the message + ```bash error: gpg failed to sign the data fatal: failed to write commit object ``` + try the following + ```bash gpgconf --kill gpg-agent export GPG_TTY=$(tty) echo "test" | gpg --clearsign ``` + if this problem keeps happening, try adding `export GPG_TTY=$(tty)` into your `~/.bashrc` or `~/.zshrc` file. diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 38bd7ef..b1b727c 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -30,8 +30,8 @@ Maintainers are assigned the following scopes in this repository: | Name | GitHub ID | Scope | LFID | Discord ID | Email | Company Affiliation | |----- | --------- | ----- | ---- | ---------- | ----- | ------------------- | | Anton Baliasnikov | antonbaliasnikov | Maintainer | | | | | -| Ahmed Moussa | hamada147 | Maintainer | | | | | -| Timothy Wells | blockchaintimothy | Maintainer | | timw_01400 | | | +| Ahmed Moussa | hamada147 | Maintainer | | | | | +| Timothy Wells | blockchaintimothy | Maintainer | | timw_01400 | | | | Cristian Gonzalez | cristianIOHK | Maintainer | | chet_to | | | | Dale Peek | Dale-iohk | Maintainer | | dale.doe | | | | Bassam Riman | CryptoKnightIOG | Maintainer | | _ | | | @@ -48,7 +48,6 @@ Maintainers are assigned the following scopes in this repository: | Shota Jolbordi | shotexa | Maintainer | | xesus1337 | | | | Kranium Mendoza | womfoo | Maintainer | | kraniumau | | | - ## The Duties of a Maintainer The expectation is for maintainers to perform the following duties for this repository. The responsibilities listed are in high to low-priority order: @@ -96,7 +95,7 @@ A PR has been created to update this file and add the proposed maintainer to the ## Removing Maintainers -Being a maintainer is not a status symbol or a title or indefinite. +Being a maintainer is not a status symbol or a title or indefinite. Moving the maintainer to emeritus status will occasionally be necessary and appropriate. The status change can occur in the following situations: @@ -117,9 +116,9 @@ resignation, the Pull Request is mergeable following a maintainer PR approval. I - The PR is authored by or has a comment supporting the proposal from an existing maintainer or Hyperledger GitHub organization administrator. - The approval timeframe begins upon receipt of the PR and necessary comments. - The PR **MAY** be communicated on appropriate channels, including relevant community calls, chat channels, and mailing lists. -- The PR gets merged, and the maintainer transitions to maintainer emeritus if: - - The PR gets approval from the maintainer to transition, OR - - Two weeks have passed since receipt of at least three (3) Maintainer PR approvals, OR +- The PR gets merged, and the maintainer transitions to maintainer emeritus if: + - The PR gets approval from the maintainer to transition, OR + - Two weeks have passed since receipt of at least three (3) Maintainer PR approvals, OR - An absolute majority of maintainers have approved the PR. - It may be closed if the PR does not get the requisite PR approvals. diff --git a/profile/README.md b/profile/README.md index 90d5c99..a8803b3 100644 --- a/profile/README.md +++ b/profile/README.md @@ -1,5 +1,6 @@ ![Identus](../resources/images/hyperledger-identus.svg) --- + Identus provides components to develop decentralized identity solutions that adhere to widely recognized self-sovereign identity (SSI) standards. It offers complete DID and verifiable credential functionality and simplifies the complexities of adopting a decentralized identity solution into existing and new workflows. ## Community Projects @@ -29,15 +30,15 @@ Identus provides components to develop decentralized identity solutions that adh - ## Quick Start Guide and Documentation To quickly get up and running and explore the project's capabilities: + - Follow the instructions in 💻 [dockerize-identus.md](https://github.com/hyperledger-identus/hyperledger-identus/blob/main/identus-docker/dockerize-identus.md) to have a local environment up and running. - Try the ⚡[Quick Start Guide](https://hyperledger-identus.github.io/docs/home/quick-start/) to explore the capabilities of Identus step by step. - Find more details about any topic you need by reading the project's 📄 [Documentation](https://hyperledger-identus.github.io/docs/). -## Project Roadmap +## Project Roadmap Are you interested in where Identus is headed? Check out the 🛣️[Project Roadmap](https://github.com/orgs/hyperledger-identus/projects/2) for upcoming features and planned improvements. @@ -48,12 +49,12 @@ Identus consists of several core components, each one with its own repository. T - [Cloud Agent](https://github.com/hyperledger/identus-cloud-agent/) - [Mediator](https://github.com/hyperledger/identus-mediator/) - Edge Agent SDKs: - - [TypeScript](https://github.com/hyperledger/identus-edge-agent-sdk-ts/) + - [TypeScript](https://github.com/hyperledger/identus-edge-agent-sdk-ts/) - [KMP](https://github.com/hyperledger/identus-edge-agent-sdk-kmp/) - [Swift](https://github.com/hyperledger/identus-edge-agent-sdk-swift/) - [Apollo Cryptographic Library](https://github.com/hyperledger/identus-apollo/) - Verifiable Data Registry (VDR): - - [VDR system API](https://github.com/hyperledger-identus/vdr) + - [VDR system API](https://github.com/hyperledger-identus/vdr) - [PRISM VDR](https://github.com/hyperledger-identus/prism-vdr-driver) - [Documentation](https://github.com/hyperledger/identus-docs/) @@ -65,7 +66,7 @@ The development of Identus relies on community input, and the project maintainer - 🪲 **Bugs:** Head to the relevant [GitHub repository](https://github.com/hyperledger-identus/hyperledger-identus/blob/main/README.md#repositories) and open an issue in the issue tracker. Detailed reports make fixing things much faster! - - 📝 **Documentation mistakes:** Please report it [here](https://github.com/hyperledger-identus/docs/issues). + - 📝 **Documentation mistakes:** Please report it [here](https://github.com/hyperledger-identus/docs/issues). - 💡 **Feature Requests:** Do you know how to improve Identus? Share your suggestion in an [issue](https://github.com/hyperledger-identus/hyperledger-identus/issues/new/choose), and we'll discuss how it could fit into the project's roadmap. @@ -85,4 +86,4 @@ The development of Identus relies on community input, and the project maintainer ### Community projects -Are you curious about what the community is building with Identus? Explore the 🌍[Community Projects](https://github.com/hyperledger-identus/hyperledger-identus/wiki/Community-Projects) to discover a variety of initiatives and tools created by developers and contributors like you. These projects showcase the versatility of Identus and can serve as inspiration or a foundation for your work. +Are you curious about what the community is building with Identus? Explore the 🌍[Community Projects](https://github.com/hyperledger-identus/hyperledger-identus/wiki/Community-Projects) to discover a variety of initiatives and tools created by developers and contributors like you. These projects showcase the versatility of Identus and can serve as inspiration or a foundation for your work. diff --git a/scripts/check-file-hygiene.py b/scripts/check-file-hygiene.py index c35afb6..3af48c1 100755 --- a/scripts/check-file-hygiene.py +++ b/scripts/check-file-hygiene.py @@ -26,7 +26,7 @@ ORG = "hyperledger-identus" TEMPLATE_REPO = ".github" -FILES = [".gitattributes", ".editorconfig", ".markdownlint.yml", ".yamllint.yml"] +FILES = [".gitattributes", ".editorconfig", ".markdownlint.yml", ".markdownlint-cli2.yaml", ".yamllint.yml"] # Repos to skip (the template repo itself) SKIP_REPOS = {TEMPLATE_REPO}