sleek-dashboard

# Contributing Guidelines Hi! we are really excited that you are interested in contributing to Sleek. Before submitting your contribution though, please make sure to take a moment and read through the following guidelines. - [Issue Reporting Guidelines](#issue-reporting-guidelines) - [Pull Request Guidelines](#pull-request-guidelines) - [Commit Message Guidelines](#commit-message-guidelines) - [Code of Conduct](#code-of-conduct) ## Issue Reporting Guidelines We use GitHub Issues as the official bug tracker for the Sleek Dashboard. Please Search [existing issues](https://github.com/tafcoder/sleek-dashboard/issues). It’s possible someone has already reported the same problem. If your problem or idea is not addressed yet, [open a new issue](https://github.com/tafcoder/sleek-dashboard/issues) ## Pull Request Guidelines - The `master` branch is basically just a snapshot of the latest stable release. All development should be done in dedicated branches. **Do not submit PRs against the `master` branch.** - Work in the `src` folder. - It's OK to have multiple small commits as you work on the PR - Commit messages should follow the [Commit Message Guidelines](#commit-message-guidelines) so that changelogs can be automatically generated.. - If adding new feature: - Provide convincing reason to add this feature. Ideally you should open a suggestion issue first and have it greenlighted before working on it. - If fixing a bug: - If you are resolving a special issue, add `(fix #xxxx[,#xxx])` (#xxxx is the issue id) in your PR title for a better release log, e.g. `update entities encoding/decoding (fix #3899)`. - Provide detailed description of the bug in the PR. Live demo preferred. ## Commit Message Guidelines We have very precise rules over how our git commit messages can be formatted. This leads to **more readable messages** that are easy to follow when looking through the **project history**. But also, we use the git commit messages to **generate the change log**. ### Full Message Format A commit message consists of a **header**, **body** and **footer**. The header has a **type** and **subject**: ``` c <type>: <subject> <BLANK LINE> <body> <BLANK LINE> <footer> ``` The **header** is mandatory. ### Revert If the commit reverts a previous commit, it should begin with `revert:` , followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted. ### Type Must be one of the following: - **feat**: A new feature - **fix**: A bug fix - **docs**: Documentation only changes - **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) - **refactor**: A code change that neither fixes a bug nor adds a feature - **perf**: A code change that improves performance - **test**: Adding missing or correcting existing tests - **chore**: Changes to the build process or auxiliary tools and libraries such as documentation generation ### Subject (Mandatory) The subject contains succinct description of the change: - use the imperative, present tense: "change" not "changed" nor "changes" - don't capitalize first letter - no dot (.) at the end ### Body (Not Mandatory) Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior. ### Footer (Not Mandatory) The footer should contain any information about **Breaking Changes** and is also the place to reference GitHub issues that this commit **Closes**. **Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. The rest of the commit message is then used for this. #### Examples Messages must be matched by the following regex: ``` js /^(revert: )?(feat|fix|polish|docs|style|refactor|perf|test|workflow|ci|chore|types)(\(.+\))?: .{1,50}/ ``` To add "Features" : ``` c feat: add 'comments' option ``` To make "Bug Fixes" with a link to issue #28: ``` c fix: handle events on blur close #28 ``` To make "Performance Improvements" and under "Breaking Changes" with the breaking change explanation: ``` c perf: improve time consuming by removing 'foo' option BREAKING CHANGE: The 'foo' option has been removed. ``` The following commit and commit `667ecc1` do not appear in the changelog if they are under the same release. If not, the revert commit appears under the "Reverts" header. ``` c revert: feat: add 'comments' option This reverts commit 667ecc1654a317a13331b17617d973392f415f02. ``` ## Code of Conduct In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. For more details please check: [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md)