I was making the commits as you mentioned in your post, but reviewing pr's I didn't see useful this approach, because is explicit what are you doing in your code, but no much why are you doing that code, so you can get additional information to get a better perspective.
Yeah I love this. Definitely reviewing PRs is where you should write the information. Ie. when you have a pull request, all the information about what you are adding and WHY should be in the PR rather than each commit. The PR is often a collection of commits so having a why is super important. This is something you should have in your contribution guide if it's an open source project, and something you should have as part of your guidelines for corporate closed projects.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I was making the commits as you mentioned in your post, but reviewing pr's I didn't see useful this approach, because is explicit what are you doing in your code, but no much why are you doing that code, so you can get additional information to get a better perspective.
Yeah I love this. Definitely reviewing PRs is where you should write the information. Ie. when you have a pull request, all the information about what you are adding and WHY should be in the PR rather than each commit. The PR is often a collection of commits so having a why is super important. This is something you should have in your contribution guide if it's an open source project, and something you should have as part of your guidelines for corporate closed projects.