In addition to this, it seems like the situation involving the relationship between commits on haddock and commits on GHC is currently somewhat unsatisfactory. In order to build an arbitrary commit on haddock, you need to know which commit of GHC to use to build it, but instead, the commits of GHC have a pointer to the haddock repo, rather than the other way around. I remember being surprised that the git submodule relationship wasn't at least in the opposite direction. I think it would make a fair amount of sense just to regard haddock as being a full-fledged part of GHC and perhaps just unify the repositories, since it's so intimately connected to GHC's internals anyway, but I might be unaware of other constraints on its development process. On Fri, 19 Jun 2020 at 11:35, Simon Peyton Jones via ghc-steering-committee wrote:

Good thought. Personally, I'd be happy to have a Haddock maintainer on the committee; but I'd like them to be a full member, contributing to the discussion and shepherding proposals -- not merely acting as the Haddock liaison.

Simon

| -----Original Message----- | From: ghc-steering-committee | On Behalf Of Richard Eisenberg | Sent: 18 June 2020 22:29 | To: ghc-steering-committee | Subject: [ghc-steering-committee] Haddock | | 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 | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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. 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. GHC developer (2x) Educator Industry practitioner (2x) Haddock developer Researcher IDE tooling developer GHC fork developer (maybe) 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. One individual can fill multiple constituency needs, and overrepresentation is fine. So, I ask two separate questions: 1. Should we have such a list? 2. If yes, what do we think of this list, in particular? 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 https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst and consult it when making future committee appointments. Thanks, Richard

On Jun 19, 2020, at 5:50 PM, Iavor Diatchki wrote:

Hello,

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.

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.

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.

-Iavor

On Fri, Jun 19, 2020 at 9:01 AM Cale Gibbard mailto:cgibbard@gmail.com> wrote: In addition to this, it seems like the situation involving the relationship between commits on haddock and commits on GHC is currently somewhat unsatisfactory. In order to build an arbitrary commit on haddock, you need to know which commit of GHC to use to build it, but instead, the commits of GHC have a pointer to the haddock repo, rather than the other way around. I remember being surprised that the git submodule relationship wasn't at least in the opposite direction.

I think it would make a fair amount of sense just to regard haddock as being a full-fledged part of GHC and perhaps just unify the repositories, since it's so intimately connected to GHC's internals anyway, but I might be unaware of other constraints on its development process.

On Fri, 19 Jun 2020 at 11:35, Simon Peyton Jones via ghc-steering-committee mailto:ghc-steering-committee@haskell.org> wrote:

...

Good thought. Personally, I'd be happy to have a Haddock maintainer on the committee; but I'd like them to be a full member, contributing to the discussion and shepherding proposals -- not merely acting as the Haddock liaison.

Simon

| -----Original Message----- | From: ghc-steering-committee mailto:ghc-steering-committee-bounces@haskell.org> | On Behalf Of Richard Eisenberg | Sent: 18 June 2020 22:29 | To: ghc-steering-committee mailto:ghc-steering-committee@haskell.org> | Subject: [ghc-steering-committee] Haddock | | 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- 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- 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 | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, I have an issue regarding the proposed list of constituencies: GHC developer (2x) Educator Industry practitioner (2x) Haddock developer Researcher IDE tooling developer GHC fork developer (maybe) We have the following positions for developers working on something closely related to GHC: Haddock developer IDE tooling developer GHC fork developer (or GHC API client, as Simon suggests) What about cabal/stack? They both are closely related to GHC. No Backpack support in stack makes the former a bit esoteric *language* feature, for one example of such a relation. I don't think there is any difference between IDE tooling or cabal/stack developers regarding their membership in the Committee. Shouldn't we try to incorporate them either? What about another tooling? Linters, code formatters, independent parsers? Aren't there too many such developer categories? How are we (or who?) supposed to choose between them? In fact, I'd prefer temporary per proposal membership instead when a shepherd invites someone to discuss and decide on the particular proposal. Maybe we could have two or three unassigned "tooling developer" positions for such cases. Vitaly пн, 22 июн. 2020 г. в 15:34, Simon Peyton Jones via ghc-steering-committee :

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”.

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.

Yes the list should be on our main home page.

Simon

From: ghc-steering-committee On Behalf Of Richard Eisenberg Sent: 22 June 2020 12:04 To: Iavor Diatchki Cc: ghc-steering-committee Subject: [ghc-steering-committee] committee constitution

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.

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.

GHC developer (2x)

Educator

Industry practitioner (2x)

Haddock developer

Researcher

IDE tooling developer

GHC fork developer (maybe)

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.

One individual can fill multiple constituency needs, and overrepresentation is fine.

So, I ask two separate questions:

1. Should we have such a list?

2. If yes, what do we think of this list, in particular?

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 https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst and consult it when making future committee appointments.

Thanks,

Richard

On Jun 19, 2020, at 5:50 PM, Iavor Diatchki wrote:

Hello,

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.

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.

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.

-Iavor

On Fri, Jun 19, 2020 at 9:01 AM Cale Gibbard wrote:

In addition to this, it seems like the situation involving the relationship between commits on haddock and commits on GHC is currently somewhat unsatisfactory. In order to build an arbitrary commit on haddock, you need to know which commit of GHC to use to build it, but instead, the commits of GHC have a pointer to the haddock repo, rather than the other way around. I remember being surprised that the git submodule relationship wasn't at least in the opposite direction.

I think it would make a fair amount of sense just to regard haddock as being a full-fledged part of GHC and perhaps just unify the repositories, since it's so intimately connected to GHC's internals anyway, but I might be unaware of other constraints on its development process.

On Fri, 19 Jun 2020 at 11:35, Simon Peyton Jones via ghc-steering-committee wrote:

...

Good thought. Personally, I'd be happy to have a Haddock maintainer on the committee; but I'd like them to be a full member, contributing to the discussion and shepherding proposals -- not merely acting as the Haddock liaison.

Simon

| -----Original Message----- | From: ghc-steering-committee | On Behalf Of Richard Eisenberg | Sent: 18 June 2020 22:29 | To: ghc-steering-committee | Subject: [ghc-steering-committee] Haddock | | 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 | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I was Feeling Lucky so I tried digging for the original list, and found it immediately! It was in private email so I won't paste the whole thing, but the list was | 1. GHC developer (e.g. someone named Simon, or similar) | 2. GHC maintainer (e.g. Austin or Ben) | 3. Author (e.g. Chris Allen, Alejandro Serrano Mena, etc) | 4. Teacher (someone who has recently or will soon teach Haskell in a | classroom setting) | 5-6. Industrial users | 7. Researcher (someone who uses the Haskell language as a research | vehicle) | 8-9. Members-at-large On Mon, 22 Jun 2020 at 12:04, Richard Eisenberg wrote:

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.

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.

GHC developer (2x) Educator Industry practitioner (2x) Haddock developer Researcher IDE tooling developer GHC fork developer (maybe)

I find Haddock developer a slightly odd choice. It's also a very small pool of people! Is the motivation due to the tight coupling? Alternatively we can try to ensure we're consulting stakeholders as appropriate, but we don't necessarily need representation on the committee. This also applies where changes touch core libraries too - we would want to consult with the core libraries committee to ensure alignment. Do we think that research is less important than industrial use? (this 2-1 ratio was also in the original list, but I don't recall if we discussed it). Cheers Simon 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.

One individual can fill multiple constituency needs, and overrepresentation is fine.

So, I ask two separate questions:

1. Should we have such a list?

2. If yes, what do we think of this list, in particular?

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 https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst and consult it when making future committee appointments.

Thanks, Richard

On Jun 19, 2020, at 5:50 PM, Iavor Diatchki wrote:

Hello,

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.

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.

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.

-Iavor

On Fri, Jun 19, 2020 at 9:01 AM Cale Gibbard wrote:

...

In addition to this, it seems like the situation involving the relationship between commits on haddock and commits on GHC is currently somewhat unsatisfactory. In order to build an arbitrary commit on haddock, you need to know which commit of GHC to use to build it, but instead, the commits of GHC have a pointer to the haddock repo, rather than the other way around. I remember being surprised that the git submodule relationship wasn't at least in the opposite direction.

I think it would make a fair amount of sense just to regard haddock as being a full-fledged part of GHC and perhaps just unify the repositories, since it's so intimately connected to GHC's internals anyway, but I might be unaware of other constraints on its development process.

On Fri, 19 Jun 2020 at 11:35, Simon Peyton Jones via ghc-steering-committee wrote:

...

Good thought. Personally, I'd be happy to have a Haddock maintainer on

...

but I'd like them to be a full member, contributing to the discussion and shepherding proposals -- not merely acting as the Haddock liaison.

Simon

| -----Original Message----- | From: ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> | On Behalf Of Richard Eisenberg | Sent: 18 June 2020 22:29 | To: ghc-steering-committee | Subject: [ghc-steering-committee] Haddock | | 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- |

...

| 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

...

| may want to incorporate. | | If we don't think we need an ex-officio committee member, then

the committee; proposals/blob/3dfec03b11e8829d7febbb7290c3183f752466d7/proposals/0054- they 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 | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I prefer A+B because I think it's too hard to come up with a reasonable list including all the categories. Though having such a list with bigger categories is definitely helpful. Vitaly ср, 24 июн. 2020 г. в 13:58, Richard Eisenberg :

An interesting viewpoint arose in this thread that I'd like to highlight: instead of representing all these interests on the committee, we could have shepherds consider external reviewers, who are invited to review individual proposals. Beyond that, there have been ideas shared about what, precisely, the list should be. I want to defer that discussion until we agree that we should even have a list. So I pose a question:

How should we ensure that various constituencies are well served by our process?

A. By having shepherds reach out to community members external to the committee who can share their expert opinion B. By maintaining a list of constituencies that the committee membership covers (ideally)

These can be combined, or we could do neither. (Right now, we do neither.) Please respond answering whether you'd prefer A alone, B alone, A + B, or neither.

I prefer B alone. I think A is fine, but it should be hopefully rare enough that we don't need to bake it into our process. And I'd prefer to have the constituencies represented in such a way that the representative sees a range of proposals, not just a few that narrowly affect some group of people.

If we decide to include B in the end, I'll create a Google Doc where we can collaboratively compose the list.

Thanks, Richard

On Jun 23, 2020, at 3:13 PM, Simon Marlow wrote:

I was Feeling Lucky so I tried digging for the original list, and found it immediately! It was in private email so I won't paste the whole thing, but the list was

| 1. GHC developer (e.g. someone named Simon, or similar) | 2. GHC maintainer (e.g. Austin or Ben) | 3. Author (e.g. Chris Allen, Alejandro Serrano Mena, etc) | 4. Teacher (someone who has recently or will soon teach Haskell in a | classroom setting) | 5-6. Industrial users | 7. Researcher (someone who uses the Haskell language as a research | vehicle) | 8-9. Members-at-large

On Mon, 22 Jun 2020 at 12:04, Richard Eisenberg wrote:

...

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.

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.

GHC developer (2x) Educator Industry practitioner (2x) Haddock developer Researcher IDE tooling developer GHC fork developer (maybe)

I find Haddock developer a slightly odd choice. It's also a very small pool of people! Is the motivation due to the tight coupling? Alternatively we can try to ensure we're consulting stakeholders as appropriate, but we don't necessarily need representation on the committee. This also applies where changes touch core libraries too - we would want to consult with the core libraries committee to ensure alignment.

Do we think that research is less important than industrial use? (this 2-1 ratio was also in the original list, but I don't recall if we discussed it).

Cheers Simon

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.

One individual can fill multiple constituency needs, and overrepresentation is fine.

So, I ask two separate questions:

1. Should we have such a list?

2. If yes, what do we think of this list, in particular?

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 https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst and consult it when making future committee appointments.

Thanks, Richard

On Jun 19, 2020, at 5:50 PM, Iavor Diatchki wrote:

Hello,

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.

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.

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.

-Iavor

On Fri, Jun 19, 2020 at 9:01 AM Cale Gibbard wrote:

...

In addition to this, it seems like the situation involving the relationship between commits on haddock and commits on GHC is currently somewhat unsatisfactory. In order to build an arbitrary commit on haddock, you need to know which commit of GHC to use to build it, but instead, the commits of GHC have a pointer to the haddock repo, rather than the other way around. I remember being surprised that the git submodule relationship wasn't at least in the opposite direction.

I think it would make a fair amount of sense just to regard haddock as being a full-fledged part of GHC and perhaps just unify the repositories, since it's so intimately connected to GHC's internals anyway, but I might be unaware of other constraints on its development process.

On Fri, 19 Jun 2020 at 11:35, Simon Peyton Jones via ghc-steering-committee wrote:

...

Good thought. Personally, I'd be happy to have a Haddock maintainer on

...

but I'd like them to be a full member, contributing to the discussion and shepherding proposals -- not merely acting as the Haddock liaison.

Simon

| -----Original Message----- | From: ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> | On Behalf Of Richard Eisenberg | Sent: 18 June 2020 22:29 | To: ghc-steering-committee | Subject: [ghc-steering-committee] Haddock | | 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- |

...

| 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

...

| may want to incorporate. | | If we don't think we need an ex-officio committee member, then

the committee; proposals/blob/3dfec03b11e8829d7febbb7290c3183f752466d7/proposals/0054- they 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 | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I am not really keen on putting these labels on folks, so my preference would be to not bake this into the process. I am also not sure what problem we are solving though. Iavor On Wed, Jun 24, 2020, 04:58 Joachim Breitner wrote:

Hi,

Am Mittwoch, den 24.06.2020, 11:57 +0100 schrieb Richard Eisenberg:

...

A. By having shepherds reach out to community members external to the committee who can share their expert opinion B. By maintaining a list of constituencies that the committee membership covers (ideally)

These can be combined, or we could do neither. (Right now, we do neither.)

I think we have sometimes used A. For example with the proposal about Arrow something, we (or the author?) reached out the likely affected library authors.

I am slightly favoring A (less formal, less process overhead, maybe more flexible).

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

El lun., 13 jul. 2020 a las 13:58, Richard Eisenberg () escribió:

To summarize where we are in this thread:

I asked:

How should we ensure that various constituencies are well served by our process?

A. By having shepherds reach out to community members external to the committee who can share their expert opinion B. By maintaining a list of constituencies that the committee membership covers (ideally)

I said B Vitaly said A+B Joachim said A Iavor said neither

Do others have opinions?

I lean towards A, but of course not having to see external members and have all stakeholders in the Committee would be great too. Alejandro