git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

'Design Review' tag


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.