Per, thanks for bringing up this issue. On Sun, Jun 24, 2012 at 08:13:04AM +0900, Charles Plessy wrote: > > To honour the recent vote on diversity [0] please make the developers > > reference gender neutral.
> > [0] http://www.debian.org/vote/2012/vote_002 > I think that our technical documents should be easy to read for non-native > speakers, and the modification that you propose mixes singular and plural > forms in a way that, as far as I know, is not taught to students who learn > the English language. I personally find it confusing and do not feel that > the use of "he" implies that the maintainer must be a man. You may not personally think so, but *native* speakers *do* see such an implication. I agree with Per that this is something that needs to be fixed. > Do you have example of high-proflile institutions in England or the U.S., > that recommend the use of "they" as you do ? http://suite101.com/article/the-generic-or-singular-they-a182106 references The Cambridge Guide to English Usage, which should be enough to be going on with. The particular patch Per has proposed here has a few bugs, such as this construction: -If a difference arises later (say, if upstream notices that he wasn't using -maximal compression in his original distribution and then +If a difference arises later (say, if upstream notices that they wasn't using +maximal compression in their original distribution and then This is definitely incorrect usage. Even when using singular "they" in English, "they" is always grammatically plural. This must be written "they weren't", not "they wasn't". (I think this was just an oversight, since Per's patch shows correct agreement elsewhere.) Attached is a corrected patch, which fixes the verb agreement issue above and makes a few other tweaks (e.g., not introducing passive tense where it's not needed, which is worse than the original problem it aims to fix), and also catches a few more gender-specific pronouns that were overlooked. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
Index: developer-duties.dbk
===================================================================
--- developer-duties.dbk (revision 9223)
+++ developer-duties.dbk (working copy)
@@ -37,7 +37,7 @@
<title>Maintain packages in <literal>stable</literal></title>
<para>
Most of the package maintainer's work goes into providing updated
-versions of packages in <literal>unstable</literal>, but his job also entails taking care
+versions of packages in <literal>unstable</literal>, but their job also entails taking care
of the packages in the current <literal>stable</literal> release.
</para>
<para>
@@ -77,7 +77,7 @@
</para>
<para>
Lack of attention to RC bugs is often interpreted by the QA team as a sign
-that the maintainer has disappeared without properly orphaning his package.
+that the maintainer has disappeared without properly orphaning their package.
The MIA team might also get involved, which could result in your packages
being orphaned (see <xref linkend="mia-qa" />).
</para>
Index: best-pkging-practices.dbk
===================================================================
--- best-pkging-practices.dbk (revision 9223)
+++ best-pkging-practices.dbk (working copy)
@@ -1630,9 +1630,9 @@
tarball is identical to what upstream <emphasis>currently</emphasis>
distributing at any point in time. All that can be expected is that it is
identical to something that upstream once <emphasis>did</emphasis> distribute.
-If a difference arises later (say, if upstream notices that he wasn't using
-maximal compression in his original distribution and then
-re-<command>gzip</command>s it), that's just too bad. Since there is no good
+If a difference arises later (say, if upstream notice that they weren't using
+maximal compression in their original distribution and then
+re-<command>gzip</command> it), that's just too bad. Since there is no good
way to upload a new <filename>.orig.tar.{gz,bz2,xz}</filename> for the same version, there is not even any
point in treating this situation as a bug. </para> </footnote> This makes it
possible to use checksums to easily verify that all changes between Debian's
@@ -1688,7 +1688,7 @@
</para>
<para>
In these cases the developer must construct a suitable <filename>.orig.tar.{gz,bz2,xz}</filename>
-file himself. We refer to such a tarball as a repackaged upstream
+file themselves. We refer to such a tarball as a repackaged upstream
source. Note that a repackaged upstream source is different from a
Debian-native package. A repackaged source still comes with Debian-specific
changes in a separate <filename>.diff.gz</filename> or <filename>.debian.tar.{gz,bz2,xz}</filename>
@@ -1856,7 +1856,7 @@
</para>
<para>
The long description of the meta-package must clearly document its purpose
-so that the user knows what he will lose if he removes the package. Being
+so that the user knows what they will lose if they remove the package. Being
explicit about the consequences is recommended. This is particularly
important for meta-packages which are installed during initial
installation and that have not been explicitly installed by the user.
Index: beyond-pkging.dbk
===================================================================
--- beyond-pkging.dbk (revision 9223)
+++ beyond-pkging.dbk (working copy)
@@ -346,13 +346,13 @@
<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 @@
</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 @@
<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 @@
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 @@
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
Index: pkgs.dbk
===================================================================
--- pkgs.dbk (revision 9223)
+++ pkgs.dbk (working copy)
@@ -1955,11 +1955,11 @@
<listitem>
<para>
If the maintainer is usually active and responsive, have you tried to contact
-him? In general it should be considered preferable that a maintainer takes care
-of an issue himself and that he is given the chance to review and correct your
-patch, because he can be expected to be more aware of potential issues which an
-NMUer might miss. It is often a better use of everyone's time if the maintainer
-is given an opportunity to upload a fix on their own.
+them? In general it should be considered preferable that maintainers take care
+of an issue themselves and that they are given the chance to review and
+correct your patch, because they can be expected to be more aware of potential
+issues which an NMUer might miss. It is often a better use of everyone's time
+if the maintainer is given an opportunity to upload a fix on their own.
</para>
</listitem>
</itemizedlist>
@@ -2121,7 +2121,7 @@
same time. For instance, instead of telling the maintainer that you will
upload the updated
package in 7 days, you should upload the package to
-<literal>DELAYED/7</literal> and tell the maintainer that he has 7 days to
+<literal>DELAYED/7</literal> and tell the maintainer that they have 7 days to
react. During this time, the maintainer can ask you to delay the upload some
more, or cancel your upload.
</para>
@@ -2130,12 +2130,12 @@
The <literal>DELAYED</literal> queue should not be used to put additional
pressure on the maintainer. In particular, it's important that you are
available to cancel or delay the upload before the delay expires since the
-maintainer cannot cancel the upload himself.
+maintainer cannot cancel the upload themselves.
</para>
<para>
If you make an NMU to <literal>DELAYED</literal> and the maintainer updates
-his package before the delay expires, your upload will be rejected because a
+the package before the delay expires, your upload will be rejected because a
newer version is already available in the archive.
Ideally, the maintainer will take care to include your proposed changes (or
at least a solution for the problems they address) in that upload.
Index: resources.dbk
===================================================================
--- resources.dbk (revision 9223)
+++ resources.dbk (working copy)
@@ -627,7 +627,7 @@
<para>
Active development is done in the <literal>unstable</literal> distribution
(that's why this distribution is sometimes called the <literal>development
-distribution</literal>). Every Debian developer can update his or her
+distribution</literal>). Every Debian developer 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 made to make
sure everything in this distribution is working properly, it is sometimes
Index: l10n.dbk
===================================================================
--- l10n.dbk (revision 9223)
+++ l10n.dbk (working copy)
@@ -158,7 +158,7 @@
<title>How to handle a bug report concerning a translation</title>
<para>
The best solution may be to mark the bug as forwarded to upstream, and forward
-it to both the previous translator and his/her team (using the corresponding
+it to both the previous translator and their team (using the corresponding
debian-l10n-XXX mailing list).
<!-- TODO: add the i18n tag to the bug? -->
</para>
signature.asc
Description: Digital signature
