<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">I agree with making a list of constituencies. We could also list which constituencies we think the current membership reflects. This gives a way for self-nominations to say “I fill a gap”.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">I’m not so keen on “GHC fork dev” and more keen on “GHC API client”, including plugins. That overlaps with IDE tooling, but is not subsumed by IDE.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Yes the list should be on our main home page.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Simon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> ghc-steering-committee <ghc-steering-committee-bounces@haskell.org>
<b>On Behalf Of </b>Richard Eisenberg<br>
<b>Sent:</b> 22 June 2020 12:04<br>
<b>To:</b> Iavor Diatchki <iavor.diatchki@gmail.com><br>
<b>Cc:</b> ghc-steering-committee <ghc-steering-committee@haskell.org><br>
<b>Subject:</b> [ghc-steering-committee] committee constitution<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Broadening from my thoughts on having a Haddock representative, I wonder if we should aim to have a "balanced" committee. I seem to recall (but can't find evidence of, after ~5 minutes of searching) that we started this steering committee
with the aim of representing various different interests. We even had, somewhere, I believe, a list of different constituencies we wished to include. When we have considered this kind of diversity when selecting new members, we've also generally worked with
whatever nominations we've received, instead of seeking out particular people. I'd like to propose that we reify a set of constituencies that we aim to always represent. When someone retires from the committee, we would then both seek nominations and think
creatively about folks to invite from the constituency(ies) that are being left vacant by the retirement.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Here is an initial proposed list of constituencies. If there is a "2x", it means we should have at least two steering committee members from that constituency.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">GHC developer (2x)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Educator<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Industry practitioner (2x)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Haddock developer<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Researcher<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">IDE tooling developer<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">GHC fork developer (maybe)<o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On GHC port developer: there seem to be a growing number of GHC forks, and it might be nice to incorporate someone in that position into our committee. Examples: GHCJS, Asterius, DAML.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">One individual can fill multiple constituency needs, and overrepresentation is fine.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So, I ask two separate questions:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">1. Should we have such a list?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">2. If yes, what do we think of this list, in particular?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It would be great to hear from everyone on the committee on this point. If we answer "yes" to (1), I would expect us to add the list to <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst">https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst</a>
and consult it when making future committee appointments.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Richard<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Jun 19, 2020, at 5:50 PM, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com">iavor.diatchki@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Hello,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-Iavor<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Jun 19, 2020 at 9:01 AM Cale Gibbard <<a href="mailto:cgibbard@gmail.com">cgibbard@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal">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-" 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-" 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" 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" 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" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal">_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>