Make clear .Internal convention does not adhere to the spec (#53)

* Make clear .Internal convention does not adhere to the spec

* Improve "not permitted" wording

Co-authored-by: ˌbodʲɪˈɡrʲim <[email protected]>

* Fix spelling

Co-authored-by: ˌbodʲɪˈɡrʲim <[email protected]>

---------

Co-authored-by: ˌbodʲɪˈɡrʲim <[email protected]>

Author: hasufell

pvp-faq.md

@@ -311,3 +311,26 @@ conditionally, as you'd need to have access to the `Generic` class and
 be able to define instances for it in the first place, before being
 able to make use of (and thus observe) the default implementation of
 `rnf`.
+
+## Internal modules
+
+There are various common practices of exempting some modules from PVP.
+E.g.:
+
+* Mentioning in the documentation that the module is not under PVP
+* Naming module with prefix/infix/suffix component `Internal`
+* Combination of the two above
+
+PVP does not endorse or recognise such practices.
+All exposed modules are subject to the uniform versioning policy.
+
+The `Internal` modules are useful to export internals of a library, like
+in `Data.Text.Internal` in [text](https://hackage.haskell.org/package/text),
+however these are expected to follow versioning policy as any other modules
+(and `Data.Text.Internal` does).
+
+If author desires to keep library version churn to a minimum, yet be able
+to change internals freely, then they are advised to create a separate
+package for the internal API. That approach is outlined in
+[Nikita Volvov's blog post "Internal convention is a mistake"](http://nikita-volkov.github.io/internal-convention-is-a-mistake/).
+