Contributing Guidelines

We love your input! We want to make contributing to this project as easy and transparent as possible, whether it's:
Reporting a bug
Discussing the current state of the code
Submitting a fix
Proposing new features
We use Github to host code, to track issues and feature requests, as well as accept pull requests. Pull requests are the best way to propose changes to the codebase.
Report bugs using Github's issues​
We use GitHub issues to track bugs. Report a bug by opening a new issue; it's that easy!
Just make sure to write bug reports with details, background, and sample code.
Great Bug Reports tend to have:
A quick summary and/or background
Steps to reproduce
Be specific!
Give sample code if you can.
What you expected would happen.
What actually happens.
Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
How to contribute?
1.Fork the repo and create your branch from master.
2.Add your code and tests if needed.
3.Ensure the code is clean.
4.Always format your code using prettier.
5.Ensure your commits are small and tidy.
6.You may also update the documentation if needed.
7.Issue that pull request and write an awesome description that describes what you did!
Pull requests gets automatically deployed to Vercel so you can test your changes live
Merging a Pull Request
We use semantic-release to automatically publish packages from master to npm, which is relying on the commit message format below to determine the next release based on it.
When merging a PR, make sure that it has at least one commit with this commit format below. If it doesn't, squash the PR and use this format as a title then merge.
Commit Message Format
For a detailed specification, please visit Conventional Commits​
<type>(<package>): <short summary>
  │       │             │
  │       │             └─> A short description of the code change. In present tense. Not capitalized.
  │       │
  │       └─> Package affected: frontend|hooks|components. Can be more than one.
  │
  └─> Commit Type: build|ci|docs|feat|fix|test
<type> and <short summary> fields are required, but the (<package>) field is optional.
Commit type explanation
build: Changes that affect the build or management system only (example: yarn, tsconfig.js, package.json)
ci: Changes to our CI configuration files and scripts (examples: .github/workflows)
docs: Documentation only changes
feat: A new feature
fix: A bug fix
test: Adding tests or correcting existing tests

Introduction

Next - Frontend

Overview

Last modified 6mo ago

Copy link

Outline

Report bugs using Github's issues

How to contribute?

Merging a Pull Request

Commit Message Format

Report bugs using Github's issues​

How to contribute?

Merging a Pull Request

Commit Message Format

Report bugs using Github's issues