diff --git a/HACKING b/HACKING
index 0be13bb86f..884e78cadd 100644
--- a/HACKING
+++ b/HACKING
@@ -61,12 +61,12 @@ Please follow this as close as you can, especially the rebase and git
 send-email part, as it makes life easier for other developers to review your
 patch set. One should avoid sending patches as attachments, but rather send
 them in email body along with commit message. If a developer is sending
-another version of the patch (e.g. to address review comments), he is advised
-to note differences to previous versions after the "---" line in the patch so
-that it helps reviewers but doesn't become part of git history. Moreover, such
-patch needs to be prefixed correctly with "--subject-prefix=PATCHv2" appended
-to "git send-email" (substitute "v2" with the correct version if needed
-though).
+another version of the patch (e.g. to address review comments), they are
+advised to note differences to previous versions after the "---" line in the
+patch so that it helps reviewers but doesn't become part of git history.
+Moreover, such patch needs to be prefixed correctly with
+"--subject-prefix=PATCHv2" appended to "git send-email" (substitute "v2" with
+the correct version if needed though).
 
 
 
diff --git a/docs/hacking.html.in b/docs/hacking.html.in
index 32ebd8e0ac..a73b1e0c85 100644
--- a/docs/hacking.html.in
+++ b/docs/hacking.html.in
@@ -65,7 +65,7 @@
         review your patch set. One should avoid sending patches as attachments,
         but rather send them in email body along with commit message. If a
         developer is sending another version of the patch (e.g. to address
-        review comments), he is advised to note differences to previous
+        review comments), they are advised to note differences to previous
         versions after the <code>---</code> line in the patch so that it helps
         reviewers but doesn't become part of git history. Moreover, such patch
         needs to be prefixed correctly with