-Under certain circumstances it is necessary for someone other than the official
-package maintainer to make a release of a package. This is called a
-non-maintainer upload, or NMU.
-</para>
-<para>
-This section handles only source NMUs, i.e. NMUs which upload a new version of
-the package. For binary-only NMUs by porters or QA members, please see <xref
-linkend="binary-only-nmu"/> . If a buildd builds and uploads a package, that
-too is strictly speaking a binary NMU. See <xref linkend="buildd"/> for some
-more information.
-</para>
-<para>
-The main reason why NMUs are done is when a developer needs to fix another
-developer's package in order to address serious problems or crippling bugs or
-when the package maintainer is unable to release a fix in a timely fashion.
-</para>
-<para>
-First and foremost, it is critical that NMU patches to source should be as
-non-disruptive as possible. Do not do housekeeping tasks, do not change the
-name of modules or files, do not move directories; in general, do not fix
-things which are not broken. Keep the patch as small as possible. If things
-bother you aesthetically, talk to the Debian maintainer, talk to the upstream
-maintainer, or submit a bug. However, aesthetic changes must
-<emphasis>not</emphasis> be made in a non-maintainer upload.
-</para>
-<para>
-And please remember the Hippocratic Oath: Above all, do no harm. It is better
-to leave a package with an open grave bug than applying a non-functional patch,
-or one that hides the bug instead of resolving it.
+Every package has one or more maintainers. Normally, these are the people who
+work on and upload new versions of the package. In some situations, it is
+useful that other developers can upload a new version as well, for example if
+they want to fix a bug in a package they don't maintain, when the maintainer
+needs help to respond to issues. Such uploads are called
+<emphasis>Non-Maintainer Uploads (NMU)</emphasis>.