From 7daa81f0cd65b4038989b53a84f47d8e51baccdb Mon Sep 17 00:00:00 2001 From: Luis Valdes Date: Sun, 16 Apr 2017 06:22:51 -0400 Subject: [PATCH] Fix typo Change to improvement --- contributors/devel/development.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributors/devel/development.md b/contributors/devel/development.md index 779b6bf5a..f0e645fcf 100644 --- a/contributors/devel/development.md +++ b/contributors/devel/development.md @@ -64,7 +64,7 @@ Examples of how NOT to suggest a performance bug (these can really lead to a lon The above statements have basically no value to a reviewer, because neither is a strong, testable, assertive statement. This will land your PR in a no-man's-land zone (at best), or waste tons of time for a busy reviewer (at worst). -Of course any improvment is welcome, but performance improvements are the hardest to review. They often make code more +Of course any improvement is welcome, but performance improvements are the hardest to review. They often make code more complex, and to-often are not easily evaluated at review time due to lack of sufficient data submitted by the author of a performance improvement patch.