docs: correction in links to assets in md files

.docs/CONTRIBUTING.md

@@ -34,14 +34,14 @@ We are happy to welcome contributions from anyone willing to add to or improve t
 
     - Your PR title must be in the form of `PR_TYPE: PR_TITLE`
       - eg, `feat: new funky section`, `fix: fix the fencepost error`, `docs: add link to discord`, `style: make header component responsive`, `chore: add walkingpal logo`
-      - Refer [Git Commit Guidelines](./GIT-GUIDELINES.MD) for more details
+      - Refer [Git Commit Guidelines](.docs/GIT-GUIDELINES.md) for more details
     - Make sure you have created an issue for your PR. [Link that issue to your PR](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue).
     - Mention your proposed changes in the PR description along with screenshots and reference links (if applicable).
-    - If you created new files, make sure they follow [Project Structure Guidelines](./PROJECT-STRUCTURE.md).
+    - If you created new files, make sure they follow [Project Structure Guidelines](.docs/PROJECT-STRUCTURE.md).
     - Your work must be **original**, written by you, not copied from other resources. Copying is not bad. But copying without properly understanding which parts of the code are needed and which are not is very bad. Make sure you avoid adding redundant code.
     - You must **comment** on your code wherever necessary. **Avoid committing commented code**, e.g `console.log` statements, etc.
     - For **frontend changes** kindly share screenshots and samples of your work before sending a PR.
-    - For **frontend changes**, abide by the [STYLE GUIDE](./STYLE-GUIDE.md).
+    - For **frontend changes**, abide by the [STYLE GUIDE](.docs/STYLE-GUIDE.md).
     - ⚠**IMPORTANT**⚠ After creating your PR, Vercel will try to automatically deploy your PR code. If your Vercel build fails in your PR, you need to run `yarn build` locally and address those build errors. Your PR won't be reviewed until after the build errors have been fixed. It would be considered a WIP draft PR.
 
   ***
@@ -106,11 +106,11 @@ To access the `/register` and `/faq` pages on the webapp seamlessly, follow the
 
 1. Head to the [reCAPTCHA admin console](https://www.google.com/recaptcha/admin/create) and fill in the required details.
 
-![recaptcha-registration](./assets/recaptcha-registration.jpg)
+![recaptcha-registration](.docs/assets/recaptcha-registration.jpg)
 
 2. After clicking submit, you should be able to see the public and secret keys.
 
-![recaptcha-keys](./assets/recaptcha-keys.jpg)
+![recaptcha-keys](.docs/assets/recaptcha-keys.jpg)
 
 3. Create a file called .env.local and add the following to it. Then paste the keys you copied from the reCAPTCHA dashboard appropriately.
 
@@ -211,7 +211,7 @@ To learn more about Next.js, take a look at the following resources:
     # Now start working on your bugfix
    ```
 3. After finishing the bugfix, stage all your changes using the `git add` command.
-4. Commit all those changes with a nice commit message that follows [our commit message guidelines](./GIT-GUIDELINES.MD).
+4. Commit all those changes with a nice commit message that follows [our commit message guidelines](.docs/GIT-GUIDELINES.md).
 
    - If you get an error from husky commit-msg hook after running `git commit` command, this means that your commit message does not follow the commit guidelines. Correct your commit message.
 
@@ -220,13 +220,13 @@ To learn more about Next.js, take a look at the following resources:
    git push origin <your-branch-name> #in our example the branch name is "fix/button-onclick"
    ```
 6. After pushing you will see a create pull request link as shown in the figure shown below:
-   ![Creating A PR](./assets/creating-pr.png)
+   ![Creating A PR](.docs/assets/creating-pr.png)
    Create your Pull Request using that link 🎉
 
 ## Converting existing PR to draft PR
 
 If your Pull Request is a work in progress: go to your Pull Request and click on `Convert to draft` to convert it to a Draft PR.
-![Converting Existing PR to Draft PR](./assets/how-to-draft-PR.png)
+![Converting Existing PR to Draft PR](.docs/assets/how-to-draft-PR.png)
 
 ## Making changes to an existing PR
 

.docs/GIT-GUIDELINES.MD → .docs/GIT-GUIDELINES.md

@@ -2,31 +2,35 @@
 
 ### 🚨 **Be a good commitizen** 🚨
 
-##### When creating a commit, writing a good commit message is very important. 
+##### When creating a commit, writing a good commit message is very important.
 
 For a detailed Guide [follow this link](https://www.freecodecamp.org/news/how-to-write-better-git-commit-messages/). Else follow the guide given below.
 
 Commit messages are written in the following format:
+
 ```sh
 commit_type(scope): commit message
 ```
+
 - The `commit_type` can include the following types:
+
   1. **feat** – used when a new feature is introduced
-  2. **fix** – used when a bug fix is added 
-  3. **chore** – for changes that do not relate to a fix or feature and don't modify src or test files (*for example* updating dependencies, adding assets like images, config file changes)
+  2. **fix** – used when a bug fix is added
+  3. **chore** – for changes that do not relate to a fix or feature and don't modify src or test files (_for example_ updating dependencies, adding assets like images, config file changes)
   4. **refactor** – for "code refactor" changes, i.e changes in the code that neither fixes a bug nor adds a feature
   5. **docs** – for changes to the documentation such as the README.md or other markdown files
   6. **style** – for changes that do not affect the meaning of the code, likely related to code formatting such as white-space, missing semi-colons, and so on.
   7. **perf** – for performance improvements changes.
-  8. **ci** – for changes related to continuous integration 
+  8. **ci** – for changes related to continuous integration
   9. **build** – for changes that affect the build system or external dependencies
 
 - The `scope` can be a name of a page or a component. **Mentioning a scope is optional**. It should be mentioned whenever possible.
-**Examples**: `home`, `faq`, `company`, `header`, `footer` etc.
+  **Examples**: `home`, `faq`, `company`, `header`, `footer` etc.
 
 - `commit message` is a simple lowercase string that describes all the edits/changes you have made in your commit.
 
 ##### Examples of how to create a good commit message
+
 1. Suppose you added a feature in the home page and that feature is all about creating a new Events section.
 
    - So, your commit message must look like this: `feat(home): new events section`
@@ -35,4 +39,3 @@ commit_type(scope): commit message
    - So, your commit message must look like this: `fix(header): fix header component onClick event`
    - Observe that here `header` scope represents the [Header component](../components/Header/Header.tsx). The Header component is a global component. Global Components are the components that are used by more than one components/pages. Since this component does not belong to just a single page, we did not write the name of a page in the scope, instead, we wrote the name of the component (i,e `header`).
    - Also, observe that the commit message is always written in lowercase.
-

.docs/PROJECT-GUIDELINES.md

@@ -1,5 +1,5 @@
 # Project Guidelines
 
 - walking-pal-web is a [Next.js](https://nextjs.org/) project.
-- We strictly abide by our [Style Guide](./STYLE-GUIDE.md) to style our React components.
-- We have an opinionated Project file structure, always follow our [Project Structure Guide](./PROJECT-STRUCTURE.md) when creating new files/folders.
+- We strictly abide by our [Style Guide](.docs/STYLE-GUIDE.md) to style our React components.
+- We have an opinionated Project file structure, always follow our [Project Structure Guide](.docs/PROJECT-STRUCTURE.md) when creating new files/folders.

.docs/STYLE-GUIDE.md

@@ -11,5 +11,5 @@ All our React Components are created using [Material UI](https://mui.com/materia
 
 ### Following the Color System and Font System
 
-1. We follow the material color system. Follow our [Color System Guide](./COLOR-SYSTEM.md).
-2. We follow the material Font Type system. Follow out [Type System Guide](./TYPE-SYSTEM.md)
+1. We follow the material color system. Follow our [Color System Guide](.docs/COLOR-SYSTEM.md).
+2. We follow the material Font Type system. Follow out [Type System Guide](.docs/TYPE-SYSTEM.md)

.docs/TYPE-SYSTEM.md

@@ -3,7 +3,7 @@
 This style guide is created from Material.io design guidelines.
 If you want to learn from animations and illustrations, [follow this link to official material.io type-system docs](https://material.io/design/typography/the-type-system.html#type-scale).
 
-![type-system](./assets/material-type-face.png)
+![type-system](.docs/assets/material-type-face.png)
 
 There is a total of 13 font variants which are shown below in decreasing order of emphasis:
 

README.md

@@ -10,7 +10,7 @@ WalkingPal is the world's first walking buddy app of its kind. Get yourself a wa
 
 > **IMPORTANT**: Go to `#🚦start-here` channel after you join the Discord server. Read and follow the instructions given there to get started.
 
-> Make sure you read and follow the [code of conduct](./.docs/CODE-OF-CONDUCT.md)
+> Make sure you read and follow the [code of conduct](/.docs/CODE-OF-CONDUCT.md)
 
 ---
 
@@ -36,7 +36,7 @@ This is the official repo for the [WalkingPal website](https://walkingpal.in/).
 **Wish to fix a bug or add a new feature?**
 Checkout our [contributing guidelines](.docs/CONTRIBUTING.md)!
 
-<p align="center"><img src = "https://media.giphy.com/media/1xOe0qgiYLYWE6pkki/giphy.gif"></p>
+<p align="center"><img src="https://media.giphy.com/media/1xOe0qgiYLYWE6pkki/giphy.gif"></p>
 
 ---