+The mailing list &email-debian-mentors; has been set up for novice
+maintainers who seek help with initial packaging and other
+developer-related issues. Every new developer is invited to subscribe
+to that list (see <ref id="mailing-lists"> for details).
+ <p>
+Those who prefer one-on-one help (e.g., via private email) should also
+post to that list and an experienced developer will volunteer to help.
+
+
+ <chapt id="developer-duties">Debian Developer's Duties
+
+ <sect id="user-maint">Maintaining Your Debian Information
+ <p>
+There's a LDAP database containing many informations concerning all
+developers, you can access it at <url id="&url-debian-db;">. You can
+update your password (this password is propagated to most of the machines
+that are accessible to you), your address, your country, the latitude and
+longitude of the point where you live, phone and fax numbers, your
+preferred shell, your IRC nickname, your web page and the email that
+you're using as alias for your debian.org email. Most of the information
+is not accessible to the public, for more details about this
+database, please read its online documentation that you can find
+here : <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
+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. 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
+those bugs needs to be corrected as fast 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 each time they can. 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 justify yourself and present your plan to fix
+it by sending a mail to the bug concerned 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
+on 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 to 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 think that it's quite impossible, then you should
+consider orphaning (see <ref id="orphaning">) some of your packages so
+that you can do a good job with the other packages that you
+maintain. 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>Retiring Gracefully
+ <p>
+If you choose to leave the Debian project, you should make sure you do
+the following steps:
+<enumlist>
+ <item>
+Orphan all your packages, as described in <ref id="orphaning">.
+ <item>
+Send an email about how you are leaving the project to
+&email-debian-private;.
+ <item>
+Notify the Debian key ring maintainers that you are leaving by
+emailing to &email-debian-keyring;.
+ </enumlist>