Devils in the details are found only when the high level design is refined and gets more detailed, and the appropriate phrase to use to describe this is "problems are revealed", not "problems are reviewed". Reviews may reveal these problems, though ;-) Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> --- Documentation/process/3.Early-stage.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/process/3.Early-stage.rst b/Documentation/process/3.Early-stage.rst index af2c0af931d6..be00716071d4 100644 --- a/Documentation/process/3.Early-stage.rst +++ b/Documentation/process/3.Early-stage.rst @@ -178,7 +178,7 @@ matter is (1) kernel developers tend to be busy, (2) there is no shortage of people with grand plans and little code (or even prospect of code) to back them up, and (3) nobody is obligated to review or comment on ideas posted by others. Beyond that, high-level designs often hide problems -which are only reviewed when somebody actually tries to implement those +which are only revealed when somebody actually tries to implement those designs; for that reason, kernel developers would rather see the code. If a request-for-comments posting yields little in the way of comments, do -- 2.14.1-981-g3e3c0c3ae1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
