From dc53e1b8b92afd54ba6466c7bd0fb4ece3def7e2 Mon Sep 17 00:00:00 2001 From: Maxime Guillemin | Cloudflow Date: Tue, 15 Oct 2024 16:29:51 +0200 Subject: [PATCH] Create CONTRIBUTING.md --- CONTRIBUTING.md | 62 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..6b30463 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,62 @@ +# Contributing to Intune-Toolkit + +Thank you for considering contributing to the **Intune-Toolkit** project! We welcome contributions of all kinds, whether you're fixing a bug, improving documentation, or adding a new feature. Please take a moment to review the guidelines below to ensure that your contributions align with our standards. + +## 1. How to Contribute + +### 1.1 Reporting Bugs or Requesting Features +- **Search first:** Before creating a new issue, please search the [existing issues](https://github.com/MG-Cloudflow/Intune-Toolkit/issues) to ensure that the issue or feature request hasn’t been reported already. +- **Open an issue:** If you find a bug or have a feature request, open a new issue using the appropriate template: + - **Bug Report:** Provide clear details about the problem, including steps to reproduce, environment information, and any logs/screenshots. + - **Feature Request:** Describe the feature in detail, including why it would be useful and how you envision it working. +- **Provide context:** Be specific in your descriptions and provide as much context as possible to help us understand your needs and address the issue efficiently. + +### 1.2 Contributing Code +- **Fork the repository:** Before making any changes, fork the repository and work on a new branch. +- **Follow the coding style:** Ensure your code follows the existing coding style of the project. Follow any formatting or linting rules outlined in the project. +- **Document your changes:** If you're adding a new feature or updating an existing one, make sure to update the documentation accordingly. Provide comments and write meaningful commit messages. +- **Test your changes:** Ensure that your code changes are thoroughly tested and don't introduce new bugs. If you're adding a new feature, consider writing tests to cover it. + +### 1.3 Submitting a Pull Request +- **Create a pull request (PR):** Once you're ready to submit your changes, create a pull request to the main branch. +- **Reference related issues:** If your pull request addresses an issue, mention it in the pull request description (e.g., "Fixes #42"). +- **Explain your changes:** Clearly describe the purpose of your changes and why they are necessary. If the pull request is large or complex, break it down into smaller, self-contained commits. +- **Be responsive:** If your PR receives feedback from the maintainers, respond promptly and make the requested changes. Discussions and reviews help improve the code quality. +- **Small, focused PRs:** When possible, submit small, incremental changes rather than large, sweeping ones. Smaller pull requests are easier to review and increase the chances of acceptance. + +## 2. Code Style Guidelines + +To maintain consistency across the project, all contributors should adhere to the following coding conventions: + +- **Naming Conventions:** Use descriptive and meaningful names for variables, functions, and classes. Stick to common conventions such as camelCase for variables and functions, and PascalCase for class names. +- **Formatting:** Ensure your code is properly formatted with appropriate indentation. Use linters and formatters (if any are specified) to maintain consistency. +- **Comments:** Write clear and concise comments to explain complex logic or important decisions within the code. However, avoid over-commenting trivial parts of the code. + +## 3. Commit Message Guidelines + +To keep the Git history clean and readable, please follow these commit message guidelines: +- **Write in the imperative mood:** E.g., “Add feature,” not “Added feature” or “Adding feature.” +- **Keep it short:** Limit the first line of the commit message to 50 characters. If additional context is needed, add a longer description in the subsequent lines. +- **Reference issues:** If your commit relates to an issue, include a reference to it (e.g., `Fixes #42`). + +Example commit message structure: +``` +Add new feature to improve authentication flow + +This update implements a new authentication method that reduces latency and increases security. It also fixes a bug in the previous implementation that caused incorrect login redirects. +``` + +## 4. Best Practices + +- **Keep discussions respectful:** Constructive feedback is encouraged, but personal attacks or dismissive comments are not acceptable. +- **Collaborate early:** If you're working on a significant change, open an issue or reach out via the discussion board to get feedback early in the process. +- **Stay up-to-date:** Regularly pull in changes from the main branch to avoid merge conflicts and keep your branch up-to-date with the latest changes in the repository. +- **Work in progress (WIP):** If you want to get feedback on a pull request before it's finished, feel free to submit a "Work in Progress" PR. You can mark it as such using `[WIP]` in the PR title. + +## 5. License + +By contributing to this repository, you agree that your contributions will be licensed under the same license as the project (MIT License). + +## 6. Getting Help + +If you're unsure about anything in the contribution process, feel free to ask for help by opening an issue or reaching out via the project's discussions. We value contributions from all skill levels, and we're here to assist you.