[ghc-steering-committee] Solicitation for a new member

Mon Jul 9 13:46:14 UTC 2018

+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 <rae at cs.brynmawr.edu>
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 <chak at justtesting.org>
> 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 <ghc-steering-committee at haskell.org>:
>
> 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 at 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 <ghc-steering-committee-bounces at haskell.org
> > *On Behalf Of *Simon Marlow
> *Sent:* 09 July 2018 08:23
> *To:* Joachim Breitner <mail at joachim-breitner.de>
> *Cc:* ghc-steering-committee at 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 <mail at 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 at 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 at 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 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/20180709/0564c92e/attachment-0001.html>