We value contributions to App Identity—bug reports, discussions, feature requests, and code contributions. New features should be proposed and discussed prior to implementation, and release of any new feature may be delayed until implemented in the reference implementations.
Before contributing patches, please read the Licence.
App Identity is governed under the Kinetic Commerce Open Source Code of Conduct.
We have several guidelines to contributing code through pull requests to App Identity reference implementations:
-
All code changes require tests. In most cases, this will be added or updated unit tests for the implementations: ExUnit (Elixir), minitest (Ruby), or vitest (Typescript).
In some cases, new integration tests will be required, which will require updates to the integration test generators for all implementations.
-
We use code formatters, static analysis tools, and linting to ensure consistent styles and formatting. There should be no warnings output from compile or test run processes.
-
Proposed changes should be on a thoughtfully-named topic branch and organized into logical commit chunks as appropriate.
-
Use Conventional Commits with our conventions.
-
Versions must not be updated in pull requests; implementations may have other restrictions on file updates as they are part of the release process.
-
Documentation should be added or updated as appropriate for new or updated functionality.
-
New dependencies are discouraged and their addition must be discussed, regardless whether it is a development dependency, optional dependency, or runtime dependency.
-
All GitHub Actions checks marked as required must pass before a pull request may be accepted and merged.
App Identity has adopted the Conventional Commits format for commit messages.
Because there are three reference implementations, integration tests, and a
specification in this repository, the (scope)
is required for most commits.
The scope
constraints the permitted commit type
s, as outlined below.
scope |
Purpose | Allowed type s |
Example |
---|---|---|---|
spec |
Updates to the App Identity spec. | feat , fix , chore |
feat(spec) |
int |
Updates to integration test specification or definitions | feat , fix , chore |
feat(int) |
int/elixir |
Updates to Elixir integration test support | feat , fix , chore |
feat(int/elixir) |
int/ruby |
Updates to Ruby integration test support | feat , fix , chore |
feat(int/ruby) |
int/ts |
Updates to Typescript integration test support | feat , fix , chore |
feat(int/ts) |
elixir |
Updates to the Elixir implementation | feat , fix , chore , docs , deps |
docs(elixir) |
ruby |
Updates to the Ruby implementation | feat , fix , chore , docs , deps |
fix(ruby) |
ts |
Updates to the Typescript implementation | feat , fix , chore , docs , deps |
feat(ts) |
Updates to global documentation or configuration | feat , fix , chore , docs , deps |
chore |
Updates to GitHub Actions may be global, but should be scoped if applied to a single implementation's workflow.
We encourage the use of Tim Pope's or Chris Beam's guidelines on the writing of commit messages
We require the use of git trailers for specific additional metadata and strongly encourage it for others. The conditionally required metadata trailers are:
-
Breaking-Change
: if the change is a breaking change. Do not use the shorthand form (feat!(scope)
) orBREAKING CHANGE
. -
Signed-off-by
: required for non-Kinetic Commerce contributors, as outlined in the Licence. -
Fixes
orResolves
: If a change fixes one or more open issues, that issue must be included in theFixes
orResolves
trailer. Multiple issues should be listed comma separated in the same trailer:Fixes: #1, #5, #7
, but may appear in separate trailers. While bothFixes
andResolves
are synonyms, only one should be used in a given commit or pull request. -
Related to
: If a change does not fix an issue, those issue references should be included in this trailer. -
Discussion
: If a change is related to a discussion, those discussion URLs should be inDiscussion
trailers.
Austin Ziegler (@halostatue), Mike Stok (@mikestok), and Nitin Malik (@ohnit) created and maintained the Elixir and Ruby versions of the original code at Kinetic Commerce that defined what has become App Identity.