+<section id="help-release">
+<title>Work towards the next stable release</title>
+<para>
+Providing high-quality packages in unstable is not enough, most users will
+only benefit from your packages when they are released as part of the next
+stable release. You are thus expected to collaborate with the release team
+to ensure your packages get included.
+</para>
+<para>
+More concretely, you should monitor whether your packages are migrating
+to testing (see <xref linkend="testing"/>). When the migration doesn't happen
+after the test period, you should analyze why and work towards fixing this.
+It might mean fixing your package (in the case of release-critical bugs or
+failures to build on some architecture) but it can also mean updating (or
+fixing, or removing from testing) other packages to help complete a
+transition in which your package is entangled due to its dependencies. The
+release team might provide you some input on the current blockers of a
+given transition if you are not able to identify them.
+</para>
+</section>
+
+<section id="maintain-stable">
+<title>Maintain packages in stable</title>
+<para>
+Most of the package maintainer's work goes into providing updated
+versions of packages in unstable, but his job also entails taking care
+of the packages in the current stable release.
+</para>
+<para>
+While changes in stable are discouraged, they are possible. Whenever a
+security problem is reported, you should collaborate with the security
+team to provide a fixed version (see <xref linkend="bug-security"/>). When
+bugs of severity important (or more) are reported against the stable
+version of your packages, you should consider providing a targeted fix.
+You can ask the stable release team whether they would accept such an
+update and then prepare a stable upload (see <xref
+linkend="upload-stable"/>).
+</para>
+</section>
+