Merge branch 'main' into migrate-to-pgx-v5

FerretDB · Apr 16, 2023 · e667ffe · e667ffe
2 parents a5db3c6 + 4d47717
commit e667ffe
Show file tree

Hide file tree

Showing 2 changed files with 22 additions and 19 deletions.
diff --git a/.github/PROCESS.md b/.github/PROCESS.md
@@ -59,40 +59,28 @@ Try to estimate on the planning as best as you can.
 
 ## Pull requests
 
+For FerretDB Inc. engineers and long-term contributors, besides the guides in [CONTRIBUTING.md](../CONTRIBUTING.md), please follow these notes below when you working with pull request:
+
 1. Send pull requests from forks; do not make personal branches in the main repository.
    This way, we are similar to community members and could notice similar problems that we could fix for everyone,
    not just for us.
 2. Pull request **title** should be accurate and descriptive as it is used in the generated changelog.
    It should not mention the issue number but describe the fixed issue instead.
-3. Most of the time pull requests are related to some issues.
-   In such cases, pull request **description** should mention the issue number
-   like `Closes #{issue_number}.` or `Closes org/repo#{issue_number}.`.
-   Do not use URLs like `https://github.com/org/repo/issue/123` or paths like `org/repo/issue/123`
-   even if they are rendered the same on GitHub.
-   If you propose a tiny fix, there is no needed to create a new issue.
-4. We provide a pull requests template that includes suggestions and readiness checklist.
+3. We provide a pull requests template that includes suggestions and readiness checklist.
    Please use it.
-5. It is fine to send several sequential pull requests for one issue to make them easier to review.
+4. It is fine to send several sequential pull requests for one issue to make them easier to review.
    In that case, please still use the `Closes` word as described above
    (because [words like "refs" do not link PR to the issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)),
    but don't forget to reopen the issue once PR is merged,
    but the issue as a whole is not done.
-6. Please create a draft pull request as soon as you start working on an issue; that is needed for our process tooling.
+5. Please create a draft pull request as soon as you start working on an issue; that is needed for our process tooling.
    Once it is ready for review, please mark it as such.
    After that, there is no need to switch between draft and non-draft states.
-7. In the pull request review conversations, please either leave a new comment or resolve (close) the conversation,
-   but do not do that simultaneously.
-   That ensures that the other person can read all comments.
-8. Please don't forget to click "re-request review" buttons once PR is ready for re-review.
-9. Commit messages (both titles and bodies) are not important and can be "WIP" or anything else.
-   All commits are always squashed on merge by GitHub, so there is no need to squash them manually, amend them, and/or do force pushes.
-   Autogenerated GitHub's squash commit's body should be manually replaced by "Closes #{issue_number}.".
-   Do not leave original commit messages in the squashed commit body.
-10. Pull requests should be merged by an auto-merge that the author should enable.
+6. Pull requests should be merged by an auto-merge that the author should enable.
     If the pull request is not ready to be merged for some reason (but ready to be reviewed as usual),
     the description should explain why, and the `do not merge` label should be applied.
     Even in that case, auto-merge should still be enabled by the author.
-11. Ultimately, the author is responsible for doing everything to ensure that the pull request is merged and done.
+7. Ultimately, the author is responsible for doing everything to ensure that the pull request is merged and done.
 
 One can see all pull requests that await review [there](https://github.com/pulls/review-requested?q=user%3AFerretDB+is%3Aopen).
 We also have [#devlog channel](https://ferretdb.slack.com/archives/C02P0MR7VJS)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -227,6 +227,8 @@ Also, we should use driver methods as much as possible instead of testing comman
 
 ### Submitting code changes
 
+#### Before submitting PR
+
 Before submitting a pull request, please make sure that:
 
 1. Tests are added for new functionality or fixed bugs.
@@ -239,6 +241,19 @@ Before submitting a pull request, please make sure that:
 3. Comments are rendered correctly in the `task godocs` output.
 4. `task all` passes.
 
+#### Submitting PR
+
+1. If the pull request is related to some issues, please mention the issue number in the pull request **description** like `Closes #{issue_number}.` or `Closes org/repo#{issue_number}.`(You can just follow the pull request template).
+   If you propose a tiny fix, there is no needed to create a new issue.
+2. In the pull request review conversations, please either leave a new comment or resolve (close) the conversation, which ensures the other people can read all comments.
+   But **do not** do that simultaneously.
+3. During your development, commit messages (both titles and bodies) are not important and can be "WIP" or anything else.
+   All commits are always squashed on merge by GitHub, so there is **no need** to squash them manually, amend them, and/or do force pushes.
+   But notice that the autogenerated GitHub's squash commit's body **should be** manually replaced by "Closes #{issue_number}.".
+4. Please don't forget to click "re-request review" buttons once PR is ready for re-review.
+
+If you have interest in becoming or are a long-term contributor, please read [PROCESS.md](.github/PROCESS.md) for more details.
+
 ## Reporting a bug
 
 We appreciate reporting a bug to us.