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 連結到原始審查留言。