projectshub Contributing Guidelines

Thank you for taking the time to contribute to our project. Please take a moment to read the following guidelines before contributing:

⚠️IMPORTANT Note

Pull Requests having no issue associated with them will not be accepted. Firstly get an issue assigned, whether it's already opened or raised by you, and then create a Pull Request.

Prerequisites ⚠️

Basic familiarity with Git and GitHub: If you are also new to these tools, visit Getting to Know Git and GitHub: Your Code's Best Friends for a practical guide to them.
Open Source Etiquette: If you've never contributed to an open source project before, have a read of Basic etiquette for open source projects.

How to Contribute 🤔

To get started, look at the existing Issues or create a new issue!

Setup guidelines 🪜

Follow these steps to setup projectshub on your local machine

Fork the project
Clone the project to your local machine using the following command:
```
git clone https://github.com/<your_github_username>/projectshub.git
```
Get into the root directory
```
cd projectshub
```
Create your branch
```
git checkout -b <your_branch_name>
```
Make your changes before staging them.
Stage your changes
```
git add <filename>
```
Commit your changes
```
git commit -m "<your-commit-message>"
```
Push your changes to your branch
```
git push origin "<your_branch_name>"
```
Create a PULL REQUEST 💣

Click compare across forks if you don't see your branch

Issues ✍️

When creating an issue, make sure you fill up all the fields properly.
Make sure that you are NOT raising a duplicate issue.
If you want to work on the issue, please click on the I am willing to work on this issue checkmark.
Work on only ONE issue at a time.

Closing the issue 📍

If you decide to close the issue, please leave a brief comment describing why(e.g., I'm busy with other obligations.) before you do.
Note: If the Pull Request associated with the issue gets merged and the issue still remains open, it's your responsibility to close the issue.

Commits Message Guidelines 💬

We follow a standardized commit message format using Commitlint to ensure consistency and clarity in our commit history. Each commit message should adhere to the following guidelines:

Type: The commit type must be one of the following:
- feat: A new feature or enhancement.
- fix: A bug fix.
- docs: Documentation changes.
- style: Code style changes (e.g., formatting, semicolons).
- refactor: Code refactorings with no feature changes or bug fixes.
- test: Adding or improving tests.
- chore: General maintenance tasks, build changes, etc.
Scope (Optional): The scope provides context for the commit, indicating the specific part of the project being affected. Use a short description in lowercase (e.g., auth, navbar, README).
Description: A brief and meaningful description of the changes made. Start with a capital letter and use the imperative mood (e.g., "Add new feature" instead of "Added new feature").
Issue reference (Optional): Include the issue number associated with the commit (e.g., #123).

✔️ Examples of Valid Commit Messages

feat: Add user authentication feature
`fix(auth): Resolve login page redirect issue
`docs: Update installation instructions
`style: Format code according to project guidelines
refactor(navbar): Improve responsiveness
test: Add unit tests for API endpoints
`chore: Update dependencies to the latest versions
fix: Handle edge case in data processing (#456)

❌ Examples of Invalid Commit Messages

Added new stuff
Fixed a bug
Updated code
auth feature update
chore: fixed some stuff

Commit Example with Commitlint

git commit -m "feat(auth): Implement user signup process (#123)"

Making Pull Requests 💥

When you submit a pull request, several tests are automatically run as GitHub Actions. If any of these tests fail, it is your responsibility to try and resolve the underlying issue(s). If you don't know how to resolve the underlying issue(s), you can ask for help.
Each pull request should contain a single logical change or related set of changes that make sense to submit together. If a pull request becomes too large or contains too many unrelated changes, it becomes too difficult to review. In such cases, the reviewer has the right to close your pull request and ask that you submit a separate pull request for each logical set of changes that belong together.
Link the issue you have resolved in the Pull Request Template (e.g. Closes/Fixes #99).
Use our Commit messages Guidelines (You can find it in the CONTRIBUTING.md file) for your changes.
Do not re-open a pull request that a reviewer has closed.
- Make sure to tick the "Allow edits from maintainers" box. This allows us to directly make minor edits / refactors and saves a lot of time.
  
  Note If your pull request has merge conflicts with the main branch (GitHub checks for this automatically and notifies you), you are responsible for resolving them. You can do this by merging the main branch into your branch (git pull upstream main), and then pushing the updated branch to your fork (git push). If you need more tips, check out Resolving a merge conflict on GitHub.

Remarks ✅

If something is missing here, or you feel something is not well described, either create a PR, raise an issue, or do a code review of the person’s PR (ensure that your review conforms to the Code of Conduct)
You can tag maintainers for any kind of difficulty using @username.

Levels

We came up with this chart so you can gauge the issue's difficulty and pick ones that fit within your skillset:

Points	Contribution
`priority: low`:	Addition of new links/categories or doing any small task (e.g fixing typos)
`priority: medium`:	Modifying an existing feature
`priority: high`:	Making completely new feature