Hi 🖖! I am very excited that you are interested in contributing. However, before submitting your contribution, be sure to take a moment and read the following guidelines.
Before you create a Pull Request, please check whether your commits comply with the commit conventions used in this repository.
#<issueNumber>/<message>
Issue number must be prefixed with #
and separated from the message with a /
(forward slash).
Important
Issue number is NOT optional. If your commit does not resolve an issue, please create one first.
- Commit messages must have a subject line and may have body copy. These must be separated by a blank line.
- The subject line must be written in imperative mood (Fix, not Fixed / Fixes etc.)
- The body copy must only contain explanations as to what and why, never how. The latter belongs in documentation and implementation.
First word of the subject line must be one of the following:
First Word | Meaning |
---|---|
Add | Create a capability e.g. feature, test, dependency. |
Cut | Remove a capability e.g. feature, test, dependency. |
Fix | Fix an issue e.g. bug, typo, accident, misstatement. |
Bump | Increase the version of something e.g. dependency. |
Make | Change the build process, or tooling, or infra. |
Start | Begin doing something; e.g. create a feature flag. |
Stop | End doing something; e.g. remove a feature flag. |
Refactor | A code change that MUST be just a refactoring. |
Reformat | Refactor of formatting, e.g. omit whitespace. |
Optimize | Refactor of performance, e.g. speed up code. |
Document | Refactor of documentation, e.g. help files. |
Example:
#1/Add README.md
.#1/Update README.md
.#1/Fix typo in README.md
.#1/Cut README.md
.
- The main branch is basically a snapshot of the latest stable version. All development MUST be done in dedicated branches.
- Pull requests must be made against the
main
branch. - It is good to have multiple small commits while working on the PR. We'll let GitHub squash it automatically before the merge.
- Review your own code.
- Make sure that you didn't leave any debug code, console logs, etc.
- If you are adding a new feature, make sure that you have added documentation for it.
- Assign the PR to @GodHermit (Oleh Proidakov).
- If your PR is not ready for review yet, add the
[WIP]
prefix to the title.
- The PR will be merged once it has been approved by at least one maintainer.
- If there are any conflicts, the PR will be merged once the conflicts have been resolved. If you are not sure how to resolve the conflicts, ask for help in the comments.
- All conversations in the PR must be resolved before the PR can be merged.
- We use slightly modified Google TypeScript Style for the frontend part.
This project uses monorepo structure. So, first steps depend on what you want to do.
Important
This section is not yet applicable. Please wait for the backend part to be implemented.
- Clone the repository.
- Create a branch for your changes.
- Name your branch according to the following convention:
<issueNumber>/<branchName>
.
- Name your branch according to the following convention:
- Clone the repository.
- Create a branch for your changes.
- Name your branch according to the following convention:
<issueNumber>/<branchName>
.
- Name your branch according to the following convention:
- Run
npm install
in theweb-gui
directory. - Run
npm run dev
in theweb-gui
directory. - Open
http://localhost:3000
in your browser. - Make changes to the code and see them being reflected in the browser.
- Make sure that your changes are in accordance with the Code Style.
- Commit your changes.
- Push your changes to the remote repository.
- Create a Pull Request.
- Send the PR to the
main
branch. - Your pull request will be reviewed by the maintainers and the maintainers will decide if it is accepted or not
- Once the pull request is accepted, the maintainers will merge it to the main branch
- Send the PR to the
When making a visual change, please provide screenshots and/or screenshots of the proposed change. This will help us to understand the desired change easier.
When making a change that affects the documentation, please update the documentation accordingly. This will help us to keep the documentation up to date.
If you are interested in becoming a maintainer, start by reviewing issues. Answer questions for those in need of troubleshooting. Once we see you helping, either we will reach out and ask you if you want to join or you can ask one of the current maintainers to add you. We will try our best to be proactive in reaching out to those that are already helping out.
Being a maintainer is not an obligation. You can help when you have time and be less active when you don't. If you get a new job and get busy, that's alright.
This contributing guide is based on Next UI Contributing Guide.