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.

Comienza revisando el procedimiento propuesto y los ejemplos de revisión enlazados en el issue #1359; después, inspecciona la documentación existente del devguide sobre contribuciones y el proceso de revisión para encontrar la ubicación adecuada. Se considerará terminado cuando haya un procedimiento acordado documentado, incluida la responsabilidad del seguimiento y enlaces desde los nuevos issues o PRs al comentario de revisión original.