1. Everyone is encouraged to make an anonymous pull request.
2. Anonymous pull requests are immediately visible to everyone who would ordinarily be able to a read a pull request.
3. However, by convention, nobody should spend any significant time looking at an anonymous pull request until after review by a senior person. At this initial stage, the senior person's job isn't to assess the details of the change, but only to assess the risk that the pull request may be wrong for reasons that aren't apparent within any of the modified files. The senior person then flags the pull request as either OK_TO_REVIEW or CANNOT_BE_ANONYMOUS.
4. When a flagger has set CANNOT_BE_ANONYMOUS, this means that the pull request -- if it were from a person who is new to the overall architecture or goals -- may generate a lot of review work even though the contribution has little chance of ever being used. In other words, you can waste a lot of time and money by reviewing a contribution when you have no context about the contributor's stature. Anomalies that may be noticed by a flagger vary across projects, but might include:
a. The code changes operate on untrusted data as if it were trusted.
b. The code changes operate on trusted data as if it were untrusted.
c. The code changes add expensive computation to the critical path.
d. The code changes improve a deprecated feature.
e. It violates the primary rule of Office Space ("Is This Good for the COMPANY?"). For example, adding this feature to Product X would reduce sales of Product Y.
5. When there's a CANNOT_BE_ANONYMOUS flag, anyone can add a non-anonymous comment of the form "I am developer MyName who has previously contributed. I understand the architecture and goals, and believe the flagger is wrong." Then, the flagger and MyName should try to reach agreement.