git: merge branch 'develop'

Signed-off-by: Vedant K <gamemaker0042@gmail.com>

Author: gamemaker1

contributing.md

@@ -6,11 +6,11 @@ The following is a set of guidelines for contributing to Dabbu CLI. These are ju
 
 ## Issues
 
-You can contribute to Dabbu CLI by reporting bugs, fixing bugs, adding features, and spreading the word! If you want to report a bug, create an issue by the clicking [here](https://github.com/dabbu-knowledge-platform/cli/issues/new/choose). While creating an issue, try to follow the Bug report or Feature request template.
+You can contribute to Dabbu CLI by reporting bugs, fixing bugs, adding features, and spreading the word! If you want to report a bug, create an issue by clicking [here](https://github.com/dabbu-knowledge-platform/cli/issues/new/choose). While creating an issue, try to follow the Bug report or Feature request template.
 
 ## Pull requests
 
-This guide assumes you are familiar with Github and the command line. If not, [here](https://guides.github.com/activities/hello-world/) is a guide to get started with Github. If you are stuck on something, feel free to ask on [Github Discussions](https://github.com/dabbu-knowledge-platform/cli/discussions/categories/want-to-want-to-contribute).
+This guide assumes you are familiar with Github and the command line. If not, [here](https://guides.github.com/activities/hello-world/) is a guide to get started with Github. If you are stuck on something, feel free to ask on [Github Discussions](https://github.com/dabbu-knowledge-platform/cli/discussions/categories/want-to-contribute).
 
 ### Step 0: Environment
 
@@ -32,7 +32,7 @@ Install `git`, `nodejs` and `npm`.
 
 ### Step 1: Fork
 
-Fork the project [on the GitHub site](https://github.com/dabbu-knowledge-platform/cli) and clone your fork locally.
+Fork the project [on the GitHub website](https://github.com/dabbu-knowledge-platform/cli) and clone your fork locally.
 
 Run the following in a terminal to clone your fork locally:
 
@@ -51,10 +51,19 @@ Once you've built the project locally, you're ready to start making changes!
 
 ### Step 3: Branch
 
-To keep your development environment organized, create local branches to hold your work. These should be branched directly off of the `main` branch. While naming branches, try to name it according to the bug it fixes or the feature it adds.
+To keep your development environment organized, create local branches to hold your work. These should be branched directly off of the `develop` branch. While naming branches, try to name it according to the bug it fixes or the feature it adds. Also prefix the branch with the type of change it is making. Here is a list of common prefixes:
+
+- `fix/`: A bug fix
+- `feature/`: A new feature
+- `docs/`: Documentation changes
+- `perf/`: A code change that improves performance
+- `refactor/`: A code change that neither fixes a bug nor adds a feature
+- `test/`: A change to the tests
+- `style/`: Changes that do not affect the meaning of the code (linting)
+- `build/`: Bumping a dependency like node or express
 
 ```sh
-$ git checkout -b fix-buggy-bug -t upstream/main
+$ git checkout -b feature/add-awesome-new-feature -t upstream/develop
 ```
 
 ### Step 4: Code
@@ -71,32 +80,74 @@ To test a change without building the executables, you can type `npm start` and
 
 > While running the CLI for the first time, you will be asked to enter the URL to a Dabbu Server. For testing and development purposes, you may use the server hosted on Heroku - https://dabbu-server.herokuapp.com - but for continued use, it is recommended to setup your own server following the instructions [here](https://dabbu-knowledge-platform.github.io/impls/server).
 
-Remember to always format the code using `prettier` once you're done. To check if the code is formatted correctly, run `npm run check-format`. To format the code using prettier, run `npm run format`.
+Remember to always format the code using `xo` once you're done.
+
+### Step 5: Document
+
+Once your changes are ready to go, begin the process of documenting your code. The code **must** be heavily commented, so future contributors can move around and make changes easily.
+
+If you are adding new features, or making changes to the behaviour of existing features, make sure you create a separate pull request in the [user docs repository](https://github.com/dabbu-knowledge-platform/dabbu-knowledge-platform.github.io/), and add relevant info to the `impls/cli.md` page. Also add the same changes to the `readme.md` file.
+
+The documentation uses jekyll. To set up jekyll on your computer and make changes to the documentation, follow [this](https://docs.github.com/en/github/working-with-github-pages/testing-your-github-pages-site-locally-with-jekyll) guide.
+
+### Step 6: Test
+
+Before submitting your changes, please run the linter (`xo`):
+
+```
+npm test
+```
+
+Please ensure that:
+
+- your code passes all lint checks (`xo`)
+- your code passes all format checks (`prettier` run by xo) 
+
+If the linter points out errors, try fixing them automatically by running:
+
+```
+npm run format
+```
+
+The linter will try its best to fix all issues, but certain issues require you to fix them manually.
+
+If you need to disable any lint rules, please make sure that it is really necessary and there is absolutely no better way of writing that piece of code. Disable lint checks for a certain line by entering typing the following before that line:
+
+```
+// eslint-disable-next-line some-lint-rule-id
+```
+
+To disable lint checks for an entire file (not recommended), enter the following at the top of the file:
+
+```
+/* eslint some-lint-rule-id: 0 */
+```
 
-If you find yourself stuck somewhere, or need help with some code, feel free to ask for help on [Github Discussions](https://github.com/dabbu-knowledge-platform/cli/discussions/categories/want-to-contribute).
+All existing and added tests **MUST** pass for the PR to land. If existing tests are already failing on the `develop` branch, ensure that no additional tests fail due to your changes. Note that **no PRs will be merged until the tests on the `develop` branch are fixed and all of them pass**.
 
-### Step 5: Commit
+### Step 7: Commit
 
 It is recommended to keep your changes grouped logically within individual commits. Many contributors find it easier to review changes that are split across multiple commits. There is no limit to the number of commits in a pull request.
 
 ```sh
 $ git add my/changed/files
-$ git commit -m "<commit message>"
+$ git commit
 ```
 
 Note that multiple commits often get squashed when they are landed.
 
 #### Commit message guidelines
 
-A good commit message should describe what changed and why. This project uses [semantic commit messages](https://conventionalcommits.org/) to streamline the release process.
+A good commit message should describe what changed and why. This project uses [semantic commit messages](https://conventionalcommits.org/) to streamline
+the release process.
 
 Before a pull request can be merged, it **must** have a pull request title with a semantic prefix.
 
-Examples of commit messages with semantic prefixes: (Also, note that they must be in present tense)
+Examples of commit messages with semantic prefixes:
 
-- `fix: fix crash in Google Drive client`
-- `feat: add MS OneDrive client for CLI`
-- `docs: fix typo in README.md`
+- `fix: don't reload config everytime`
+- `feat: add MS OneDrive provider`
+- `docs: fix typo in APIs.md`
 
 Common prefixes:
 
@@ -105,8 +156,9 @@ Common prefixes:
 - `docs`: Documentation changes
 - `perf`: A code change that improves performance
 - `refactor`: A code change that neither fixes a bug nor adds a feature
+- `test`: A change to the tests
 - `style`: Changes that do not affect the meaning of the code (linting)
-- `vendor`: Bumping a dependency like node or express
+- `build`: Bumping a dependency like node or express
 
 Other things to keep in mind when writing a commit message:
 
@@ -122,35 +174,23 @@ A commit that has the text `BREAKING CHANGE:` at the beginning of its optional b
 
 See [conventionalcommits.org](https://conventionalcommits.org) for more details.
 
-### Step 6: Rebase
+### Step 8: Rebase
 
-Once you have committed your changes, it is a good idea to use `git rebase` (_NOT `git merge`_) to synchronize your work with the main repository.
+Once you have committed your changes, it is a good idea to use `git rebase` (NOT `git merge`) to synchronize your work with the develop branch.
 
 ```sh
 $ git fetch upstream
-$ git rebase upstream/main
+$ git rebase upstream/develop
 ```
 
-This ensures that your working branch has the latest changes from `dabbu-knowledge-platform/cli` main.
-
-### Step 7: Test
-
-Bug fixes and features should always come with tests. Please test your own code adequately. Also, before finally pushing your code, clone it into a fresh environment (different user or maybe a different computer) and make sure it works just as fine. Make sure you test the executables in the `dist/` directory.
-
-### Step 8: Document
-
-Once your commits are ready to go - with adequate testing - begin the process of documenting your code. The code **must** be heavily commented, so future contributors can move around and make changes easily.
-
-If you are adding new features, or making changes to the behaviour of existing features, make sure you create a separate pull request in the [user docs repository](https://github.com/dabbu-knowledge-platform/dabbu-knowledge-platform.github.io/), and add relevant info to the `impls/cli.md` page.
-
-The documentation uses jekyll. To set up jekyll on your computer and make changes to the documentation, follow [this](https://docs.github.com/en/github/working-with-github-pages/testing-your-github-pages-site-locally-with-jekyll) guide.
+This ensures that your working branch has the latest changes from `dabbu-knowledge-platform/cli` develop. If any conflicts arise, resolve them and commit the changes again.
 
 ### Step 9: Push
 
 Once you have documented your code as required, begin the process of opening a pull request by pushing your working branch to your fork on GitHub.
 
 ```sh
-$ git push origin fix-buggy-bug
+$ git push origin feature/add-awesome-new-feature
 ```
 
 ### Step 10: Opening the Pull Request
@@ -166,21 +206,21 @@ To make changes to an existing pull request, make the changes to your local bran
 ```sh
 $ git add my/changed/files
 $ git commit
-$ git push origin fix-buggy-bug
+$ git push origin feature/add-awesome-new-feature
 ```
 
-There are a number of more advanced mechanisms for managing commits using `git rebase` that can be used, but are beyond the scope of this guide.
+There are a number of more advanced mechanisms for managing commits using `git rebase` that can be used, but are beyond the scope of this guide. Also, any branch that is being merged must be merged without fast forward, i.e., `git merge --no-ff ...`.
 
 Feel free to post a comment in the pull request to ping reviewers if you are awaiting an answer on something.
 
 **Approval and Request Changes Workflow**
 
-All pull requests require approval from contributors in order to land. Whenever a maintainer reviews a pull request they may request changes. These may be small, such as fixing a typo, or may involve substantive changes. Such requests are intended to be helpful, but at times may come across as abrupt or unhelpful, especially if they do not include concrete suggestions on _how_ to change them.
+All pull requests require approval from at least one maintainer in order to land. Whenever a maintainer reviews a pull request they may request changes. These may be small, such as fixing a typo, or may involve substantive changes. Such requests are intended to be helpful, but at times may come across as abrupt or unhelpful, especially if they do not include concrete suggestions on _how_ to change them.
 
 Try not to be discouraged. Try asking the maintainer for advice on how to implement it. If you feel that a review is unfair, say so or seek the input of another project contributor. Often such comments are the result of a reviewer having taken insufficient time to review and are not ill-intended. Such difficulties can often be resolved with a bit of patience. That said, reviewers should be expected to provide helpful feedback.
 
 ### Step 12: Landing
 
-In order to land, a pull request needs to be reviewed and approved by at least one contributor. After that, if there are no objections from other contributors, the pull request can be merged.
+In order to land, a pull request needs to be reviewed and approved by at least one maintainer. After that, if there are no objections from other contributors, the pull request can be merged.
 
 **Congratulations and thanks a lot for your contribution!**