- Introduction
- TL;DR
- Code of conduct
- Getting started
- Issues
- Pull requests
- SDKs
- Documentation
- Security
- Publishing
- License
- Community
Thanks for contributing to one of Kinde’s open source (OS) projects. With your help, contributors like you take Kinde OS projects to the next level 👏🏻.
Please take a moment to read over this document to make the contribution process easy and effective for everyone involved 👍🏾.
- Want to report a bug? Create an issue via the “Bug report” template.
- Want to contribute a new feature or any significant change? Please discuss it in the Kinde community first, or create an issue via the “Feature request” template.
- Have a general or a support-type related question? Please head to the Kinde community and ask there.
- Have you discovered a security vulnerability? Please refer to the Kinde vulnerability disclosure policy.
- Want to contribute code to one of Kinde’s SDKs? Please refer to the SDKs section.
Kinde takes its OS community seriously and holds both itself and other contributors to high standards of communication. Kinde’s goal is to foster a positive environment for contributors and to welcome newcomers.
Please review the code of conduct before engaging in Kinde’s OS projects.
There are many ways to get involved, including improving the documentation, submitting bug reports and feature requests, and, of course, writing code.
Most contributions begin with an issue. Once you’re ready to contribute code, a pull request (PR) is required. However, before contributing, please check first.
To contribute code, you will need a public GitHub account. If you don’t have one, you can join here.
All Kinde OS projects get hosted on GitHub under the following organizations:
- kinde-oss: A bunch of SDKs and libraries to work with the Kinde ecosystem.
- kinde-starter-kits: A bunch of starter kits to work with the Kinde ecosystem.
Each organization has one code repository per project, except for most SDK repositories where two can exist. For more information, refer to the SDKs section.
To save time and prevent duplicating work, it’s best to search the relevant project (repository) for open or closed issues or PRs related to your contribution. This is especially important for significant changes or enhancements.
You might also check in the Kinde community to see if an issue has a discussion history.
If it’s your first time contributing to an OS project and you’re feeling a little unsure how to go about it, check out these resources:
- 🎬 Video course on egghead: How to Contribute to an Open Source Project on GitHub
- 📄 One of the Open Source Guides: How to Contribute to Open Source
Or, if it’s more Kinde-specific, jump on the Kinde community and start a chat with one of the friendly Kinde staff.
🎓 You can read more about getting started with Github in GitHub Docs → Get started.
Issues is where everything gets logged against a project, including:
- Feature requests
- Bug reports
- Documentation issues
Issues should be the first port of call alongside the Kinde community when considering contributing to a Kinde OS project.
🎓 You can read more about issues in GitHub Docs → GitHub Issues.
Before you create a new issue, please check first.
Kinde provides templates per issue type, such as “Feature requests”, which get presented to you when creating a new issue.
These templates help you create your issue in a clear and specific way, saving everybody time.
Please assign the most relevant label to your issue.
🎓 You can read more about creating issues in GitHub Docs → Creating an issue.
Please follow these guidelines to ensure that everyone gets the most from your contributions.
- Strive for clear and concise writing to minimize the need for excessive communication. This also applies to comments on issues.
- Keep issue comments focused on the topic at hand.
- Don’t use issues for general or support-type related questions. Head over to the Kinde community for help instead.
- Don’t use issues to report security vulnerabilities. Refer to the Kinde vulnerability disclosure policy.
- We’d prefer if you don’t post issue comments consisting solely of “+1” or “👍”. Use GitHub’s ‘reactions’ feature instead.
- Format your prose and code so it’s clear and useable. See GitHub’s Basic writing and formatting syntax doc, also the Creating and highlighting code blocks doc. Further mentions:
- Link to an existing line or range of lines of code in your prose via GitHub’s Creating a permanent link to a code snippet feature.
- “@-mention” people where applicable via GitHub’s Mentioning people and teams feature.
- Reference existing issues and PRs via GitHub’s Referencing issues and pull requests feature.
To make a change to a Kinde OS project, you’ll need to submit a pull request (PR).
All PRs are welcome, from trivial fixes like correcting typos to more substantial changes like introducing new functionality.
Note: When contributing to a Kinde SDK project, please ensure you are contributing to the correct repository. Refer to the SDKs section for more information.
🎓 You can read more about PRs in GitHub Docs → Pull requests.
Before you create a new PR, please check first.
All PRs should be created from a fork. For instructions on how to do this, refer to GitHub’s Creating a pull request from a fork doc.
Please assign the most relevant label to your PR.
The core team is monitoring PRs. They will review your PR and either merge it, request changes, or close it with an explanation. The core team strives to review PRs promptly.
Please follow these guidelines to create tidy PRs.
- Keep your PR focused in scope - it should address a single concern using the fewest changed lines possible.
- Ensure your PR does not contain any unrelated commits. For related commits, please provide clear log messages.
- Help your reviewers understand the changes in your PR by providing a clear and concise description. If there’s an accompanying issue, link to it via GitHub’s Referencing issues and pull requests feature.
- Add tests for fixed or changed functionality if a test suite exists.
- Follow the code style guide if one. Projects may use tools like Prettier to apply a style guide automatically. Most projects also have “lint” tasks, such as
npm run lintfor npm libraries. If there is a lint task, please run it before submitting your PR. - As you update your PR and apply changes, mark each conversation as resolved via GitHub’s Resolving conversations feature.
Awesome! Thanks so much for contributing to a Kinde OS project.
Once your PR merges, your contributions are publicly visible in the relevant project and will be reflected in the project’s changelog.
Most of Kinde’s OS projects are comprised of software development kits (SDKs) that are generated using the OpenAPI Generator tool. As a result, each SDK has two repositories: one for the generator and one for the end code. For example, the Ruby SDK has the following repositories:
- Generator: kinde-ruby-generator
- End code: kinde-ruby-sdk
In most cases, contributions should be made against the generator repository since it creates the end code repository. However, there are cases where it makes sense to make changes to the end code repository, such as for test code that validates the overall use of the SDK.
In certain circumstances, it may be necessary to modify the Mustache templates used by the OpenAPI generator tool. One common reason for this is when you need to reference a user-written module from a generated code module.
Taking the TypeScript generator as an example, an additional line must get added to the generated index.ts code file to reference the user-written modules in the client.ts file. In this case, the index.mustache template file must get edited to refer to the client.ts code.
/* tslint:disable */
/* eslint-disable */
export * from './runtime';
{{#useSagaAndRecords}}
export * from './runtimeSagasAndRecords';
export * from './ApiEntitiesRecord';
export * from './ApiEntitiesReducer';
export * from './ApiEntitiesSelectors';
{{/useSagaAndRecords}}
{{#apiInfo}}
{{#apis.0}}
export * from './apis';
{{/apis.0}}
{{/apiInfo}}
{{#models.0}}
export * from './models';
{{/models.0}}
export * from './client/client'; /* This line was added */↑ An example of modifying a Mustache template in the TypeScript generator (reference file).
To avoid duplicating documentation between the Kinde docs and a project’s README, we prefer to link to the Kinde docs when possible.
If you encounter problems with the Kinde docs, believe something is missing or unclear, or spot a typo, please submit an issue via the “Documentation issues” template.
If a project does not have an accompanying Kinde doc and there are issues in the README, please feel free to raise them in an issue. For trivial changes, such as correcting a typo, go ahead and fix it via a PR.
If you discover a security vulnerability in a Kinde OS project, please report it through the Kinde vulnerability disclosure policy. Kinde’s security team closely monitors this policy to ensure that any reported vulnerabilities get promptly and appropriately addressed. For more information, please visit Security at Kinde.
The core team is in charge of handling version updates and publishing. We’re currently working on updating the documentation for this, and it should be available soon.
Kinde OS projects adhere to the Semantic Versioning standard, and we strive to ensure that changelogs are available for each project.
By contributing to Kinde, you agree that your contributions will be licensed under its MIT License.
Join us in the Slack Kinde community and post your questions there. A friendly Kinde staff member is always happy to help, and it might save you a lot of time.
Note: please submit your general or support-related questions in the Kinde community rather than on GitHub.
| Slack channel | For |
|---|---|
| #requests-and-feedback | Feature requests + product feedback |
| #questions | General questions |
| #kinde-support | Support questions and reporting bugs |
| #documentation | Reporting documentation issues |