Add contributing

[durdana3105]

This pull request introduces a dedicated CONTRIBUTING.md file to help new contributors understand how to properly contribute to the LocalMind project. It outlines clear steps for forking, branching, committing, coding standards, and opening pull requests.

What’s Included:
Added CONTRIBUTING.md with:
Steps to clone and set up the project
Branching and commit guidelines
PR submission instructions
Coding standards and documentation practices
Instructions for keeping forks updated

Why This Change Is Needed:
Improves developer onboarding experience
Ensures consistency in contributions
Reduces errors and increases clarity for future contributors
Helps maintain code quality and repository organization

How It Was Done:
Created a new branch: add-contributing-file
Added a fully detailed CONTRIBUTING.md
Ensured proper markdown formatting
Committed and pushed the branch
Opening this PR for review and merge

Checklist:
CONTRIBUTING.md added
Instructions clearly written
Markdown formatting validated
Ready for review

[gemini-code-assist]

Summary of Changes

Hello @durdana3105, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the project's accessibility for new contributors by introducing a detailed "CONTRIBUTING.md" file. This document provides clear, step-by-step instructions for engaging with the LocalMind project, from initial setup to pull request submission, aiming to streamline the onboarding process, ensure consistency in contributions, and uphold code quality. Additionally, an "MIT License" has been added to formally establish the project's open-source terms.

Highlights

• New Contribution Guidelines: Introduced a comprehensive "CONTRIBUTING.md" file to guide new contributors through the process of forking, branching, committing, adhering to coding standards, and submitting pull requests for the LocalMind project.
• Project Licensing: Added an "MIT License" file to clearly define the terms under which the LocalMind project can be used, modified, and distributed.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request is a great initiative to improve the contributor experience by adding a CONTRIBUTING.md and LICENSE file. The contributing guide is well-structured and covers the essential workflow. My review includes several suggestions to enhance the document's clarity and correctness. Specifically, I've recommended using markdown code blocks for shell commands for better readability and adding a crucial missing step for synchronizing a forked repository. I also pointed out a minor formatting improvement for the LICENSE file.

[gemini-code-assist]

These instructions are missing a critical step: configuring the upstream remote. A new contributor's fork won't have an upstream remote by default, causing git fetch upstream to fail. The instructions should be updated to include adding the remote and should also place the commands in proper code blocks for clarity.

Suggested change

	Before starting new work, sync your fork:
	git fetch upstream
	git checkout main
	git merge upstream/main
	git push origin main
	Before starting new work, it's important to sync your fork with the original repository to avoid merge conflicts.
	**1. Configure the Upstream Remote (only needs to be done once):**
	Add the original repository as a remote named `upstream`.
	```bash
	git remote add upstream https://github.com/NexGenStudioDev/LocalMind.git

2. Sync Your Main Branch:
Before creating a new feature branch, fetch the latest changes from upstream and update your local main branch.

git fetch upstream
git checkout main
git merge upstream/main
git push origin main

[gemini-code-assist]

It's a good practice for files to end with a single newline character. This prevents issues with some command-line tools and can make git diff outputs cleaner.

SOFTWARE.

[gemini-code-assist]

This title is redundant since the file is already named CONTRIBUTING.md. The main heading on line 3, Contributing to LocalMind, is more descriptive and sufficient. Removing this and the following blank line will make the document cleaner.

[gemini-code-assist]

For better readability and to allow users to easily copy the commands, it's best to wrap shell commands in a fenced code block with language highlighting.

Suggested change

	git clone https://github.com/<your-username>/LocalMind.git
	cd LocalMind
	git clone https://github.com/<your-username>/LocalMind.git
	cd LocalMind

[gemini-code-assist]

This command should be in a fenced code block for consistency and readability.

Suggested change

	git checkout -b feature-name
	git checkout -b feature-name

[gemini-code-assist]

These commands should be wrapped in a fenced code block for consistency and easy copying.

Suggested change

	git add .
	git commit -m "Short description of the change"
	git add .
	git commit -m "Short description of the change"

[abhishek-nexgen-dev]

Write like This

git add .
git commit -m "Short description of the change"

[gemini-code-assist]

This command should be in a fenced code block for consistency and readability.

Suggested change

	git push origin feature-name
	git push origin feature-name

[abhishek-nexgen-dev]

Write like This

git add .
git commit -m "Short description of the change"