From: joy <joy@313b444b-1b9f-4f58-a734-7bb04f332e8d>
Date: Sat, 22 Feb 2003 18:54:47 +0000 (+0000)
Subject: tidied up the vacation section
X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=developers-reference.git;a=commitdiff_plain;h=4429914d13bcd922d5f29aae420b19697f7ffe1b

tidied up the vacation section


git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@2173 313b444b-1b9f-4f58-a734-7bb04f332e8d
---

diff --git a/developers-reference.sgml b/developers-reference.sgml
index d457656..dcaced2 100644
--- a/developers-reference.sgml
+++ b/developers-reference.sgml
@@ -6,7 +6,7 @@
   <!entity % commondata  SYSTEM "common.ent" > %commondata;
 
   <!-- CVS revision of this document -->
-  <!entity cvs-rev "$Revision: 1.178 $">
+  <!entity cvs-rev "$Revision: 1.179 $">
   <!-- if you are translating this document, please notate the CVS
        revision of the developers reference here -->
   <!--
@@ -278,6 +278,7 @@ at <url id="&url-debian-db-doc;">.
 	<p>
 You have to keep the information available there up-to-date.
 
+
       <sect id="key-maint">Maintaining your public key
 	<p>
 Be very careful with your private keys.  Do not place them on any
@@ -319,27 +320,33 @@ The list of all the proposals (past and current) is available on the
 <url id="&url-vote;" name="Debian Voting Information"> page, along with
 information on how to make, second and vote on proposals.
 
+
       <sect id="inform-vacation">Going on vacation gracefully
 	<p>
-Most developers take vacations, and usually this means that they can't
-work for Debian and they can't be reached by email if any problem occurs.
-The other developers need to know that you're on vacation so that they'll
-do whatever is needed when such a problem occurs. Usually this means that
-other developers are allowed to NMU (see <ref id="nmu">) your package if a
-big problem (release critical bugs, security update, etc.) occurs while
-you're on vacation.
+It is common for developers to have periods of absence, whether those are
+planned vacations or simply being buried in other work. The important thing
+to notice is that the other developers need to know that you're on vacation
+so that they can do whatever is needed if a problem occurs with your
+packages or other duties in the project.
+	<p>
+Usually this means that other developers are allowed to NMU (see
+<ref id="nmu">) your package if a big problem (release critical bugs,
+security update, etc.) occurs while you're on vacation. Sometimes it's
+nothing as critical as that, but it's still appropriate to let the others
+know that you're unavailable.
 	<p>
 In order to inform the other developers, there's two things that you should do.
-First send a mail to &email-debian-private; giving the period of time when
-you will be on vacation.  You can also give some special instructions on what to
-do if any problem occurs. Be aware that some people don't care for vacation
-notices and don't want to read them; you should prepend "[VAC] " to the
-subject of your message so that it can be easily filtered.
+First send a mail to &email-debian-private; with "[VAC] " prepended to the
+subject of your message<footnote>This is so that the message can be easily
+filtered by people who don't want to read vacation notices.</footnote>,
+giving the period of time when you will be on vacation. You can also give
+some special instructions on what to do if a problem occurs.
 	<p>
-Next you should update your information
-available in the Debian LDAP database and mark yourself as ``on vacation''
-(this information is only accessible to debian developers). Don't forget
-to remove the ``on vacation'' flag when you come back!
+The other thing to do is to mark yourself as "on vacation" in the
+<qref id="devel-db">Debian developers' LDAP database</qref> (this
+information is only accessible to Debian developers).
+Don't forget to remove the "on vacation" flag when you come back!
+
 
       <sect id="upstream-coordination">Coordination with upstream developers
 	<p>
@@ -360,6 +367,7 @@ developers which can be included there, so that you won't have to
 modify the sources of the next upstream version. Whatever changes you
 need, always try not to fork from the upstream sources.
 
+
       <sect id="rc-bugs">Managing release-critical bugs
         <p>
 Generally you should deal with bug reports on your packages as described in