+Be very careful with your private keys. Do not place them on any
+public servers or multiuser machines, such as
+<tt>master.debian.org</tt>. Back your keys up; keep a copy offline.
+Read the documentation that comes with your software; read the <url
+id="&url-pgp-faq;" name="PGP FAQ">.
+ <p>
+If you add signatures to your public key, or add user identities, you
+can update the debian keyring by sending your key to the key server at
+<tt>&keyserver-host;</tt>. If you need to add a completely new key,
+or remove an old key, send mail to &email-debian-keyring;. The same
+key extraction routines discussed in <ref id="registering"> apply.
+ <p>
+You can find a more in-depth discussion of Debian key maintenance in
+the documentation for the <package>debian-keyring</package> package.
+
+ <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, ...) occurs while
+you're on vacation.
+ <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.
+ <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!
+
+ <sect id="upstream-coordination">Coordination With Upstream Developers
+ <p>
+A big part of your job as Debian maintainer will be to stay in contact
+with the upstream developers. Debian users will sometimes report bugs
+to the Bug Tracking System that are not specific to Debian. You
+must forward these bug reports to the upstream developers so that
+they can be fixed in a future release. It's not your job to fix
+non-Debian specific bugs. However, if you are able to do so, you are
+encouraged to contribute to upstream development of the package by
+providing a fix for the bug. Debian users and developers will often
+submit patches to fix upstream bugs, and you should evaluate and
+forward these patches upstream.
+ <p>
+If you need to modify the upstream sources in order to build a policy
+conformant package, then you should propose a nice fix to the upstream
+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>
+Release Critical Bugs (RCB) are all bugs that have severity
+<em>critical</em>, <em>grave</em> or <em>serious</em>.
+Those bugs can delay the Debian release
+and/or can justify the removal of a package at freeze time. That's why
+these bugs need to be corrected as quickly as possible. You must be
+aware that some developers who are part of the <url
+id="&url-debian-qa;" name="Debian Quality Assurance"> effort are
+following those bugs and try to help you whenever they are able. But if
+you can't fix such bugs within 2 weeks, you should either ask for help
+by sending a mail to the Quality Assurance (QA) group
+&email-debian-qa;, or explain your difficulties and present a plan to fix
+them by sending a mail to the proper bug report. Otherwise, people
+from the QA group may want to do a Non-Maintainer Upload (see
+<ref id="nmu">) after trying to contact you (they might not wait as long as
+usual before they do their NMU if they have seen no recent activity from you
+in the BTS).
+
+ <sect id="qa-effort">Quality Assurance Effort
+ <p>
+Even though there is a dedicated group of people for Quality
+Assurance, QA duties are not reserved solely for them. You can
+participate in this effort by keeping your packages as bug-free as
+possible, and as lintian-clean (see <ref id="lintian-reports">) as
+possible. If you do not find that possible, then you should consider
+orphaning some of your packages (see <ref
+id="orphaning">). Alternatively, you may ask the help of other people
+in order to catch up the backlog of bugs that you have (you can ask
+for help on &email-debian-qa; or &email-debian-devel;).
+
+ <sect id="mia-qa">Dealing with unreachable maintainers
+ <p>
+If you notice that a package is lacking maintenance, you should
+make sure the maintainer is active and will continue to work on
+their packages. Try contacting them 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 in to
+the <url id="http://db.debian.org" name="Debian Developer's Database">
+and doing a full search to check whether the maintainer is on vacation
+and when they were last seen. Collect any important package names
+they maintain 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.