You may add the special address
firstname.lastname@example.org as a reviewer to
have Gerrit automatically choose an appropriate person to review your change.
Follow the advice at Speed of Code Reviews. Most importantly,
If you are not in the middle of a focused task, you should do a code review shortly after it comes in.
One business day is the maximum time it should take to respond to a code review request (i.e., first thing the next morning).
If you will not be able to review the change within a business day, comment on the change stating so, and reassign to another reviewer if possible.
Attention set management#
Remove yourself from the attention set for changes where another person (author or reviewer) must take action before you can continue to review. You are encouraged, but not required, to leave a comment when doing so, especially for changes by external contributors who may not be familiar with our process.
Common advice playbook#
What follows are bite-sized copy-paste-able advice when doing code reviews. Feel free to link to them from code review comments, too.
Sometimes, a change doesn’t make it out of the review process: after some rounds of review, there are unresolved comments from the Pigweed team, but the author is no longer actively working on the change.
For any change that’s not seen activity for 3 months, the Pigweed team will,
File a bug for the feature or bug that the change was addressing, referencing the change.
Mark the change Abandoned in Gerrit.
This does not mean the change is rejected! It just indicates no further action on it is expected. As its author, you should feel free to reopen it when you have time to work on it again.
Before making or sending major changes or SEEDs, please reach out in our chat room or on the mailing list first to ensure the changes make sense for upstream. We generally go through a design phase before making large changes. See 0001: The SEED Process for a description of this process; but please discuss with us before writing a full SEED. Let us know of any priorities, timelines, requirements, and limitations ahead of time.
Gerrit for PRs#
We don’t currently support GitHub pull requests. All Pigweed development takes place on our Gerrit instance. Please resubmit your change there!
Docs-Only Changes Do Not Need To Be Complete#
Documentation-only changes should generally be accepted if they make the docs better or more complete, even if the documentation change itself is incomplete.