Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
143 messages Options
1 ... 5678
Reply | Threaded
Open this post in threaded view
|

Re: Committee M.O. Change Proposals

Geoffrey Mainland
Apologies for the previous mailer-mangled "draft"...

On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote:

> Hello,
>
> On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote:
>
> [...]
>
>> In effect, only those who actively follow the libraries list have had a
>> voice in these decisions. Maybe that is what the community wants. I hope
>> not. How then can people like me (and Henrik and Graham) have a say
>> without committing to actively following the libraries list?
>>  
>> We have a method to solve this: elected representatives. Right now the
>> Core Libraries Committee elects its own members; perhaps it is time for
>> that to change.
> [...]
>
>> Proposal 1: Move to community election of the members of the Core
>> Libraries Committee. Yes, I know this would have its own issues.
> How exactly do public elections of representatives address the problem
> that some people feel left out? Have you considered nominating yourself
> or somebody else you have confidence in for the core libraries
> committee? You'd still have to find somebody to represent your
> interests, regardless of whether the committee is self-elected or
> direct-elected.
>
> Here's some food for thought regarding language design by voting or its
> indirect form via a directly elected language committee:
>
> Back in February there was a large-scale survey which resulted (see [2]
> for more details) in a rather unequivocal 4:1 majority *for* going
> through with the otherwise controversial FTP implementation. If the
> community elections would result in a similar spirit, you'd could easily
> end up with a similarly 4:1 pro-change biased committee. Would you
> consider that a well balanced committee formation?

Thanks, all good points.

It is quite possible that direct elections would produce the exact same
committee. I wouldn't see that as a negative outcome at all! At least
that committee would have been put in place by direct election; I would
see that as strengthening their mandate.

I am very much aware of the February survey. I wonder if Proposal 2, had
it been in place at the time, would have increased participation in the
survey.

The recent kerfuffle has caught the attention of many people who don't
normally follow the libraries list. Proposal 1 is an attempt to give
them a voice. Yes, they would still need to find a candidate to
represent their interests. If we moved to direct elections, I would
consider running. However, my preference is that Proposal 3 go through
in some form, in which case my main concern would be the Haskell Prime
committee, and unfortunately nominations for that committee have already
closed.

>> Proposal 2: After a suitable period of discussion on the libraries list,
>> the Core Libraries Committee will summarize the arguments for and
>> against a proposal and post it, along with a (justified) preliminary
>> decision, to a low-traffic, announce-only email list. After another
>> suitable period of discussion, they will issue a final decision. What is
>> a suitable period of time? Perhaps that depends on the properties of the
>> proposal, such as whether it breaks backwards compatibility.
> That generally sounds like a good compromise, if this actually helps
> reaching the otherwise unreachable parts of the community and have their
> voices heard.

My hope is that a low-volume mailing list would indeed reach a wider
audience.

>> Proposal 3: A decision regarding any proposal that significantly affects
>> backwards compatibility is within the purview of the Haskell Prime
>> Committee, not the Core Libraries Committee.
> I don't see how that would change much. The prior Haskell Prime
> Committee has been traditionally self-elected as well. So it's just the
> label of the committee you'd swap out.
>
> In the recent call of nominations[1] for Haskell Prime, the stated area
> of work for the new nominations was to take care of the *language* part,
> because that's what we are lacking the workforce for.
>
> Since its creation for the very purpose of watching over the core
> libraries, the core-libraries-committee has been almost exclusively busy
> with evaluating and deciding about changes to the `base` library and
> overseeing their implementation. Transferring this huge workload to the
> new Haskell Prime committee members who have already their hands full
> with revising the language part would IMO just achieve to reduce the
> effectiveness of the upcoming Haskell Prime committee, and therefore
> increase the risk of failure in producing an adequate new Haskell Report
> revision.

My understanding is that much of the work of the core libraries
committee does not "significantly affect backwards compatibility," at
least not to the extent that MRP does. If this is the case, the bulk of
their workload would not be transferred to the new Haskell Prime
committee. Is my understanding incorrect?

The intent of Proposal 3 was to transfer only a small fraction of the
issues that come before the core libraries committee to the Haskell
Prime committee. In any case, we would certainly need to clarify what
"significantly affects backwards compatibility" means.

Perhaps we should consider direct elections for the Haskell Prime
committee as well as changing their mandate to include some subset of
the changes proposed to libraries covered by the Haskell Report. My
understanding of the current state of affairs is that the Haskell Prime
committee is charged with producing a new report, but the core libraries
committee is in charge of the library part of that report. Is that correct?

Cheers,
Geoff

> Regards,
>   H.V.Riedel
>
>  [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
>  [2]: https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Committee M.O. Change Proposals

Edward Kmett-2
In reply to this post by Geoffrey Mainland
The committee was formed from a pool of suggestions supplied to SPJ that represented a fairly wide cross-section of the community.

Simon initially offered both myself and Johan Tibell the role of co-chairs. Johan ultimately declined.

In the end, putting perhaps too simple a spin on it, the initial committee was selected: Michael Snoyman for commercial interest, Mark Lentczner representing the needs of the Platform and implementation concerns, Brent Yorgey on the theory side, Doug Beardsley representing practitioners, Joachim Breitner had expressed interest in working on split base, which at the time was a much more active concern, Dan Doel represented a decent balance of theory and practice.

Since then we had two slots open up on the committee, and precisely two self-nominations to fill them, which rather simplified the selection process. Brent and Doug rotated out and Eric Mertens and Luite Stegeman rotated in.

Technically, yes, we are self-selected going forward, based on the precedent of the haskell.org committee and haskell-prime committees, but you'll note this hasn't actually been a factor yet as there hasn't been any decision point reached where that has affected a membership decision.

-Edward

On Wed, Oct 21, 2015 at 8:31 AM, Geoffrey Mainland <[hidden email]> wrote:
On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote:
> Hello, > > On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote: > > [...]
> >> In effect, only those who actively follow the libraries list have
had a >> voice in these decisions. Maybe that is what the community
wants. I hope >> not. How then can people like me (and Henrik and
Graham) have a say >> without committing to actively following the
libraries list? >>  >> We have a method to solve this: elected
representatives. Right now the >> Core Libraries Committee elects its
own members; perhaps it is time for >> that to change. > > [...] > >>
Proposal 1: Move to community election of the members of the Core >>
Libraries Committee. Yes, I know this would have its own issues. > > How
exactly do public elections of representatives address the problem >
that some people feel left out? Have you considered nominating yourself
> or somebody else you have confidence in for the core libraries >
committee? You'd still have to find somebody to represent your >
interests, regardless of whether the committee is self-elected or >
direct-elected. > > Here's some food for thought regarding language
design by voting or its > indirect form via a directly elected language
committee: > > Back in February there was a large-scale survey which
resulted (see [2] > for more details) in a rather unequivocal 4:1
majority *for* going > through with the otherwise controversial FTP
implementation. If the > community elections would result in a similar
spirit, you'd could easily > end up with a similarly 4:1 pro-change
biased committee. Would you > consider that a well balanced committee
formation?

Thanks, all good points.

It is quite possible that direct elections would produce the exact same
committee. I wouldn't see that as a negative outcome at all! At least
that committee would have been put in place by direct election; I would
see that as strengthening their mandate.

I am very much aware of the February survey. I wonder if Proposal 2, had
it been in place at the time, would have increased participation in the
survey.

The recent kerfuffle has caught the attention of many people who don't
normally follow the libraries list. Proposal 1 is an attempt to give
them a voice. Yes, they would still need to find a candidate to
represent their interests. If we moved to direct elections, I would
consider running. However, my preference is that Proposal 3 go through
in some form, in which case my main concern would be the Haskell Prime
committee, and unfortunately nominations for that committee have already
closed.

>> Proposal 2: After a suitable period of discussion on the libraries list, >> the Core Libraries Committee will summarize the arguments for and >>
against a proposal and post it, along with a (justified) preliminary >>
decision, to a low-traffic, announce-only email list. After another >>
suitable period of discussion, they will issue a final decision. What is
>> a suitable period of time? Perhaps that depends on the properties of
the >> proposal, such as whether it breaks backwards compatibility. > >
That generally sounds like a good compromise, if this actually helps >
reaching the otherwise unreachable parts of the community and have their
> voices heard.

My hope is that a low-volume mailing list would indeed reach a wider
audience.

>> Proposal 3: A decision regarding any proposal that significantly affects >> backwards compatibility is within the purview of the Haskell Prime
>> Committee, not the Core Libraries Committee. > > I don't see how that
would change much. The prior Haskell Prime > Committee has been
traditionally self-elected as well. So it's just the > label of the
committee you'd swap out. > > In the recent call of nominations[1] for
Haskell Prime, the stated area > of work for the new nominations was to
take care of the *language* part, > because that's what we are lacking
the workforce for. > > Since its creation for the very purpose of
watching over the core > libraries, the core-libraries-committee has
been almost exclusively busy > with evaluating and deciding about
changes to the `base` library and > overseeing their implementation.
Transferring this huge workload to the > new Haskell Prime committee
members who have already their hands full > with revising the language
part would IMO just achieve to reduce the > effectiveness of the
upcoming Haskell Prime committee, and therefore > increase the risk of
failure in producing an adequate new Haskell Report > revision.

My understanding is that much of the work of the core libraries
committee does not "significantly affect backwards compatibility," at
least not to the extent that MRP does. If this is the case, the bulk of
their workload would not be transferred to the new Haskell Prime
committee. Is my understanding incorrect?

The intent of Proposal 3 was to transfer only a small fraction of the
issues that come before the core libraries committee to the Haskell
Prime committee. In any case, we would certainly need to clarify what
"significantly affects backwards compatibility" means.

Perhaps we should consider direct elections for the Haskell Prime
committee as well as changing their mandate to include some subset of
the changes proposed to libraries covered by the Haskell Report. My
understanding of the current state of affairs is that the Haskell Prime
committee is charged with producing a new report, but the core libraries
committee is in charge of the library part of that report. Is that
correct?

Cheers,
Geoff

> Regards, >   H.V.Riedel > >  [1]:
https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
>  [2]:
https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Committee M.O. Change Proposals

Geoffrey Mainland
Thanks for the background, Edward.

I don't mean to question the composition of the committee, only to start
a discussion about how the community might handle the selection process
going forward. I apologize if I was not clear about that. As I said
below, if a direct vote resulted in the same committee we would have had
under the current system, I would consider that a success!

We may also see a larger nomination pool in the future :)

Cheers,
Geoff

On 10/21/2015 03:54 PM, Edward Kmett wrote:

> The committee was formed from a pool of suggestions supplied to SPJ
> that represented a fairly wide cross-section of the community.
>
> Simon initially offered both myself and Johan Tibell the role of
> co-chairs. Johan ultimately declined.
>
> In the end, putting perhaps too simple a spin on it, the initial
> committee was selected: Michael Snoyman for commercial interest, Mark
> Lentczner representing the needs of the Platform and implementation
> concerns, Brent Yorgey on the theory side, Doug Beardsley representing
> practitioners, Joachim Breitner had expressed interest in working on
> split base, which at the time was a much more active concern, Dan Doel
> represented a decent balance of theory and practice.
>
> Since then we had two slots open up on the committee, and precisely
> two self-nominations to fill them, which rather simplified the
> selection process. Brent and Doug rotated out and Eric Mertens and
> Luite Stegeman rotated in.
>
> Technically, yes, we are self-selected going forward, based on the
> precedent of the haskell.org <http://haskell.org> committee and
> haskell-prime committees, but you'll note this hasn't actually been a
> factor yet as there hasn't been any decision point reached where that
> has affected a membership decision.
>
> -Edward
>
> On Wed, Oct 21, 2015 at 8:31 AM, Geoffrey Mainland
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote:
>     > Hello, > > On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland
>     wrote: > > [...]
>     > >> In effect, only those who actively follow the libraries list have
>     had a >> voice in these decisions. Maybe that is what the community
>     wants. I hope >> not. How then can people like me (and Henrik and
>     Graham) have a say >> without committing to actively following the
>     libraries list? >>  >> We have a method to solve this: elected
>     representatives. Right now the >> Core Libraries Committee elects its
>     own members; perhaps it is time for >> that to change. > > [...] > >>
>     Proposal 1: Move to community election of the members of the Core >>
>     Libraries Committee. Yes, I know this would have its own issues. >
>     > How
>     exactly do public elections of representatives address the problem >
>     that some people feel left out? Have you considered nominating
>     yourself
>     > or somebody else you have confidence in for the core libraries >
>     committee? You'd still have to find somebody to represent your >
>     interests, regardless of whether the committee is self-elected or >
>     direct-elected. > > Here's some food for thought regarding language
>     design by voting or its > indirect form via a directly elected
>     language
>     committee: > > Back in February there was a large-scale survey which
>     resulted (see [2] > for more details) in a rather unequivocal 4:1
>     majority *for* going > through with the otherwise controversial FTP
>     implementation. If the > community elections would result in a similar
>     spirit, you'd could easily > end up with a similarly 4:1 pro-change
>     biased committee. Would you > consider that a well balanced committee
>     formation?
>
>     Thanks, all good points.
>
>     It is quite possible that direct elections would produce the exact
>     same
>     committee. I wouldn't see that as a negative outcome at all! At least
>     that committee would have been put in place by direct election; I
>     would
>     see that as strengthening their mandate.
>
>     I am very much aware of the February survey. I wonder if Proposal
>     2, had
>     it been in place at the time, would have increased participation
>     in the
>     survey.
>
>     The recent kerfuffle has caught the attention of many people who don't
>     normally follow the libraries list. Proposal 1 is an attempt to give
>     them a voice. Yes, they would still need to find a candidate to
>     represent their interests. If we moved to direct elections, I would
>     consider running. However, my preference is that Proposal 3 go through
>     in some form, in which case my main concern would be the Haskell Prime
>     committee, and unfortunately nominations for that committee have
>     already
>     closed.
>
>     >> Proposal 2: After a suitable period of discussion on the
>     libraries list, >> the Core Libraries Committee will summarize the
>     arguments for and >>
>     against a proposal and post it, along with a (justified)
>     preliminary >>
>     decision, to a low-traffic, announce-only email list. After another >>
>     suitable period of discussion, they will issue a final decision.
>     What is
>     >> a suitable period of time? Perhaps that depends on the
>     properties of
>     the >> proposal, such as whether it breaks backwards
>     compatibility. > >
>     That generally sounds like a good compromise, if this actually helps >
>     reaching the otherwise unreachable parts of the community and have
>     their
>     > voices heard.
>
>     My hope is that a low-volume mailing list would indeed reach a wider
>     audience.
>
>     >> Proposal 3: A decision regarding any proposal that
>     significantly affects >> backwards compatibility is within the
>     purview of the Haskell Prime
>     >> Committee, not the Core Libraries Committee. > > I don't see
>     how that
>     would change much. The prior Haskell Prime > Committee has been
>     traditionally self-elected as well. So it's just the > label of the
>     committee you'd swap out. > > In the recent call of nominations[1] for
>     Haskell Prime, the stated area > of work for the new nominations
>     was to
>     take care of the *language* part, > because that's what we are lacking
>     the workforce for. > > Since its creation for the very purpose of
>     watching over the core > libraries, the core-libraries-committee has
>     been almost exclusively busy > with evaluating and deciding about
>     changes to the `base` library and > overseeing their implementation.
>     Transferring this huge workload to the > new Haskell Prime committee
>     members who have already their hands full > with revising the language
>     part would IMO just achieve to reduce the > effectiveness of the
>     upcoming Haskell Prime committee, and therefore > increase the risk of
>     failure in producing an adequate new Haskell Report > revision.
>
>     My understanding is that much of the work of the core libraries
>     committee does not "significantly affect backwards compatibility," at
>     least not to the extent that MRP does. If this is the case, the
>     bulk of
>     their workload would not be transferred to the new Haskell Prime
>     committee. Is my understanding incorrect?
>
>     The intent of Proposal 3 was to transfer only a small fraction of the
>     issues that come before the core libraries committee to the Haskell
>     Prime committee. In any case, we would certainly need to clarify what
>     "significantly affects backwards compatibility" means.
>
>     Perhaps we should consider direct elections for the Haskell Prime
>     committee as well as changing their mandate to include some subset of
>     the changes proposed to libraries covered by the Haskell Report. My
>     understanding of the current state of affairs is that the Haskell
>     Prime
>     committee is charged with producing a new report, but the core
>     libraries
>     committee is in charge of the library part of that report. Is that
>     correct?
>
>     Cheers,
>     Geoff
>
>     > Regards, >   H.V.Riedel > >  [1]:
>     https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
>     >  [2]:
>     https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html
>
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
1 ... 5678