Address PR feedback

Author: japgolly

CONTRIBUTING.md

@@ -15,14 +15,10 @@ Contents:
 Packages
 ========
 
-TODO: Put `beacon` in `dom`
+TODO: Pending discussion in #545
+
 TODO: Put DOMParser in `dom` with its extra types in its companion object
-TODO: Put `gamepad` in `dom`
-TODO: Put `push` in `dom`? Everything is `Push*`. Or will there be `Push*` from other APIs too? Do we care?
-TODO: Put `sharedworkers` in `dom`
-TODO: Put `storage` in `dom`? Does it really warrant its own package?
 TODO: Put `webgl/extensions` in `webgl`
-TODO: The `ext` package is named confusingly imo. Ideally we could rename it to something clearer.
 
 ```
 org.scalajs.dom          — All top-level facades
@@ -60,6 +56,8 @@ Facades
 =======
 
 If a feature has many types that don't share a common unambiguous prefix (like `crypto`),
+  * firstly, please raise an issue to discuss so that you don't do work only to be asked to undo it
+    during PR review
   * create a feature package
   * put all of its types in its package
 
@@ -81,8 +79,9 @@ Non-Facades
 * Add Scala-only utilities that pertain to a specific facade, in the facades companion object
   Eg: helper constructors, legal facade values.
 
-* Add Scala-only utilities that don't pertain to a specific facade, or shouldn't be universally
-  available (subjective judgement here) in the `ext` package.
+* We currently don't see the need for Scala-only utilities that don't pertain to a specific facade,
+  or shouldn't be universally available (subjective judgement here).
+  If you believe you've got a compelling use case please raise an issue first to discuss.
 
 
 Partially-Supported DOM API
@@ -94,7 +93,7 @@ TODO: Pending discussion in #514
 Binary Compatibility
 ====================
 
-Binary compatibility for Scala.JS facades is different than standard Scala.
+Binary compatibility for Scala.js facades is different than standard Scala.
 The following are changes that are indeed incompatible in both formats:
 
 Don't:
@@ -117,8 +116,16 @@ Submitting a PR
 Once you're done making your changes...
 
 1. Run `sbt prePR`
+
 2. Run `git diff api-reports` and ensure that you aren't breaking backwards-binary-compatibility
-   (see above). We'll probably automate this step in the future (See #503)
+   (see above). The api reports are auto-generated by `prePR` and provide a concise summary of the
+   entire API. Make sure to look at the top of the file for a description of format.
+
+   Note: We might automate binary-compatibility checking in the future (See #503) but for now,
+   it's just a helpful tool for reviewing PRs.
+
 3. Check in and commit the changes to `api-reports`
+
 4. Submit your PR
+
 5. Know that your contribution is appreciated, thank you!