[ghc-steering-committee] Haddock

[Richard Eisenberg]

Hi committee,

With a steady level of activity adding new features to GHC, I fear we may be forgetting one important downstream client: Haddock. For a nice example of how our decisions can cause trouble, see https://github.com/goldfirere/singletons/issues/466#issuecomment-646117067. Despite appearing on the singletons bug tracker, that comment is all about Haddock support for https://github.com/ghc-proposals/ghc-proposals/blob/3dfec03b11e8829d7febbb7290c3183f752466d7/proposals/0054-kind-signatures.rst, the -XStandaloneKindSignatures extension.

This makes me wonder: should we invite a maintainer of Haddock to be an ex-officio (and voting) member of the committee? This would have two salutary effects:
- It would force us to consider an important aspect of the user experience -- reading documentation -- of newly proposed features.
- It would force us to give Haddock a heads-up about new features they may want to incorporate.

If we don't think we need an ex-officio committee member, then perhaps we should instead require future proposals to describe a plausible impact on Haddock. I say "plausible impact" to suggest that the proposal text would not be binding on Haddock (which would be awfully dictatorial of us), but that it gives Haddock a starting place to consider their own design, while forcing proposers to think about this important-but-easily-neglected aspect of language evolution.

What do we think?

Richard