Skip to content

Latest commit

 

History

History
82 lines (55 loc) · 4.1 KB

CONTRIBUTING.md

File metadata and controls

82 lines (55 loc) · 4.1 KB

🎒 Contributing to Student Toolbox

We want to make contributing to this project as easy and transparent as possible.

📚 Contents of this Guideline

💻 We Use GitHub Flow, So All Code Changes Happen Through Pull Requests When Contributing

Pull requests are the best way to propose changes to the codebase. We actively welcome your pull requests:

  1. 🍴 Fork the repo and create your branch from main.
  2. 📝 When creating a pull request, please use our pull request template.
  3. ✅ If you've added code that should be tested, add tests.
  4. 🚦 Ensure the test suite passes if any.
  5. 🔍 Make sure your code lints.
  6. 📤 Issue that pull request!
  7. 🛠️ Once the issue has been reviewed and approved, it should be squashed and merged.

🌲 Branching and committing

Please follow these guidelines when creating branches:

  • Tag your branch with a valid branch type followed by a forward slash. Describe it using snake case. e.g., feature/add_login_page or documentation/fix_comments.

Please follow these guidelines when creating commits:

  • Tag your branch with a valid commit type followed by a colon. Describe it using snake case and a captital at the start. e.g., feat: Add_login_page or docs: Fix_comments.

✨ Propose New Features Using GitHub's Issues

We use GitHub issues to track proposed features. Propose a feature by opening a new issue and choosing the Feature Request template—it's that easy!

🐛 Report Bugs Using GitHub's Issues

We use GitHub issues to track public bugs. Report a bug by opening a new issue and choosing the Bugs template—it's that easy!

🪭 Our Custom Labels

  • backend 🔙

    • Purpose: Indicates that the issue or pull request involves backend development, such as server-side logic, database interactions, or APIs.
    • Example:
      • Issue: "Create RESTful API for user authentication."

  • design 🎨

    • Purpose: Marks issues or pull requests focused on the design elements that are not directly functional, such as wireframes, UI mockups, or architectural diagrams.
    • Example:
      • Issue: "Update wireframes to reflect new navigation flow."

  • feature 🐥

    • Purpose: Used for issues or pull requests that involve the development or modification of features or components in the application.
      • Example:
        • Issues "Add search functionality to the dashboard."

  • front end 🙇‍♀️

    • Purpose: Specifies that the issue or pull request deals with frontend development, such as UI implementation, styling, or client-side logic.
    • Example:
      • Issue: "Fix button alignment on the settings page."

  • refactor 🔀

    • Purpose: Applied to issues or pull requests that involve code refactoring, restructuring, or optimization.
    • Example:
      • Issue: "Refactor the user authentication logic to use a single function."

  • wontfix 🙈

    • Purpose: Applied to issues or pull requests that, after review, are determined not to be addressed or implemented.
    • Example:
      • Issue: "Add support for outdated browser versions."

📜 License

By contributing, you agree that your contributions will be licensed under its MIT License.

📄 Any Contributions You Make Will Be Under the MIT Software License

In short, when you submit code changes, your submissions are understood to be under the same MIT License that covers the project. Feel free to contact the maintainers if that's a concern.