X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=developers-reference.git;a=blobdiff_plain;f=beyond-pkging.dbk;h=371fba21d3b1e20e312448a2b0245795af0cb062;hp=88056fcc425d5ac440d48057888cd9eff7d257ec;hb=52dc65cfa7d8ecbd0c6631fa9ca9c61be60be0a6;hpb=ee5cd8e4b25b5cc08eba4e381cfdfe56d4d7b911

diff --git a/beyond-pkging.dbk b/beyond-pkging.dbk
index 88056fc..371fba2 100644
--- a/beyond-pkging.dbk
+++ b/beyond-pkging.dbk
@@ -346,13 +346,13 @@ the package is maintained.</para>
 <para>The sponsor downloads (or checkouts) the source package.</para>
 </listitem>
 <listitem>
-<para>The sponsor reviews the source package. If she finds issues, she
-informs the maintainer and asks her to provide a fixed version (the
+<para>The sponsor reviews the source package. If they find issues, they
+inform the maintainer and ask them to provide a fixed version (the
 process starts over at step 1).</para>
 </listitem>
 <listitem>
-<para>The sponsor could not find any remaining problem. She builds the
-package, signs it, and uploads it to Debian.</para>
+<para>The sponsor could not find any remaining problem. They build the
+package, sign it, and upload it to Debian.</para>
 </listitem>
 </orderedlist>
 </para>
@@ -369,15 +369,15 @@ and how large is the user base? How active are the upstream developers?
 </para>
 <para>
 You should also ensure that the prospective maintainer is going
-to be a good maintainer. Does she already have some experience with other
-packages? If yes, is she doing a good job with them (check out some bugs)?
-Is she familiar with the package and its programming language?
-Does she have the skills needed for this package? If not, is she able
+to be a good maintainer. Do they already have some experience with other
+packages? If yes, are they doing a good job with them (check out some bugs)?
+Are they familiar with the package and its programming language?
+Do they have the skills needed for this package? If not, are they able
 to learn them?
 </para>
 <para>
-It's also a good idea to know where she stands towards Debian: does
-she agree with Debian's philosophy and does she intend to join Debian?
+It's also a good idea to know where they stand with respect to Debian: do
+they agree with Debian's philosophy and do they intend to join Debian?
 Given how easy it is to become a Debian Maintainer, you might want
 to only sponsor people who plan to join. That way you know from the start
 that you won't have to act as a sponsor indefinitely.
@@ -473,7 +473,7 @@ remove and purge the packages. Maybe test them with <command>piuparts</command>.
 <para>
 If the audit did not reveal any problem, you can build the package and
 upload it to Debian. Remember that even if you're not the maintainer,
-the sponsor is still responsible of what he uploaded to Debian. That's
+as a sponsor you are still responsible for what you upload to Debian. That's
 why you're encouraged to keep up with the package through the
 <xref linkend="pkg-tracking-system"/>.
 </para>
@@ -482,7 +482,7 @@ Note that you should not need to modify the source package to put your name
 in the <filename>changelog</filename> or in the <filename>control</filename> file. The <literal>Maintainer</literal>
 field of the <filename>control</filename> file and the
 <filename>changelog</filename> should list the person who did the
-packaging, i.e. the sponsoree. That way she will get all the BTS mail.
+packaging, i.e. the sponsoree. That way they will get all the BTS mail.
 </para>
 <para>Instead you should instruct <command>dpkg-buildpackage</command> to use your key for
 the signature. You do that with the <literal>-k</literal> option:</para>
@@ -539,11 +539,11 @@ linkend="pkg-tracking-system"/>) to verify if the
 maintainer has not missed something important. Maybe there are translations
 updates sitting in the BTS that could have been integrated. Maybe the package
 has been NMUed and the maintainer forgot to integrate the changes from the
-NMU in his package. Maybe there's a release critical bug that he has left
-unhandled and that's blocking migration to <literal>testing</literal>. Whatever. If you find
-something that she could have done (better), it's time to tell her so that
-she can improve for next time, and so that she has a better understanding
-of her responsibilities.
+NMU into their package. Maybe there's a release critical bug that they have
+left unhandled and that's blocking migration to <literal>testing</literal>.
+If you find something that they could have done (better), it's time to tell
+them so that they can improve for next time, and so that they have a better
+understanding of their responsibilities.
 </para>
 <para>
 If you have found no major problem, upload the new version. Otherwise