[ghc-steering-committee] committee constitution

Wed Jun 24 11:40:44 UTC 2020

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 <rae at richarde.dev>:

> 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 <marlowsd at gmail.com> 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 <rae at richarde.dev> 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 <iavor.diatchki at gmail.com>
>> 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 <cgibbard at 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 <ghc-steering-committee at 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 <
>>> ghc-steering-committee-bounces at haskell.org>
>>> > |  On Behalf Of Richard Eisenberg
>>> > |  Sent: 18 June 2020 22:29
>>> > |  To: ghc-steering-committee <ghc-steering-committee at 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-
>>> > |  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 at haskell.org
>>> > |
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> > _______________________________________________
>>> > ghc-steering-committee mailing list
>>> > ghc-steering-committee at haskell.org
>>> >
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200624/2682f8cd/attachment.html>