I am trying to share the document on linkedin recently, but the preview picture looks bad.

Probably we can add a thumbnail to improve this document.

This project didn't add new content in the past 6 months, and could I know is there any new thing or an updated plan in the future.

I would like to know if we will have more explanations about security code review

Should async be accessed and if its a must to treat callbacks
Or the most security way to store tables using code
How to push messages for users with plaintexts, etc
If code can produce logs with confidential text
If not on this repository, where can i found more about

I noticed the section headers don't have links on google.githhub.io, but they do on github.com.

Example:
https://google.github.io/eng-practices/review/reviewer/looking-for.html
vs
https://github.com/google/eng-practices/blob/master/review/reviewer/looking-for.md

The latter has clickable links to a section like so:
https://github.com/google/eng-practices/blob/master/review/reviewer/looking-for.md#functionality

The former seems to respect the URL fragments if I type them manually, but I don't see a way to get the URL from clicking something on the page.

Being able to link to specific sections is really useful during code reviews.

Out of pure curiosity. :)

I am thinking this is taken care of some place else or the risk profile is just different from project to project. So you cant make it general description maybe. I just wonder why its not a point to look for?

btw. Thanks for a awesome guide perfect for inspiration - thanks for sharing it.

Please define this. Thanks!

I recall reading, either in these docs, or very similar docs, that the average CL size at google was about 23-24 lines, and review takes 1-4 hours

I was trying to find this information again to reference it, but can't find it!

• What is the average review time for a CL at Google?
• What's the average number of loc added/removed for a CL at Google?

It is already noted in the github repo that CL doesn't have any meaning outside of Google, and I'm glad that it is defined in the repo for those of us outside of the Google ecosystem.

I would like to make a suggestion that would solve this problem for people outside of Google (the documents have general appeal), as well as anyone within Google but new to the Google way of doing things.

1. Always define an acronym before using it. It is easy enough to say: "When starting to review a new change list (CL).." This way nobody has to feel like they're dumb for missing something so simple as what a CTLG is or a VA is, or make sure you STL that. It's frustrating when acronyms are used with no definition anywhere in sight. Did you miss it? Was it in that paragraph up top? Maybe it is defined in one of the other pages in the table of contents.... It is unnecessarily wasted time for the reader to hunt down what terms you are using.

2. Include a glossary.

Just my $0.02

I really like the documents otherwise. Lots of good lessons, looking forward to sharing them within my organization.

Not sure if this was addressed in the article yet. Who should be in charge of resolving the comments? Should the reviewee resolve it on their own when they think it is fixed, or should the reviewer come back and verify the changes and resolve the thread? Who has the final decision?