I agree with Simon’s point about self-nominations; otherwise, I like Joachim’s proposal. Manuel

Am 09.07.2018 um 10:34 schrieb Simon Peyton Jones via ghc-steering-committee :

Ryan Newton has expressed interest in being rotated out of the committee. I spoke to the Simons, and they indicate we should ask for public nominations. Here is a draft of a mail I’d send to the usual mailing lists. Please comment.

Good draft. I support “conservative”. I have made some suggesting drafting amendments (highlighted) below.

I think nominations of someone else are ok, provided said person has explicitly consented. It’s affirming to be nominated, but it erodes that affirmation if the person doing the encouraging has to say “but you have to nominate yourself”.

Simon

========================== Dear community,

the GHC Steering committee is seeking nomination for a new member, and ask for self-nominations.

The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC Our processes are described in the README in https://github.com/ghc-proposals/ghc-proposals https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals&data=02%7C01%7Csimonpj%40microsoft.com%7Ccac1713fd9614f04d17d08d5e56cdc25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667178065249408&sdata=X5dfzCxNJiKmvPkYrIEBTy4UZgCCmtiBJEXBsK21tVo%3D&reserved=0 which is also the GitHub repository where proposals are proposed.

We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * make constructive comments and improvements, * judge the cost/benefit ratio and * finally come to a justifiable conclusion.

We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features * have made active contributions to the Haskell community, for some time * have expertise in language design and implementation, in either Haskell or related language, which they can share with us.

The GHC developers themselves are already well represented already. We seek Haskell users more than GHC hackers.

The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. Please keep that in mind if your email inbox is already overflowing.

There is no shortage of people who are very eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, and (particularly) through its uexpected interaction with other features. We need to strike a balance, one that encourages innovation (as Haskell always has) while still making Haskell attractive for real-world production use. We therefore explicitly invite “conservative” members of the community to join the committee.

To nominate yourself, please send an email to me (as the committee secretary) at mail@joachim-breitner.de mailto:mail@joachim-breitner.de until July 20th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private.

You can nominate others, but you must obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.)

On behalf of the committee, Joachim Breitner ==========================

From: ghc-steering-committee On Behalf Of Simon Marlow Sent: 09 July 2018 08:23 To: Joachim Breitner Cc: ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] Solicitation for a new member

This looks great to me.

On the amount of time required - can we put a ballpark figure on this? Perhaps 2 hours per week on average, more when going in depth into proposals. How much do other people spend? I worry that "small but non-trivial" means different things to different people.

I'm ok with "conservative".

Cheers

Simon

On 7 July 2018 at 15:48, Joachim Breitner mailto:mail@joachim-breitner.de> wrote:

Dear Committee,

Ryan Newton has expressed interest in being rotated out of the committee. I spoke to the Simons, and they indicate we should ask for public nominations. Here is a draft of a mail I’d send to the usual mailing lists. Please comment.

========================== Dear community,

the GHC Steering committee is seeking nomination for a new member, and ask for self-nominations.

The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC Our processes are described in the README in https://github.com/ghc-proposals/ghc-proposals https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals&data=02%7C01%7Csimonpj%40microsoft.com%7Ccac1713fd9614f04d17d08d5e56cdc25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667178065249408&sdata=X5dfzCxNJiKmvPkYrIEBTy4UZgCCmtiBJEXBsK21tVo%3D&reserved=0 which is also the GitHub repository where proposals are proposed.

We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * make constructive comments and improvements, * judge the cost/benefit ratio and * finally come to a justifiable conclusion.

Particular pluses that we look for are * candidates who have been in the community for some time, and/or * who have expertise in language design and implementation in related language, which they can share with us.

The committee work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. Please keep that in mind if your email inbox is already flowing over.

There is no shortage of people who are very eager to get fancy new features into the language, both in the committee and the wider community. I therefore explicitly invite “conservative” members of the community to join the committee.

The GHC developers themselves are nicely represented already. Having hacked on GHC is not a requirement.

To nominate yourself, please send an email to me (as the committee secretary) at mail@joachim-breitner.de mailto:mail@joachim-breitner.de until July 20th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private.

You cannot nominate others. But if you know of anyone else you’d think should be on the committee, please do encourage them, or talk to us and we can encourage them.

On behalf of the committee, Joachim Breitner ==========================

Note worth discussing:

* I see no point in non-self-nominations. We can only have members that want to do this.

* Do we want to encourage “conservative” members? Is that the right wording? (I see the committee a bit as a flood gate that protects against premature and not-worth-it changes. We are doing a good job of that – most of my proposals get rejected ;-) – but I think it would not hurt to explicitly keep it that way.

* One could consider public nominations and deliberations, but I feel that a public discussion of who we think is the “best” is not very nice.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ccac1713fd9614f04d17d08d5e56cdc25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667178065259412&sdata=vab8j7i%2F9tp7QLt4CicceON5iDPoj779PGgH7KBEXpo%3D&reserved=0

_______________________________________________ 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

+1 to Joachim's proposal. Also, I wanted to thank him for handling this and for all his other excellent management of this process. I'm somewhat pulled away from the Haskell space at the moment (working feverishly on a non-Haskell startup company during sabbatical), but I hope to reengage with you all more fully at a future time. Best regards, -Ryan On Mon, Jul 9, 2018 at 8:30 AM Richard Eisenberg wrote:

Should we explicitly ask for responsiveness?

For example, in the desired "properties" bullets, add:

* normally responds to a technical email within 1-2 weeks

And I would agree with the assessment that this takes ~2 hours/week.

Richard

On Jul 9, 2018, at 7:40 AM, Manuel M T Chakravarty wrote:

I agree with Simon’s point about self-nominations; otherwise, I like Joachim’s proposal.

Manuel

Am 09.07.2018 um 10:34 schrieb Simon Peyton Jones via ghc-steering-committee :

Ryan Newton has expressed interest in being rotated out of the committee. I spoke to the Simons, and they indicate we should ask for public nominations. Here is a draft of a mail I’d send to the usual mailing lists. Please comment.

Good draft. I support “conservative”. I have made some suggesting drafting amendments (highlighted) below.

I think nominations of someone else are ok, provided said person has explicitly consented. It’s affirming to be nominated, but it erodes that affirmation if the person doing the encouraging has to say “but you have to nominate yourself”.

Simon

========================== Dear community,

the GHC Steering committee is seeking nomination for a new member, and ask for self-nominations.

The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC Our processes are described in the README in https://github.com/ghc-proposals/ghc-proposals https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals&data=02%7C01%7Csimonpj%40microsoft.com%7Ccac1713fd9614f04d17d08d5e56cdc25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667178065249408&sdata=X5dfzCxNJiKmvPkYrIEBTy4UZgCCmtiBJEXBsK21tVo%3D&reserved=0 which is also the GitHub repository where proposals are proposed.

We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * make constructive comments and improvements, * judge the cost/benefit ratio and * finally come to a justifiable conclusion.

We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features * have made active contributions to the Haskell community, for some time * have expertise in language design and implementation, in either Haskell or related language, which they can share with us.

The GHC developers themselves are already well represented already. We seek Haskell *users* more than GHC hackers.

The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. Please keep that in mind if your email inbox is already overflowing.

There is no shortage of people who are very eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, and (particularly) through its uexpected interaction with other features. We need to strike a balance, one that encourages innovation (as Haskell always has) while still making Haskell attractive for real-world production use. We therefore explicitly invite “conservative” members of the community to join the committee.

To nominate yourself, please send an email to me (as the committee secretary) at mail@joachim-breitner.de until July 20th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private.

You can nominate others, but you must obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.)

On behalf of the committee, Joachim Breitner ==========================

*From:* ghc-steering-committee

...

*On Behalf Of *Simon Marlow *Sent:* 09 July 2018 08:23 *To:* Joachim Breitner *Cc:* ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] Solicitation for a new member

This looks great to me.

On the amount of time required - can we put a ballpark figure on this? Perhaps 2 hours per week on average, more when going in depth into proposals. How much do other people spend? I worry that "small but non-trivial" means different things to different people.

I'm ok with "conservative".

Cheers

Simon

On 7 July 2018 at 15:48, Joachim Breitner wrote:

Dear Committee,

Ryan Newton has expressed interest in being rotated out of the committee. I spoke to the Simons, and they indicate we should ask for public nominations. Here is a draft of a mail I’d send to the usual mailing lists. Please comment.

========================== Dear community,

the GHC Steering committee is seeking nomination for a new member, and ask for self-nominations.

The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC Our processes are described in the README in https://github.com/ghc-proposals/ghc-proposals https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals&data=02%7C01%7Csimonpj%40microsoft.com%7Ccac1713fd9614f04d17d08d5e56cdc25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667178065249408&sdata=X5dfzCxNJiKmvPkYrIEBTy4UZgCCmtiBJEXBsK21tVo%3D&reserved=0 which is also the GitHub repository where proposals are proposed.

We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * make constructive comments and improvements, * judge the cost/benefit ratio and * finally come to a justifiable conclusion.

Particular pluses that we look for are * candidates who have been in the community for some time, and/or * who have expertise in language design and implementation in related language, which they can share with us.

The committee work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. Please keep that in mind if your email inbox is already flowing over.

There is no shortage of people who are very eager to get fancy new features into the language, both in the committee and the wider community. I therefore explicitly invite “conservative” members of the community to join the committee.

The GHC developers themselves are nicely represented already. Having hacked on GHC is not a requirement.

To nominate yourself, please send an email to me (as the committee secretary) at mail@joachim-breitner.de until July 20th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private.

You cannot nominate others. But if you know of anyone else you’d think should be on the committee, please do encourage them, or talk to us and we can encourage them.

On behalf of the committee, Joachim Breitner ==========================

Note worth discussing:

* I see no point in non-self-nominations. We can only have members that want to do this.

* Do we want to encourage “conservative” members? Is that the right wording? (I see the committee a bit as a flood gate that protects against premature and not-worth-it changes. We are doing a good job of that – most of my proposals get rejected ;-) – but I think it would not hurt to explicitly keep it that way.

* One could consider public nominations and deliberations, but I feel that a public discussion of who we think is the “best” is not very nice.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ccac1713fd9614f04d17d08d5e56cdc25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667178065259412&sdata=vab8j7i%2F9tp7QLt4CicceON5iDPoj779PGgH7KBEXpo%3D&reserved=0

_______________________________________________ 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