started a new chapter about the relationship between old and new developers

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

diff --git a/common.ent b/common.ent
index 8fce1c854617664486ca3cde2f4eeb80b60e2d83..ee43aff9713fe677a58c7ac6bf8a755edc16ebcc 100644 (file)
--- a/common.ent
+++ b/common.ent
@@ -52,6 +52,8 @@
 <!entity url-newmaint "http://&www-debian-org;/devel/join/newmaint">
 <!entity url-newmaint-checklist "http://&www-debian-org;/devel/join/nm-checklist">
 <!entity url-newmaint-db "http://nm.debian.org/">
+<!entity url-newmaint-advocate "http://&www-debian-org;/devel/join/nm-advocate">
+<!entity url-newmaint-amchecklist "http://&www-debian-org;/devel/join/nm-amchecklist">
 
 <!entity url-debian-keyring "ftp://&ftp-debian-org;/debian/doc/debian-keyring.tar.gz">
 <!entity url-readme-non-us "ftp://&ftp-debian-org;/debian/README.non-US">

diff --git a/developers-reference.sgml b/developers-reference.sgml
index a70f475adff0942cd7df80b0bfd0e3a8263292d9..45dcc2202c0d0a02c85e21d855065e4d4a101ce8 100644 (file)
--- a/developers-reference.sgml
+++ b/developers-reference.sgml
@@ -5,7 +5,7 @@
   <!-- common, language independant entities -->
   <!entity % commondata  SYSTEM "common.ent" > %commondata;
   <!-- CVS revision of this document -->
-  <!entity cvs-rev "$Revision: 1.59 $">
+  <!entity cvs-rev "$Revision: 1.60 $">
 
   <!-- if you are translating this document, please notate the RCS
        revision of the developers reference here -->
@@ -1834,7 +1834,6 @@ right away.
 
 
 
-
     <chapt id="bug-handling">Handling Bugs
 
       <sect>Monitoring bugs
@@ -1959,6 +1958,41 @@ that the bug report is not forwarded to the bug distribution mailing
 list.
 
 
+    <chapt id="newmaint">
+      <heading>Interaction with prospective developers</heading>
+
+      <p>
+This chapter describes procedures that existing Debian developers should
+follow when it comes to dealing with wannabe developers.
+
+      <sect>Sponsoring packages
+       <p>
+Sponsoring a package means uploading a package for a maintainer who is not
+able to do it on their own, a new maintainer applicant. Sponsoring a package
+also means accepting responsibility for it.
+       <p>
+New maintainers usually have certain difficulties creating Debian packages
+-- this is quite understandable. That is why the sponsor is there, to check
+the package and verify that it is good enough for inclusion in Debian.
+(Note that if the sponsored package is new, the FTP admins will also have to
+inspect it before letting it in.)
+       <p>
+If you are an application manager for a prospective developer, you can also
+be their sponsor. That way you can also verify the how the applicant is
+handling the `Tasks and Skills' part of their application.
+
+      <sect>Advocating new developers
+       <p>
+See the page about <url id="&url-newmaint-advocate;"
+name="advocating a prospective developer"> at the Debian web site.
+
+      <sect>Handling new maintainer applications
+       <p>
+Please see <url id="&url-newmaint-amchecklist;" name="Checklist for
+Application Managers"> at the Debian web site.
+
+
+
     <chapt id="tools">Overview of Debian Maintainer Tools
       <p>
 This section contains a rough overview of the tools available to