Skip to content

Latest commit

 

History

History
131 lines (88 loc) · 6.51 KB

Create Contributing.md

File metadata and controls

131 lines (88 loc) · 6.51 KB
Raw

Contributing Guidelines

This documentation contains a set of guidelines to help you during the contribution process. We are happy to welcome all the contributions from anyone willing to improve/add new scripts to this project. Thank you for helping out and remember, no contribution is too small.
Please note we have a code of conduct please follow it in all your interactions with the project.


Important point to keep in mind before starting ✅

  • If anything is missing or if you find something that needs to be enhanced/fixed/modified in the project, please feel free to create an issue.
  • Ask to get the issue assigned to you before working on the issue & making a PR.
  • Don't create a PR until the issue is not assigned to you.
  • Mention the issue number in the PRs and describe all the changes that you have made briefly in the PR(if possible attach a screen recording showing the changes you made).

Creating a new issue process

  1. Go to the project's issues.
  2. click on "new issue".
  3. Give proper title and required description for the issue.
  4. Don't spam to get the assignment of the issue.
  5. Wait for till someone is looking into it.
  6. Start working on issue only after you got assigned that issue.

Need some help regarding the basics?

You can refer to the following articles on basics of Git and Github and also contact the Project Mentors, in case you are stuck:


Steps need to be followed to contribute:

  1. Open GitHub Desktop: Launch GitHub Desktop and log in to your GitHub account if you haven't already.

  2. Clone the Repository:

    • If you haven't cloned the StudyNotion-An-Online-Education-Platform repository yet, you can do so by clicking on the "File" menu and selecting "Clone Repository."
    • Choose the StudyNotion-An-Online-Education-Platform repository from the list of repositories on GitHub and clone it to your local machine.

  3. Switch to the Correct Branch:

    • Ensure you are on the branch that you want to submit a pull request for.
    • If you need to switch branches, you can do so by clicking on the "Current Branch" dropdown menu and selecting the desired branch.

  4. Make Changes: Make your changes to the code or files in the repository using your preferred code editor(like vs code).

  5. Commit Changes:

    • In GitHub Desktop, you'll see a list of the files you've changed. Check the box next to each file you want to include in the commit.
    • Enter a summary and description for your changes in the "Summary" and "Description" fields, respectively. Click the "Commit to " button to commit your changes to the local branch.

  6. Push Changes to GitHub: After committing your changes, click the "Push origin" button in the top right corner of GitHub Desktop to push your changes to your forked repository on GitHub.

  7. Create a Pull Request:

    • Go to the GitHub website and navigate to your fork of the StudyNotion-An-Online-Education-Platform repository.
    • You should see a button to "Compare & pull request" between your fork and the original repository. Click on it.

  8. Review and Submit:

    • On the pull request page, review your changes and add any additional information, such as a title and description, that you want to include with your pull request.
    • Once you're satisfied, click the "Create pull request" button to submit your pull request.

  9. Wait for Review: Your pull request will now be available for review by the project maintainers. They may provide feedback or ask for changes before merging your pull request into the main branch of the StudyNotion-An-Online-Education-Platform repository.

Pull Request Process

  1. Ensure that you have self reviewed your code.
  2. Make sure you have added the proper description for the functionality of the code
  3. Submit your PR by giving the necesarry information in PR template and wait for PA to review it.

Commit Message Guidelines using Commitlint

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:

  1. 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.

  2. 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).

  3. 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").

  4. Issue reference (Optional): Include the issue number associated with the commit (e.g., #123).

Examples:

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 latest versions
  • fix: Handle edge case in data processing (#456)

Invalid Commit Messages:

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

By following these guidelines, we can maintain a clean commit history that is easy to understand and helps us effectively track changes. If you have any questions or need further assistance, feel free to ask! Happy contributing!

Thank you for your interest in contributing to StudyNotion-an-online-education-platform