Conversation
✅ Deploy Preview for playful-gelato-7892ba ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
git-branching-merging.qmd
Outdated
| ## Who merges the pull request? | ||
|
|
||
| By convention, the package maintainer is in charge of merging the pull requests. | ||
| This is indeed often more convenient as they are aware of other ongoing activities in the package that may impact or be impacted with the incoming changes. |
There was a problem hiding this comment.
| This is indeed often more convenient as they are aware of other ongoing activities in the package that may impact or be impacted with the incoming changes. | |
| This is because they are aware of other ongoing activities in the package that may impact or be impacted with the incoming changes. |
or else say more convenient than what
git-branching-merging.qmd
Outdated
| This is indeed often more convenient as they are aware of other ongoing activities in the package that may impact or be impacted with the incoming changes. | ||
| We also have a guarantee that maintainers have sufficient permissions to merge the pull request, and potentially bypass some checks if necessary, which may not be the case of the contributor. | ||
|
|
||
| This recommendation remains valid even if the maintainer if the author of the pull request and they request review from a non-maintainer. |
There was a problem hiding this comment.
| This recommendation remains valid even if the maintainer if the author of the pull request and they request review from a non-maintainer. | |
| This recommendation remains valid even if the maintainer is the author of the pull request and they request review from a non-maintainer. |
git-branching-merging.qmd
Outdated
|
|
||
| This recommendation remains valid even if the maintainer if the author of the pull request and they request review from a non-maintainer. | ||
|
|
||
| As a contributor, if you want to signal your changes are not ready to be merged, you should mark your pull requests as draft. |
There was a problem hiding this comment.
I like that this is mentioned. Do we also want to consider explicitly tagging a reviewer before reviewing can begin or can people just review if they feel the need to? I think the former introduces a little bit of friction but solves the issue where a PR seems to be open for review but is not ready or is still being actively worked on. The other solution would be to only open a PR for review after it was previously set to draft.
| As a maintainer, if you see a non draft pull request that looks like it might still receive additional changes, please check in with the contributor before proceeding with the merge. | ||
| Conversely, if a PR is marked as draft but seems ready to go, you can check in with the contributor if they have additional changes to make or if the PR can be marked as ready for review. | ||
| As a contributor, you can also check in with the maintainer to ensure they have not simply forgotten to merge the changes, especially if they already have approved the PR. |
There was a problem hiding this comment.
And if the author is unresponsive?
There was a problem hiding this comment.
I'm not sure we can have a policy for this. I suspect it will have to be dealt with on a case by case basis depending on who is unresponsive, who is trying to get something merged, what the exact circumstances, etc.
If you have a specific suggestion, please propose a follow up PR.
5 participants
Fix last item from #21.
I was reminded of this as we faced this situation today with @Karim-Mane.