diff --git a/Maintainers-Agreement.md b/Maintainers-Agreement.md
index 05c3ceb..6c8bd88 100644
--- a/Maintainers-Agreement.md
+++ b/Maintainers-Agreement.md
@@ -31,6 +31,8 @@ If you decide to put upper bounds on your packages in general in strict accordan
 
 * Michael Snoyman: For these kinds of breakages, given the frequency with which they occur and the simplicity of solving them, I believe package maintainers should have 4 days to upload a new version to Hackage.
 
+It is highly recommended for all package maintainers to follow the dependencies of their packages on [Packdeps](http://packdeps.haskellers.com/). The site provides RSS feeds to simplify this process.
+
 ## Broken packages/broken tests
 
 It's bound to happen that broken packages will be uploaded to Hackage. In my experience, the most common situation is that a new version works for the developer on his/her OS/GHC version combination, but fails on other systems. Stackage is a great way to discover such a breakage.
@@ -44,8 +46,20 @@ When Stackage reports such a breakage, I see the following possible resolutions
 
 * Michael Snoyman: My recommendation would be that we give the maintainer 24 hours to respond to the failure report. If there's no response in 24 hours, we put in a temporary version constraint. If this version constraint begins to cause problems for other packages in Stackage, and the maintainer is still non-responsive, we drop the package.
 
+If a package's test suite is failing, the first job is to investigate why. If this is due to a bad interaction with versions of other packages in Stackage, then it is the responsibility of the maintainer to fix the test suite. In some situations, it is acceptable to simply not run the test suite.
+
+One example is that, at the time of writing, the HTTP package test suite is not run. This is because the version of HTTP included with the Haskell Platform requires an older version of Warp. Since we cannot upgrade HTTP without breaking Haskell Platform compliance, we are required to simply omit the test suite.
+
 ## Major breaking changes
 
+Many times, when a new major version of a library is released, the resulting breakage is trivial to address. Some examples of this were the transformers 0.2 to 0.3 migration, or text 0.10 to 0.11.
+
+* Michael Snoyman: In such cases, I believe maintainers should be given a one week grace period to update their packages, during which time the dependency is given an upper bound.
+
+Other times, breakage is much more significant. Obviously, the distinction between these two cases in entirely subjective, and must be left in the hands of the Stackage organizers.
+
+* Michael Snoyman: In the major breaking changes case, I believe a period of one month should be given for upgrades.
+
 ## Automation
 
 Ultimately, I hope we have automated build machines and a centralized server to grab build reports. Until then, Stackage will work much more informally.
\ No newline at end of file