Index: 2.11/developers-reference.sgml
===================================================================
--- 2.11/developers-reference.sgml	(revision 10421)
+++ 2.11/developers-reference.sgml	(working copy)
@@ -217,7 +217,7 @@
 to verify your application (an <em>advocate</em>).  After you have
 contributed to Debian for a while, and you want to apply to become a
 registered developer, an existing developer with whom you
-have worked over the past months has to express his belief that you
+have worked over the past months has to state the belief that you
 can contribute to Debian successfully.
 	<p>
 When you have found an advocate, have your GPG key signed and have
@@ -358,14 +358,14 @@
       <p>
 If you notice that a package is lacking maintenance, you should
 make sure the maintainer is active and will continue to work on
-his packages. Try contacting him yourself.
+the packages. Try contacting the maintainer yourself.
       <p>
 If you do not get a reply after a few weeks you should collect all 
 useful information about this maintainer. Start by logging into 
 the <url id="&url-debian-db;" name="Debian Developer's Database">
 and doing a full search to check whether the maintainer is on vacation
-and when he was last seen. Collect any important package names
-he maintains and any Release Critical bugs filled against them.
+and when was last seen. Collect any important package names
+maintained by this person and any Release Critical bugs filled against them.
       <p>
 Send all this information to &email-debian-qa;, in order to let the 
 QA people do whatever is needed.
@@ -742,7 +742,7 @@
 	<p>
 Active development is done in the <em>unstable</em> distribution
 (that's why this distribution is sometimes called the <em>development
-distribution</em>). Every Debian developer can update his or her
+distribution</em>). Debian developers can update their
 packages in this distribution at any time. Thus, the contents of this
 distribution change from day-to-day. Since no special effort is done
 to make sure everything in this distribution is working properly, it is
Index: 3.0/developers-reference.sgml
===================================================================
--- 3.0/developers-reference.sgml	(revision 10421)
+++ 3.0/developers-reference.sgml	(working copy)
@@ -227,7 +227,7 @@
 to verify your application (an <em>advocate</em>).  After you have
 contributed to Debian for a while, and you want to apply to become a
 registered developer, an existing developer with whom you
-have worked over the past months has to express his belief that you
+have worked over the past months has to state the belief that you
 can contribute to Debian successfully.
 	<p>
 When you have found an advocate, have your GnuPG key signed and have
@@ -981,9 +981,9 @@
 waiting before uploading a NMU, it is uploaded as soon as it is
 ready but in one of those <file>DELAYED/<var>x</var>-day</file> directories.
 That leaves the corresponding number of days to the maintainer
-in order to react and upload himself another fix if he is not
-completely satisfied with the NMU. Alternatively he can remove
-the NMU by himself.
+in order to react and upload autonomously another fix if not
+completely satisfied with the NMU. Alternatively the maintainer can directly remove
+the NMU.
 	<p>
 The use of that delayed feature can be simplified with a bit
 of integration with your upload tool.  For instance, if you use 
@@ -1042,7 +1042,7 @@
 id="&url-testing-maint;">. Alternatively, it is possible to use
 the <prgn>grep-excuses</prgn> program part of the
 <package>devscripts</package> package. It can be easily put in a crontab
-to keep someone informed of the progression of his packages in testing.
+to keep someone informed of the progression of the packages in testing.
 	<p>
 The <file>update_excuses</file> file does not always give the precise reason
 why the package is refused, one may have to find it by himself by looking
@@ -1053,7 +1053,7 @@
 Sometimes, some packages never enter testing because the set of
 inter-relationship is too complicated and can not be sorted out
 by the scripts. In that case, the release manager must be
-contacted, and he will force the inclusion of the packages.
+contacted to force the inclusion of the packages.
 
     <sect id="pkg-info">Package's information
 	<p>
@@ -1822,11 +1822,11 @@
 (BTS).  If not, submit a bug.  
 	    <item>
 Wait a few days the response from the maintainer. If you don't get
-any response, you may want to help him by sending the patch that fixes
+any response, you may want to help by sending the patch that fixes
 the bug. Don't forget to tag the bug with the "patch" keyword.
 	    <item>
 Wait a few more days. If you still haven't got an answer from the
-maintainer, send him a mail announcing your intent to NMU the package.
+maintainer, contact the person by e-mail announcing your intent to NMU the package.
 Prepare an NMU as described in <ref id="nmu-guidelines">, test it
 carefully on your machine (cf. <ref id="upload-checking">).
 Double check that your patch doesn't have any unexpected side effects.
@@ -1834,7 +1834,7 @@
 	    <item>
 Upload your package to incoming in <file>DELAYED/7-day</file> (cf.
 <ref id="delayed-incoming">), send the final patch to the maintainer via
-the BTS, and explain him that he has 7 days to react if he wants to cancel
+the BTS, and explain that there are 7 days for the maintainer to react if wishing to cancel
 the NMU.
 	    <item>
 Follow what happens, you're responsible for any bug that you introduced
@@ -1977,8 +1977,8 @@
 In any case, you should not be upset by the NMU. An NMU is not a
 personal attack against the maintainer. It is just the proof that
 someone cares enough about the package and was willing to help
-you in your work. You should be thankful to him and you may want to
-ask him if he would be interested to help you on a more frequent
+you in your work. You should be thankful to the NMU and you may want to
+inquire whether this person is willing to help you on a more frequent
 basis as co-maintainer or backup maintainer
 (see <ref id="collaborative-maint">).
 
@@ -2476,7 +2476,7 @@
 Decide whether the report corresponds to a real bug or not. Sometimes
 users are just calling a program in the wrong way because they haven't
 read the documentation. If you diagnose this, just close the bug with
-enough information to let the user correct his problem (give pointers
+enough information to let the user correct the problem (give pointers
 to the good documentation and so on). If the same report comes up
 again and again you may ask yourself if the documentation is good
 enough or if the program shouldn't detect its misuse in order to
@@ -2507,7 +2507,7 @@
 change is just cosmetic.
     <item>
 The bug submitter may have forgotten to provide some information, in that
-case you have to ask him the information required. You may use the
+case you have to ask for the information required. You may use the
 <tt>moreinfo</tt> tag to mark the bug as such. Moreover if you can't
 reproduce the bug, you tag it <tt>unreproducible</tt>. Anyone who
 can reproduce the bug is then invited to provide more information
@@ -2694,8 +2694,7 @@
 do the same with <prgn>debconf-mergetemplate</prgn>
 (package <package>debconf-utils</package>). 
 	<p>
-When the package maintainer needs to update the templates file, he only
-changes <file>debian/templates</file>.  When English strings in this file
+When the package maintainer needs to update the templates file, only <file>debian/templates</file> need to be changed.  When English strings in this file
 and in <file>debian/templates.xx</file> differ, translators do know that
 their translation is outdated.
 	<p>
@@ -2789,8 +2788,8 @@
 	    <p>
 The description of the package (as defined by the corresponding field
 in the <file>control</file> file) is usually the first information
-available to the user before he installs it. As such, it should
-provide all the required information to let him decide whether
+available to the user before the installation. As such, it should
+provide all the required information to let the user decide whether
 to install the package.
 	    <p>
 For example, apart from the usual description that you adapt from the
@@ -2883,13 +2882,13 @@
       <p>
 If you notice that a package is lacking maintenance, you should
 make sure the maintainer is active and will continue to work on
-his packages. Try contacting him yourself.
+the packages. Try contacting the maintainer by yourself.
       <p>
 If you do not get a reply after a few weeks you should collect all 
 useful information about this maintainer. Start by logging into 
 the <url id="&url-debian-db;" name="Debian Developer's Database">
 and doing a full search to check whether the maintainer is on vacation
-and when he was last seen. Collect any important package names
+and when was last seen. Collect any important package names
 he maintains and any Release Critical bugs filled against them.
       <p>
 Send all this information to &email-debian-qa;, in order to let the 
@@ -2961,9 +2960,7 @@
 theory, you should only ask only for the diff file, and the location of the
 original source tarball, and then you should download the source and apply
 the diff yourself. In practice, you may want to use the source package
-built by your sponsoree. In that case you have to check that he hasn't
-altered the upstream files in the <file>.orig.tar.gz</file> file that he's
-providing.
+built by your sponsoree. In that case you have to check that the upstream files in the <file>.orig.tar.gz</file> file provided by your sponsoree hadn't been altered.
 	<p>
 Do not be afraid to write the sponsoree back and point out changes
 that need to be made.  It often takes several rounds of back-and-forth
Index: 3.3.8/developers-reference.sgml
===================================================================
--- 3.3.8/developers-reference.sgml	(revision 10421)
+++ 3.3.8/developers-reference.sgml	(working copy)
@@ -4829,8 +4829,7 @@
 time. All that can be expected is that it is identical to
 something that upstream once <em>did</em> distribute.
 
-If a difference arises later (say, if upstream notices that he wasn't
-using maximal comression in his original distribution and then
+If a difference arises later (say, if upstream notices that maximal comression hadn't been used in the original distribution and then
 re-<tt>gzip</tt>s it), that's just too bad. Since there is no good way
 to upload a new .orig.tar.gz for the same version, there is not even
 any point in treating this situation as a bug.
