From 036ae220b1db826a6941d135ed4db783cf2e51c5 Mon Sep 17 00:00:00 2001 From: Mirjam Aulbach Date: Wed, 26 Oct 2022 07:07:59 +0200 Subject: [PATCH 1/8] docs: Structure commit message rules better. --- CONTRIBUTING.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ccf41f3a05..5af203d05c 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -48,7 +48,7 @@ For more information read this article: [How to Write a Git Commit Message](http ``` -**1. Add a short description as first line** +##### 1. Add a short description as first line The first line (``) should be a short description of your change. Limit it to preferably 50 characters. It never should be longer than 72 characters. **⛔️ Don't** @@ -59,7 +59,7 @@ The first line (``) should be a short description of your change. L `Add first iteration for contribution guide` -**2. Use the "imperative mood" in first line** +##### 2. Use the "imperative mood" in first line "Imperative mood" means you form a sentence as if you were giving a command. You can image your commit message completing the sentence _"If applied, this commit will... "_. **⛔️ Don't** @@ -70,10 +70,12 @@ The first line (``) should be a short description of your change. L `fix: Remove the newline that caused a linting error` -> _"If applied, this commit will_ remove the newline that caused a linting error" -**3. Separate your description with a new line from the body.** + +##### 3. Separate your description with a new line from the body If you add an body, add an empty line between your description to separate it from the body. This makes the message more readable. It also makes `git log --oneline` or `git shortlog` more useable. -**4. Use an optional body to explain why, not how.** + +##### 4. Use an optional body to explain why, not how. You don't need to explain the code! The commit message has a changeset that contains this information. Use the body to explain _why_ you made a change. Not every commit needs to have a body. Often the code change itself is explanation enough. **⛔️ Don't** @@ -90,5 +92,5 @@ Change "optoinal" "to optional" Remove "just" from description, because it can make people feel inadequate. ``` -**5. Wrap your body at 72 characters** +##### 5. Wrap your body at 72 characters Git does not wrap text, so you have to take care of margins. Editors and IDEs can help with that. From aa8a9317eac743794372eb13ba6353482079bd6a Mon Sep 17 00:00:00 2001 From: Mirjam Aulbach Date: Wed, 26 Oct 2022 07:13:55 +0200 Subject: [PATCH 2/8] docs: Correct grammar and spelling. --- CONTRIBUTING.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 5af203d05c..251b3279c2 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -4,7 +4,7 @@ Whether it's a bug report, new feature, correction, or additional documentation, we greatly value feedback and contributions from our community. -Please read through this document before submitting any issues or pull requests. This ensures all parties have all necessary information to respond to your bug report or contribution. +Please read through this document before submitting any issues or pull requests. This ensures all parties have all the necessary information to respond to your bug report or contribution. ## ❤️ Code of Conduct @@ -15,7 +15,7 @@ For more information see the [Code of Conduct FAQ](https://www.contributor-coven ## Guideline commit messages -We uses the [Conventional Commits](https://www.conventionalcommits.org/) specification. It helps us creating a helpful and explicit git history. +We use the [Conventional Commits](https://www.conventionalcommits.org/) specification. It helps us to create a helpful and explicit git history. ### ℹ️ Semantic prefixes for commit messages @@ -34,7 +34,7 @@ Example: `refactor: Update footer from kafkawize.io to klaw-project.io` ### ✍️ Writing a great commit message -A "great" commit message enables others to gain more context about a code change. While the `diff` is telling you **what** has changes, the commit message can tell you **why** it has changed. +A "great" commit message enables others to gain more context about a code change. While the `diff` is telling you **what** has changed, the commit message can tell you **why** it has changed. For more information read this article: [How to Write a Git Commit Message](https://cbea.ms/git-commit/). We used it as a base for our rules. @@ -48,7 +48,7 @@ For more information read this article: [How to Write a Git Commit Message](http ``` -##### 1. Add a short description as first line +##### 1. Add a short description as the first line The first line (``) should be a short description of your change. Limit it to preferably 50 characters. It never should be longer than 72 characters. **⛔️ Don't** @@ -57,9 +57,9 @@ The first line (``) should be a short description of your change. L **️✅ Do** -`Add first iteration for contribution guide` +`Add the first iteration for contribution guide` -##### 2. Use the "imperative mood" in first line +##### 2. Use the "imperative mood" in the first line "Imperative mood" means you form a sentence as if you were giving a command. You can image your commit message completing the sentence _"If applied, this commit will... "_. **⛔️ Don't** @@ -72,10 +72,10 @@ The first line (``) should be a short description of your change. L ##### 3. Separate your description with a new line from the body -If you add an body, add an empty line between your description to separate it from the body. This makes the message more readable. It also makes `git log --oneline` or `git shortlog` more useable. +If you add a body, add an empty line between your description to separate it from the body. This makes the message more readable. It also makes `git log --oneline` or `git shortlog` more usable. -##### 4. Use an optional body to explain why, not how. +##### 4. Use an optional body to explain why not how. You don't need to explain the code! The commit message has a changeset that contains this information. Use the body to explain _why_ you made a change. Not every commit needs to have a body. Often the code change itself is explanation enough. **⛔️ Don't** @@ -89,7 +89,7 @@ Change "optoinal" "to optional" **️✅ Do** ```fix: Remove word -Remove "just" from description, because it can make people feel inadequate. +Remove "just" from the description, because it can make people feel inadequate. ``` ##### 5. Wrap your body at 72 characters From 574ac69b242eb14ed240d4ce689c3bffb63d3a2d Mon Sep 17 00:00:00 2001 From: Mirjam Aulbach Date: Wed, 26 Oct 2022 07:26:49 +0200 Subject: [PATCH 3/8] docs: Add table of content. --- CONTRIBUTING.md | 41 ++++++++++++++++++++++++----------------- 1 file changed, 24 insertions(+), 17 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 251b3279c2..d545b5d38e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -6,8 +6,18 @@ Whether it's a bug report, new feature, correction, or additional documentation, Please read through this document before submitting any issues or pull requests. This ensures all parties have all the necessary information to respond to your bug report or contribution. - -## ❤️ Code of Conduct +## Content +* [❤️ Code of Conduct ](#-code-of-conduct) +* [Guideline commit messages](#guideline-commit-messages) + + [ℹ️ Semantic prefixes for commit messages](#-semantic-prefixes-for-commit-messages) + + [✍️ Writing a great commit message](#-writing-a-great-commit-message) + - [1. Add a short description as the first line](#1-add-a-short-description-as-the-first-line) + - [2. Use the "imperative mood" in the first line](#2-use-the-imperative-mood-in-the-first-line) + - [3. Separate your description with a new line from the body](#3-separate-your-description-with-a-new-line-from-the-body) + - [4. Use an optional body to explain why not how.](#4-use-an-optional-body-to-explain-why-not-how) + + +## ❤️ Code of Conduct This project has adopted the [Contributor Covenant Code of Conduct](CODE_OF_CONDUCT.md). Before contributing, please take the time to read our COC. Everyone participating is expected to uphold this code. Please report unacceptable behavior to us! @@ -15,32 +25,29 @@ For more information see the [Code of Conduct FAQ](https://www.contributor-coven ## Guideline commit messages -We use the [Conventional Commits](https://www.conventionalcommits.org/) specification. It helps us to create a helpful and explicit git history. +We use the [Conventional Commits](https://www.conventionalcommits.org/) specification. It helps us to create a helpful and explicit git history. ### ℹ️ Semantic prefixes for commit messages - **fix**: a commit that patches a bug. -Example: `fix: Removes circular dependency` + Example: `fix: Removes circular dependency` - **feat**: a commit that introduces a new feature. -Example: `feat: Add sorting to user list` + Example: `feat: Add sorting to user list` - **docs**: a commit that changes something related to documentation. -Example: `docs: Update contribution guide with guidelines for commit messages` + Example: `docs: Update contribution guide with guidelines for commit messages` - **refactor**: a commit that refactors existing code. -Example: `refactor: Update footer from kafkawize.io to klaw-project.io` + Example: `refactor: Update footer from kafkawize.io to klaw-project.io` ### ✍️ Writing a great commit message -A "great" commit message enables others to gain more context about a code change. While the `diff` is telling you **what** has changed, the commit message can tell you **why** it has changed. +A "great" commit message enables others to gain more context about a code change. While the `diff` is telling you **what** has changed, the commit message can tell you **why** it has changed. For more information read this article: [How to Write a Git Commit Message](https://cbea.ms/git-commit/). We used it as a base for our rules. - -#### Rules - ``` : @@ -48,7 +55,7 @@ For more information read this article: [How to Write a Git Commit Message](http ``` -##### 1. Add a short description as the first line +#### 1. Add a short description as the first line The first line (``) should be a short description of your change. Limit it to preferably 50 characters. It never should be longer than 72 characters. **⛔️ Don't** @@ -59,7 +66,7 @@ The first line (``) should be a short description of your change. L `Add the first iteration for contribution guide` -##### 2. Use the "imperative mood" in the first line +#### 2. Use the "imperative mood" in the first line "Imperative mood" means you form a sentence as if you were giving a command. You can image your commit message completing the sentence _"If applied, this commit will... "_. **⛔️ Don't** @@ -71,12 +78,12 @@ The first line (``) should be a short description of your change. L -> _"If applied, this commit will_ remove the newline that caused a linting error" -##### 3. Separate your description with a new line from the body +#### 3. Separate your description with a new line from the body If you add a body, add an empty line between your description to separate it from the body. This makes the message more readable. It also makes `git log --oneline` or `git shortlog` more usable. -##### 4. Use an optional body to explain why not how. -You don't need to explain the code! The commit message has a changeset that contains this information. Use the body to explain _why_ you made a change. Not every commit needs to have a body. Often the code change itself is explanation enough. +#### 4. Use an optional body to explain why not how. +You don't need to explain the code! The commit message has a changeset that contains this information. Use the body to explain _why_ you made a change. Not every commit needs to have a body. Often the code change itself is explanation enough. **⛔️ Don't** ``` @@ -92,5 +99,5 @@ Change "optoinal" "to optional" Remove "just" from the description, because it can make people feel inadequate. ``` -##### 5. Wrap your body at 72 characters +#### 5. Wrap your body at 72 characters Git does not wrap text, so you have to take care of margins. Editors and IDEs can help with that. From fd2309de20b90fd5ff4a213b54104aea393d90b0 Mon Sep 17 00:00:00 2001 From: Mirjam Aulbach Date: Wed, 26 Oct 2022 15:22:14 +0200 Subject: [PATCH 4/8] docs: Add draft for missing sections. --- CONTRIBUTING.md | 93 ++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 81 insertions(+), 12 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index d545b5d38e..fc64df74ac 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -2,27 +2,96 @@ 🎉 First off: Thank you for your interest in contributing to our project 🥳 -Whether it's a bug report, new feature, correction, or additional documentation, we greatly value feedback and contributions from our community. +Whether it's a bug report, new feature, correction, or additional documentation, we greatly value feedback and contributions from our community. GitHubs Open Source guides have a great source about ways to [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/). Please read through this document before submitting any issues or pull requests. This ensures all parties have all the necessary information to respond to your bug report or contribution. -## Content -* [❤️ Code of Conduct ](#-code-of-conduct) -* [Guideline commit messages](#guideline-commit-messages) - + [ℹ️ Semantic prefixes for commit messages](#-semantic-prefixes-for-commit-messages) - + [✍️ Writing a great commit message](#-writing-a-great-commit-message) - - [1. Add a short description as the first line](#1-add-a-short-description-as-the-first-line) - - [2. Use the "imperative mood" in the first line](#2-use-the-imperative-mood-in-the-first-line) - - [3. Separate your description with a new line from the body](#3-separate-your-description-with-a-new-line-from-the-body) - - [4. Use an optional body to explain why not how.](#4-use-an-optional-body-to-explain-why-not-how) - - +## Content + +- [❤️ Code of Conduct](#code-of-conduct) +- [Opening an issue](#opening-an-issue) +- [How to work on an issue](#how-to-work-on-an-issue) +- [How to make a pull request](#how-to-make-a-pull-request) + - [When is your pull request ready to be merged?](#when-is-your-pull-request-ready-to-be-merged) +- [Guideline commit messages](#guideline-commit-messages) + - [ℹ️ Semantic prefixes for commit messages](#-semantic-prefixes-for-commit-messages) + - [✍️ Writing a great commit message](#-writing-a-great-commit-message) + ## ❤️ Code of Conduct This project has adopted the [Contributor Covenant Code of Conduct](CODE_OF_CONDUCT.md). Before contributing, please take the time to read our COC. Everyone participating is expected to uphold this code. Please report unacceptable behavior to us! For more information see the [Code of Conduct FAQ](https://www.contributor-covenant.org/faq/). + +## Opening an issue +You should open an issue when you +- checked that there is no issue open already related to your topic +- want to report an error that you can't resolve by yourself +- want to propose a new feature +- want to discuss an idea to improve a higher-level topic, for example about community, documentation + +__What information does an issue need?__ +The more information an issue includes, the better! For example: + +- If it's a bug, describe in detail how to reproduce it. You an add screenshots or screen recordings for visual bugs. +- If it's a feature, create a user story. What problem does that feature solve? What value does it add? + + +## How to work on an issue + +- Comment on the issue to inform that you will work on it. +- Set yourself as assignee and add the __in progress__ label. +- [Fork](https://docs.github.com/en/get-started/quickstart/fork-a-repo) the Klaw repository. +- On your fork, create a branch named after the issue you're working on. +- Make all of your changes 🧑‍💻 +- For your commits, please see our [Guideline commit messages](#guideline-commit-messages). +- Check if it would be helpful to update documentation related to your change. If yes, please do so! +- Make sure you added tests for your changes. +- If you fixed a bug, add a regression test. +- When you're finished and pushed all your changes to github, open a pull request. + + +## How to make a pull request + +GitHub has a detailed documentation [how to create a PR](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request) if you want to have more information. If you're not sure what to do, please feel free to reach out to our community! + +Be conscious about the scope for one PR. Sometimes it is tempting to get side tracked and for example refactor some unrelated code. But this should be a separate PR. Only add changes related to and contributing to the issue you're solving. + + +### When is your pull request ready to be merged? + +Every pull request has to be reviewed before merging. This code review is meant to assure quality for the product. It is also a great tool to give and receive feedback in the community and learn from each other. + +Your pull request should meet following criteria to be ready for review: + +__1. Every PR has to be releasable__ + +- Every PR that is merged on `main` should be treated like we release it into production right away. +- The `main` branch should always be in a state where it can be deployed and used right away. + +__2. Clear goal with a small scope__ + +- Make small and incremental PRs. +- The code changes relate to one specific topic. +- Every PR should have one specific goal (and if you add that goal in your description - all the better). +- Rather do multiple smaller PRs than one big one! PRs with a lot of changes are harder to review. It's also harder to give constructive feedback for them. + +__3. Add meaningful information__ + +- A descriptive title and detailed description of your changes helps reviewer gaining context +- Include links to relevant issues. +- If you followed a recommended approach e.g. from an article, link it in the PR. +- Especially for UI changes it can be helpful to add screenshots or recordings of your changes +- If you have questions, don't hesitate to add them! + +__4. Keep a clear git history in mind__ + +- If you do multiple commits, try to make every commit cover a scope of your changes. +- Your commit messages should follow our [guideline](#guideline-commit-messages). +- If you add changes after a review, don't force push in your existing PR, but add new commits. That way, reviewers can pick up the review again. + + ## Guideline commit messages We use the [Conventional Commits](https://www.conventionalcommits.org/) specification. It helps us to create a helpful and explicit git history. From fa903fae8b72595b283d25f55a66c792573bb43e Mon Sep 17 00:00:00 2001 From: Mirjam Aulbach Date: Wed, 26 Oct 2022 15:53:13 +0200 Subject: [PATCH 5/8] docs: Correct info and fix a typo. --- CONTRIBUTING.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index fc64df74ac..af08713181 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -34,14 +34,14 @@ You should open an issue when you __What information does an issue need?__ The more information an issue includes, the better! For example: -- If it's a bug, describe in detail how to reproduce it. You an add screenshots or screen recordings for visual bugs. +- If it's a bug, describe in detail how to reproduce it. You can add screenshots or screen recordings for visual bugs. - If it's a feature, create a user story. What problem does that feature solve? What value does it add? ## How to work on an issue - Comment on the issue to inform that you will work on it. -- Set yourself as assignee and add the __in progress__ label. +- If you have the rights: set yourself as assignee and add the __in progress__ label. - [Fork](https://docs.github.com/en/get-started/quickstart/fork-a-repo) the Klaw repository. - On your fork, create a branch named after the issue you're working on. - Make all of your changes 🧑‍💻 @@ -61,7 +61,7 @@ Be conscious about the scope for one PR. Sometimes it is tempting to get side tr ### When is your pull request ready to be merged? -Every pull request has to be reviewed before merging. This code review is meant to assure quality for the product. It is also a great tool to give and receive feedback in the community and learn from each other. +Every pull request has to be reviewed before merging. At least on maintainer need to approve it. This code review is meant to assure quality for the product. It is also a great tool to give and receive feedback in the community and learn from each other. Your pull request should meet following criteria to be ready for review: From 30d85ad8a910b6f4b3f84f626a411809ee2cc7f8 Mon Sep 17 00:00:00 2001 From: Mirjam Aulbach Date: Wed, 26 Oct 2022 16:54:59 +0200 Subject: [PATCH 6/8] docs: Improve grammar. --- CONTRIBUTING.md | 49 +++++++++++++++++++++++++------------------------ 1 file changed, 25 insertions(+), 24 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index af08713181..ace1c768fb 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -2,11 +2,11 @@ 🎉 First off: Thank you for your interest in contributing to our project 🥳 -Whether it's a bug report, new feature, correction, or additional documentation, we greatly value feedback and contributions from our community. GitHubs Open Source guides have a great source about ways to [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/). +Whether it's a bug report, new feature, correction, or additional documentation, we greatly value feedback and contributions from our community. GitHub Open Source guides have a great source about ways to [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/). Please read through this document before submitting any issues or pull requests. This ensures all parties have all the necessary information to respond to your bug report or contribution. -## Content +## Content - [❤️ Code of Conduct](#code-of-conduct) - [Opening an issue](#opening-an-issue) @@ -41,54 +41,55 @@ The more information an issue includes, the better! For example: ## How to work on an issue - Comment on the issue to inform that you will work on it. -- If you have the rights: set yourself as assignee and add the __in progress__ label. +- If you have the rights: set yourself as an assignee and add the __in progress__ label. - [Fork](https://docs.github.com/en/get-started/quickstart/fork-a-repo) the Klaw repository. -- On your fork, create a branch named after the issue you're working on. +- On your fork, [create a branch](https://docs.github.com/en/desktop/contributing-and-collaborating-using-github-desktop/making-changes-in-a-branch/managing-branches#creating-a-branch) named after the issue you're working on. - Make all of your changes 🧑‍💻 - For your commits, please see our [Guideline commit messages](#guideline-commit-messages). -- Check if it would be helpful to update documentation related to your change. If yes, please do so! -- Make sure you added tests for your changes. -- If you fixed a bug, add a regression test. -- When you're finished and pushed all your changes to github, open a pull request. +- Check if it would be helpful to update documentation related to your change. If yes, please do so 🤗! +- Make sure you add tests for your changes. +- If you fix a bug, add a regression test. + +- When you're finished and pushed all your changes to GitHub, you're ready to create a pull request 🎉 ## How to make a pull request -GitHub has a detailed documentation [how to create a PR](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request) if you want to have more information. If you're not sure what to do, please feel free to reach out to our community! +GitHub has detailed documentation on [how to create a PR](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork) if you want to have more information. If you're not sure what to do, please feel free to reach out to our community! -Be conscious about the scope for one PR. Sometimes it is tempting to get side tracked and for example refactor some unrelated code. But this should be a separate PR. Only add changes related to and contributing to the issue you're solving. +Be conscious of the scope of one PR. Sometimes it is tempting to get sidetracked for example by refactoring some unrelated code. We've all been there! But this should be a separate PR. Only add changes to your PR related and contribute to the issue you're solving. -### When is your pull request ready to be merged? +### ✅ When is your pull request ready to be merged? -Every pull request has to be reviewed before merging. At least on maintainer need to approve it. This code review is meant to assure quality for the product. It is also a great tool to give and receive feedback in the community and learn from each other. +Every pull request has to be reviewed before merging. At least one maintainer needs to approve it. This is meant to assure the quality of the product. It is also a great tool to give and receive feedback in the community and learn from each other. -Your pull request should meet following criteria to be ready for review: +Your pull request should meet the following criteria to be ready for review: __1. Every PR has to be releasable__ -- Every PR that is merged on `main` should be treated like we release it into production right away. +- Every PR that is merged on `main` should be treated like we release it into production right away. - The `main` branch should always be in a state where it can be deployed and used right away. -__2. Clear goal with a small scope__ +__2. A clear goal with a small scope__ -- Make small and incremental PRs. -- The code changes relate to one specific topic. -- Every PR should have one specific goal (and if you add that goal in your description - all the better). -- Rather do multiple smaller PRs than one big one! PRs with a lot of changes are harder to review. It's also harder to give constructive feedback for them. +- Make small and incremental PRs. +- The code changes relate to one specific topic. +- Every PR should have one specific goal (and if you add that goal in your description - all the better). +- Rather do multiple smaller PRs than one big one! PRs with a lot of changes are harder to review. It's also harder to give constructive feedback to them. __3. Add meaningful information__ -- A descriptive title and detailed description of your changes helps reviewer gaining context -- Include links to relevant issues. -- If you followed a recommended approach e.g. from an article, link it in the PR. +- A descriptive title and detailed description of your changes help the reviewer gaining context. +- Include links to relevant issues. +- If you followed a recommended approach e.g. from an article, link it in the PR. - Especially for UI changes it can be helpful to add screenshots or recordings of your changes - If you have questions, don't hesitate to add them! __4. Keep a clear git history in mind__ -- If you do multiple commits, try to make every commit cover a scope of your changes. -- Your commit messages should follow our [guideline](#guideline-commit-messages). +- If you do multiple commits, try to make every commit cover the scope of your changes. +- Your commit messages should follow our [guideline](#guideline-commit-messages). - If you add changes after a review, don't force push in your existing PR, but add new commits. That way, reviewers can pick up the review again. From c71e71e4dd97dabbce7af735619e4fdeb61572ad Mon Sep 17 00:00:00 2001 From: Mirjam Aulbach Date: Wed, 26 Oct 2022 17:09:19 +0200 Subject: [PATCH 7/8] docs: Update wording. --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ace1c768fb..5b073f1911 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -76,7 +76,7 @@ __2. A clear goal with a small scope__ - Make small and incremental PRs. - The code changes relate to one specific topic. - Every PR should have one specific goal (and if you add that goal in your description - all the better). -- Rather do multiple smaller PRs than one big one! PRs with a lot of changes are harder to review. It's also harder to give constructive feedback to them. +- Rather do multiple smaller PRs than one big one! PRs with a lot of changes are difficult to review. It's also more demanding to give constructive feedback to them. __3. Add meaningful information__ From 5e064e7db15a2d117e22e1f12095bfdd8894a1be Mon Sep 17 00:00:00 2001 From: Mirjam Aulbach Date: Thu, 27 Oct 2022 08:41:46 +0200 Subject: [PATCH 8/8] Update wording. Co-authored-by: Josep Prat --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 5b073f1911..78006e0479 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -95,7 +95,7 @@ __4. Keep a clear git history in mind__ ## Guideline commit messages -We use the [Conventional Commits](https://www.conventionalcommits.org/) specification. It helps us to create a helpful and explicit git history. +We use the [Conventional Commits](https://www.conventionalcommits.org/) specification. It helps to create a meaningful and explicit git history. ### ℹ️ Semantic prefixes for commit messages