---

22.13 Beiträge von anderen überprüfen

Den wohl größten Nutzen, damit GNU Guix als Projekt wächst, steuern Sie bei, wenn Sie die Beiträge von anderen gegenlesen und überprüfen. Dazu müssen Sie kein Committer sein; Sie wenden den Patch an (git am bzw. git apply), lesen den Quellcode, erstellen ihn und setzen ihn Linting aus, außerdem können Sie die Patchreihen anderer Leute auf Ihrem Rechner ausprobieren und kommentieren, wie Sie zurechtkommen, was anderen Committern Sicherheit gibt. Vereinfacht gesagt stellen Sie sicher, dass der Prüfliste aus dem Abschnitt Einreichen von Patches korrekt Folge geleistet wurde. Wenn eine Patchserie bereits überprüft worden ist, dann hat sie die besten Chancen, schneller ins Repository gemerget zu werden. Wenn Sie also gerne eine Änderung angenommen sehen würden und diese noch niemand überprüft hat, dann übernehmen am besten Sie die Aufgabe!

Review comments should be unambiguous; be as clear and explicit as you can about what you think should be changed, ensuring the author can take action on it. Please try to keep the following guidelines in mind during review:

1. Be clear and explicit about changes you are suggesting, ensuring the author can take action on it. In particular, it is a good idea to explicitly ask for new revisions when you want it.
2. Remain focused: do not change the scope of the work being reviewed. For example, if the contribution touches code that follows a pattern deemed unwieldy, it would be unfair to ask the submitter to fix all occurrences of that pattern in the code; to put it simply, if a problem unrelated to the patch at hand was already there, do not ask the submitter to fix it.
3. Ensure progress. As they respond to review, submitters may submit new revisions of their changes; avoid requesting changes that you did not request in the previous round of comments. Overall, the submitter should get a clear sense of progress; the number of items open for discussion should clearly decrease over time.
4. Aim for finalization. Reviewing code is time-consuming. Your goal as a reviewer is to put the process on a clear path towards integration, possibly with agreed-upon changes, or rejection, with a clear and mutually-understood reasoning. Avoid leaving the review process in a lingering state with no clear way out.
5. Review is a discussion. The submitter’s and reviewer’s views on how to achieve a particular change may not always be aligned. To lead the discussion, remain focused, ensure progress and aim for finalization, spending time proportional to the stakes⁴⁹. As a reviewer, try hard to explain the rationale for suggestions you make, and to understand and take into account the submitter’s motivation for doing things in a certain way.

When you deem the proposed change adequate and ready for inclusion within Guix, the following well understood/codified ‘Reviewed-by: Your Name<your-email@example.com>’ ⁵⁰ line should be used to sign off as a reviewer, meaning you have reviewed the change and that it looks good to you:

• If the whole series (containing multiple commits) looks good to you, reply with ‘Reviewed-by: Your Name<your-email@example.com>’ to the cover page if it has one, or to the last patch of the series otherwise, adding another ‘(for the whole series)’ comment on the line below to explicit this fact.
• If you instead want to mark a single commit as reviewed (but not the whole series), simply reply with ‘Reviewed-by: Your Name<your-email@example.com>’ to that commit message.

If you are not a committer, you can help others find a series you have reviewed more easily by adding a reviewed-looks-good usertag for the guix user (siehe Debbugs-Usertags).