<div dir="ltr">Hello,<div><br></div><div>I think having a committee member who's involved with `haddock` makes sense, as `haddock` really is very tightly coupled with GHC. This, of course, presumes that Simon M is not actively involved with `haddock` anymore, otherwise we already have a representative.</div><div><br></div><div>More generally, I think it is good if there is some overlap between various communities/organizations/projects, as it makes dissemination of information much smoother, and knowing what's happening in "the community", well, makes the community.</div><div><br></div><div>I would recommend reaching out to Alec Theriault (`harpocrates` on git-hub). I've worked with him in the past and he is very smart and thoughtful. I have not spoken to him, so I am not sure if he'd be up for taking up the position, but if we do decide to invite Alec, I'd be happy to reach out and ask him.</div><div><br></div><div>-Iavor</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 19, 2020 at 9:01 AM Cale Gibbard <<a href="mailto:cgibbard@gmail.com">cgibbard@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In addition to this, it seems like the situation involving the<br>
relationship between commits on haddock and commits on GHC is<br>
currently somewhat unsatisfactory. In order to build an arbitrary<br>
commit on haddock, you need to know which commit of GHC to use to<br>
build it, but instead, the commits of GHC have a pointer to the<br>
haddock repo, rather than the other way around. I remember being<br>
surprised that the git submodule relationship wasn't at least in the<br>
opposite direction.<br>
<br>
I think it would make a fair amount of sense just to regard haddock as<br>
being a full-fledged part of GHC and perhaps just unify the<br>
repositories, since it's so intimately connected to GHC's internals<br>
anyway, but I might be unaware of other constraints on its development<br>
process.<br>
<br>
<br>
On Fri, 19 Jun 2020 at 11:35, Simon Peyton Jones via<br>
ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>> wrote:<br>
><br>
> Good thought. Personally, I'd be happy to have a Haddock maintainer on the committee;<br>
> but I'd like them to be a full member, contributing to the discussion and shepherding proposals -- not merely acting as the Haddock liaison.<br>
><br>
> Simon<br>
><br>
> | -----Original Message-----<br>
> | From: ghc-steering-committee <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank">ghc-steering-committee-bounces@haskell.org</a>><br>
> | On Behalf Of Richard Eisenberg<br>
> | Sent: 18 June 2020 22:29<br>
> | To: ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>><br>
> | Subject: [ghc-steering-committee] Haddock<br>
> |<br>
> | Hi committee,<br>
> |<br>
> | With a steady level of activity adding new features to GHC, I fear we may<br>
> | be forgetting one important downstream client: Haddock. For a nice<br>
> | example of how our decisions can cause trouble, see<br>
> | <a href="https://github.com/goldfirere/singletons/issues/466#issuecomment-" rel="noreferrer" target="_blank">https://github.com/goldfirere/singletons/issues/466#issuecomment-</a><br>
> | 646117067. Despite appearing on the singletons bug tracker, that comment<br>
> | is all about Haddock support for <a href="https://github.com/ghc-proposals/ghc-" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-</a><br>
> | proposals/blob/3dfec03b11e8829d7febbb7290c3183f752466d7/proposals/0054-<br>
> | kind-signatures.rst, the -XStandaloneKindSignatures extension.<br>
> |<br>
> | This makes me wonder: should we invite a maintainer of Haddock to be an<br>
> | ex-officio (and voting) member of the committee? This would have two<br>
> | salutary effects:<br>
> | - It would force us to consider an important aspect of the user<br>
> | experience -- reading documentation -- of newly proposed features.<br>
> | - It would force us to give Haddock a heads-up about new features they<br>
> | may want to incorporate.<br>
> |<br>
> | If we don't think we need an ex-officio committee member, then perhaps we<br>
> | should instead require future proposals to describe a plausible impact on<br>
> | Haddock. I say "plausible impact" to suggest that the proposal text would<br>
> | not be binding on Haddock (which would be awfully dictatorial of us), but<br>
> | that it gives Haddock a starting place to consider their own design,<br>
> | while forcing proposers to think about this important-but-easily-<br>
> | neglected aspect of language evolution.<br>
> |<br>
> | What do we think?<br>
> |<br>
> | Richard<br>
> | _______________________________________________<br>
> | ghc-steering-committee mailing list<br>
> | <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> | <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> _______________________________________________<br>
> ghc-steering-committee mailing list<br>
> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>