write down a deprecation timeline

two years seems like it should be enough, especially given the
bootstrap-across-versions-with-migrate trick.

I moved this into contributing so it would be next to the migrations bit.

Signed-off-by: Tycho Andersen <tycho@tycho.pizza>

docs/manual/contributing.rst

@@ -176,7 +176,7 @@ a user's config. Examples include renaming classes, methods, arguments and movin
 class definitions.
 
 Where these changes are made, it is strongly encouraged to support the old syntax where possible
-and warn the user about the deprecations. 
+and warn the user about the deprecations.
 
 Whether or not a deprecation warning is provided, a migration script should be provided that will
 modify the user's config when they run ``qtile migrate``.
@@ -188,4 +188,15 @@ Click here for detailed instructions on :doc:`how-to-migrate`.
     :hidden:
 
     how-to-migrate
-
+
+Deprecation Policy
+------------------
+
+Interfaces that have been deprecated for at least two years after the first
+release containing the deprecation notice can be deleted. Since all new
+breaking changes should have a migration, users can use ``qtile migrate`` to
+bootstrap across versions when migrations are deleted if necessary.
+
+Deprecated interfaces that do not have a migration (i.e. whose deprecation was
+noted before the migration feature was introduced) are all fair game to be
+deleted, since the migration feature is more than two years old.

docs/manual/hacking.rst

@@ -140,14 +140,6 @@ necessarily have advanced programming knowledge; adapt your message
 accordingly. If it can't make sense to your grandma, it's probably meant to be
 a DEBUG message.
 
-Deprecation policy
-==================
-
-When a widget API is changed, you should deprecate the change using
-``libqtile.widget.base.deprecated`` to warn users, in addition to adding it to
-the appropriate place in the changelog. We will typically remove deprecated
-APIs one tag after they are deprecated.
-
 Using Xephyr
 ============