Define and document a procedure for following up on reviews

I noticed several instances in which someone (typically a reviewer) suggests a change/improvement or points out other areas affected by the same issue, but those changes are deemed out of the scope of the current PR. Even if there is consensus that these changes should take place, often no follow-up takes place.

When this happens, there are usually different actors involved:

• the author of the PR
• the reviewer that suggested/requested the change (sometimes this is the author themselves)
• whoever suggested to handle the change in a separate PR (might be the author or a reviewer)

There are at least a couple of reasons why the follow-up doesn't happen:

• it is not clear whose responsibility it is to follow up
• people might only be interested in the initial issue, and don't have time/desire to fix the requested changes

In order to solve these issues, I suggest we adopt and document the following procedure:

1. When a situation arises where a follow-up is necessary, the author of the PR should either volunteers to follow up, or ask one of the other actors if they would like to do it. This solves the first issue by ensuring that one of actors does follow up.
2. The appointed person should then create a new issue (or even a PR) that links to the original comment where the follow-up was requested, in order to provide context. It is not expected that whoever creates the follow-up issue/PR invests any more time in fixing it (even though it would be appreciated). This solves the second issue by setting expectations.

The goal here is both to create a reminder and to provide context through the reference to the previous PR.

Generally, the follow-up should be create when the suggestion is a defined action item. If for example the changes in the PR are "good enough" but could be better (such as when the code was optimized, but could be optimized further), and it's not clear how to make them better, then it's not always necessary to create a new follow-up issue.

首先查看 issue #1359 中提议的流程和链接的评审示例，然后检查 devguide 中现有的贡献者和评审流程文档，以找到合适的位置。完成的标准是记录一套达成共识的流程，其中包括后续跟进的责任，以及从新 issue 或 PR 链接到原始评审评论。