mirror of
https://github.com/Infisical/infisical.git
synced 2026-01-09 23:48:05 -05:00
Added getting started section
This commit is contained in:
59
docs/contributing/getting-started/overview.mdx
Normal file
59
docs/contributing/getting-started/overview.mdx
Normal file
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: "Overview"
|
||||
description: "Contributing to the Infisical ecosystem."
|
||||
---
|
||||
|
||||
To set a strong foundation, this section outlines how we, the community and members of Infisical,
|
||||
should approach the development and contribution process.
|
||||
|
||||
## Code-bases
|
||||
Infisical has two major code-bases. One for the platform code, and one for SDKs. The contribution process has some key differences between the two, so we've split the documentation into two sections:
|
||||
|
||||
- The [Infisical Platform](https://github.com/Infisical/infisical), the Infisical platform itself.
|
||||
- The [Infisical SDK](https://github.com/Infisical/sdk), the official Infisical client SDKs.
|
||||
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Infisical Platform" href="/contributing/platform/developing" icon="layer-group" color="#A1B659">
|
||||
The Infisical platform is the core of the Infisical ecosystem.
|
||||
</Card>
|
||||
<Card href="/contributing/sdk/developing" title="Infisical SDK" icon="code" color="#A1B659">
|
||||
The SDKs are the official Infisical client libraries, used by developers to easily interact with the Infisical platform.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Community
|
||||
|
||||
We are building an inclusive community, and this means adhering to the [Code of Conduct](/contributing/getting-started/code-of-conduct).
|
||||
|
||||
## Bugs and issues
|
||||
|
||||
Bug reports help make Infisical a better experience for everyone. When you report a bug, a template will be created automatically containing information we'd like to know.
|
||||
|
||||
Before raising a new issue, please search existing ones to make sure you're not creating a duplicate.
|
||||
|
||||
<Info>
|
||||
If the issue is related to security, please email us directly at
|
||||
team@infisical.com.
|
||||
</Info>
|
||||
|
||||
## Deciding what to work on
|
||||
|
||||
You can start by browsing through our list of issues or adding your own that improves on the platform experience. Once you've decided on an issue, leave a comment and wait to get approved; this helps avoid multiple people working on the same issue.
|
||||
|
||||
If you're ever in doubt about whether or not a proposed feature aligns with Infisical as a whole, feel free to raise an issue about it and we'll get back to you promptly.
|
||||
|
||||
## Writing and submitting code
|
||||
|
||||
Anyone can contribute code to Infisical. To get started, check out the local development guides for each language.
|
||||
|
||||
- Local development guide for Platform is [here](/contributing/platform/developing).
|
||||
- Local development guide for SDK is [here](/contributing/sdk/developing).
|
||||
|
||||
|
||||
## Licensing
|
||||
|
||||
Most of Infisical's code is under the MIT license, though some paid feature restrictions are covered by a proprietary license.
|
||||
|
||||
Any third party components incorporated into our code are licensed under the original license provided by the applicable component owner.
|
||||
|
||||
49
docs/contributing/getting-started/pull-requests.mdx
Normal file
49
docs/contributing/getting-started/pull-requests.mdx
Normal file
@@ -0,0 +1,49 @@
|
||||
---
|
||||
title: 'Pull requests'
|
||||
description: 'This guide walks through the code submission process for Infisical.'
|
||||
---
|
||||
|
||||
## Making a pull request
|
||||
|
||||
Once you are done making changes in local development, you can submit a pull request (PR) to the main repository branch.
|
||||
|
||||
We require a few considerations on your part to ensure that PRs are easy to review and up to standard with the code.
|
||||
|
||||
### Title and content
|
||||
|
||||
Start by providing a concise title addressing what your PR achieves such as "add pagination to retrieve environment variables for GitLab integration."
|
||||
|
||||
You should follow the automatically-generated PR template to fill in the PR description. This includes a more detailed description of the changes in the PR, the type of PR, and an acknowledgement that you've read and agreed to the contributing guidelines.
|
||||
|
||||
### Feature PRs
|
||||
|
||||
Give a functional overview of how your feature works, including how the user can use the feature. Then share any technical details in an overview of how the PR works.
|
||||
|
||||
As of `06-01-2023`, all PRs created after this date are required to attach a video of you performing the described functionality.
|
||||
|
||||
### Bug Fix PRs
|
||||
|
||||
Give an overview of the bug at hand and how your PR fixes the it at both a high and low level.
|
||||
|
||||
Feel free to add a short video or screenshots of what your PR achieves.
|
||||
|
||||
## Getting your PR reviewed
|
||||
|
||||
Once your PR is reviewed, one or two relevant members of the Infisical team should review and approve the PR before it is merged. You should coordinate and ping the team member closest to the submitted functionality via our [Slack](https://infisical.com/slack) to review your PR.
|
||||
|
||||
- Vlad: Frontend, Web UI
|
||||
- Tony: Backend, SDKs, Security
|
||||
- Maidul: Backend, CI/CD, CLI, Kubernetes Operator
|
||||
- Daniel: Frontend, UI/UX, Backend, SDKs
|
||||
|
||||
|
||||
The team member(s) will start by enabling baseline checks to ensure that there are no leaked secrets, new dependencies are clear, and the frontend/backend services start up. Afterward, they will review your PR thoroughly by testing the code and leave any feedback or work in with you to revise the PR up to standard.
|
||||
|
||||
Once everything is good, the team member(s) will approve the PR to be merged into the `main` branch; all changes will be tested in CI/CD and our staging environment first before being deployed to production.
|
||||
|
||||
<Note>
|
||||
Due to the high volume of issues, PRs, etc. from the community, and limited bandwidth on our end to address everything instantly, we prefer
|
||||
reviewing PRs once they are fully complete and well-tested.
|
||||
|
||||
In the past, we've often had to review low-quality PRs up to 10 times which severely restricts our capacity to address other issues, PRs, and initiatives in the pipeline. As such, we ask of the community to submit higher-quality PRs that, for example, don't break existing code; in return we'll prioritize the first 3 reviews for PRs.
|
||||
</Note>
|
||||
Reference in New Issue
Block a user