Recently Charles (as far as I remember) asked what is the criteria for giving a PR 'Design Review' tag.
I suggest that *a PR should be labelled "Design Review" if it will be hard to undo it (after it appears in some release), it will have lasting consequences on the codebase.* Addition of a new config property, public API, or changing existing public API is always hard to undo because it immediately becomes a subject for backwards compatibility. But some large code changes, even without user-facing API or config changes, could have similar effect on the codebase. Please keep in mind that it's not just for requiring two reviews instead of one, but also for really reviewing the design. E. g. bad config key/property names could stay forever because it's really hard to rename them, even harder than change Java APIs.
