SEO and brushups

Author: NishantGupt786

.env.example

@@ -9,6 +9,19 @@
 # When adding additional environment variables, the schema in "/src/env.js"
 # should be updated accordingly.
 
-# Example:
-# SERVERVAR="foo"
-# NEXT_PUBLIC_CLIENTVAR="bar"
+CLOUDINARY_API_KEY=""
+CLOUDINARY_SECRET=""
+CRYPTO_SECRET=""
+EMAIL_HOST=""
+EMAIL_PASSWORD=""
+EMAIL_PORT=""
+EMAIL_SECURE=""
+EMAIL_USER=""
+JWT_SECRET=""
+MONGODB_URI=""
+NEXT_PUBLIC_CLOUDINARY_CLOUD_NAME=""
+NEXT_PUBLIC_CRYPTO_SECRET=""
+KV_URL=""
+KV_REST_API_URL=""
+KV_REST_API_TOKEN=""
+KV_REST_API_READ_ONLY_TOKEN=""

CONTRIBUTING.md

@@ -0,0 +1,72 @@
+## Contribution Guidelines
+
+Please note that this project is released with a [Contributor Code of Conduct](CODE_OF_CONDUCT.md). By participating in this project you agree to abide by its terms.
+
+## How to contribute
+
+- Decide which repository to contribute
+- Decide what to contribute
+- Fork the repo then clone it locally
+- Commit your work (You should create a new branch when you're doing development work that is somewhat experimental in nature.)
+- Create a **Pull Request**
+- Congrats 🎉 you have just contributed towards open source!
+
+## What to contribute
+
+- Find an open issue to tackle
+- Ask if you can help write a new feature
+- Add / Improve Unit Testing
+- Write tutorials for how a project can be used and add to the readme
+- Review code on other people’s submissions and help improving / finding vulnerabilities
+
+## Making a PR
+- Provide all the appropriate details asked in PR template
+- A pull request doesn’t have to represent finished work. It’s usually better to open a pull request early on, so others can watch or give feedback on your progress. Just mark it as a “WIP” (Work in Progress) in the subject line. You can always add more commits later.
+
+## Opening an Issue
+- Make use of an appropriate Issue Template
+- We welcome Feature request, Bug Report, Documentation fix and others
+- Do not open critical security issues here, report them directly at [our email](mailto:[email protected]).
+
+## Communicating effectively
+**Give context.** Help others get quickly up to speed. If you’re running into an error, explain what you’re trying to do and how to reproduce it. If you’re suggesting a new idea, explain why you think it’d be useful to the project (not just to you!).
+
+```
+✔️ “X doesn’t happen when I do Y”
+❌ “X is broken! Please fix it.”
+```
+
+**Do your homework beforehand.** It’s OK not to know things, but show that you tried. Before asking for help, be sure to check a project’s README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate when you demonstrate that you’re trying to learn.
+
+```
+✔️ ““I’m not sure how to implement X. I checked the help docs and didn’t find any mentions.””
+❌ “How do I X?”
+```
+
+**Keep requests short and direct.**
+
+```
+✔️ “I’d like to write an API tutorial.”
+❌ “I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you…“
+```
+
+**It’s okay to ask questions (but be patient!).**
+
+```
+✔️ “Thanks for looking into this error. I followed your suggestions. Here’s the output.”
+❌ “Why can’t you fix my problem? Isn’t this your project?”
+```
+
+**Respect community decisions.**
+
+```
+✔️ “I’m disappointed you can’t support my use case, but as you’ve explained it only affects a minor portion of users, I understand why. Thanks for listening.”
+❌ “Why won’t you support my use case? This is unacceptable!”
+```
+
+## Misc
+- You are welcome to Propose a new feature by creating an **Issue**.
+- You may Discuss a high-level topic or idea (for example, community, vision or policies) by writing to us at our [Email](mailto:[email protected]).
+
+## Attribution
+- [Open Source Guide](https://opensource.guide/how-to-contribute/)