New Libraries Proposal process

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

New Libraries Proposal process

chessai .
All,


There is a new Libraries Proposal process, inspired by the GHC Proposals process.

Core Library APIs are critical. It's easy for a sensible proposal to languish or simply get dropped on the floor; and (in the other direction) a bit too easy for a proposal to make it into the core libraries without receiving the scrutiny it deserves. Most of the proposals that have been made on this mailing list, become lost to the archives. It's not easy for anyone to answer the question "what decisions has the CLC made recently?" without trawling a huge email archive. 

Of course, this is mostly for breaking changes or "big" introductions; we don't need a full proposal over something tiny, e.g. "a module from vector is missing a fold". That would be more appropriate on vector's issue tracker, and left to the maintainers to deal with.

I encourage anyone interested to get started by reading the README at https://github.com/haskell-core/core-libraries-proposals.


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

Re: New Libraries Proposal process

Carter Schonwald
Where was this discussed or proposed? All libraries process needs to start on the libraries mailing list. And soemtimes Perhaps moving to clc list for resolving tie breaking on controversial choices. 

The libraries archive goes back pretty far and email threading seems to scale far better for participating in complex discussions than does githubs comment collapsing on large discussions.  

On Fri, Sep 11, 2020 at 3:20 PM chessai <[hidden email]> wrote:
All,


There is a new Libraries Proposal process, inspired by the GHC Proposals process.

Core Library APIs are critical. It's easy for a sensible proposal to languish or simply get dropped on the floor; and (in the other direction) a bit too easy for a proposal to make it into the core libraries without receiving the scrutiny it deserves. Most of the proposals that have been made on this mailing list, become lost to the archives. It's not easy for anyone to answer the question "what decisions has the CLC made recently?" without trawling a huge email archive. 

Of course, this is mostly for breaking changes or "big" introductions; we don't need a full proposal over something tiny, e.g. "a module from vector is missing a fold". That would be more appropriate on vector's issue tracker, and left to the maintainers to deal with.

I encourage anyone interested to get started by reading the README at https://github.com/haskell-core/core-libraries-proposals.



_______________________________________________

Libraries mailing list

[hidden email]

http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


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

Fwd: New Libraries Proposal process

Carter Schonwald
Are you sure about this approach? I think you need to start with an open discussion , And have a open ended thread about ideas for how to improve how we do things. 

A proposals process / formal process isn’t always a win. This sortah approach demands a lot more dedicated human power and support admin than I think is tenable for the libraries ecosystem today. 

Merry Friday and be well
-Carter 

---------- Forwarded message ---------
From: chessai <[hidden email]>
Date: Fri, Sep 11, 2020 at 10:02 PM
Subject: Re: New Libraries Proposal process
To: Carter Schonwald <[hidden email]>


This has been discussed on and off for a few months now, amongst CLC, between members of CLC and GHC Steering/Haskell.org, Tweag, Target, IOHK, Serokell, etc. My only regret is that a lot of the conversation happened privately.

> All libraries process needs to start on the libraries mailing list

Not anymore. 

The libraries mailing list has proven to be ineffective when it comes to getting stuff done. Mailing lists are not the right format for this. Furthermore, I don't see how emails are more conducive to deep discussion than github comments. There are many GitHub issue trackers and PRs which show otherwise.

This new process will never be perfect and of course will need some tweaking, but the current process is very poor and gets little done. Most proposals I ever see end up with no resolution.

Since the GHC Proposals process has proven to be a net positive, much of the structure was taken from there and adapted to core libraries.


On Fri, Sep 11, 2020, 19:52 Carter Schonwald <[hidden email]> wrote:
Where was this discussed or proposed? All libraries process needs to start on the libraries mailing list. And soemtimes Perhaps moving to clc list for resolving tie breaking on controversial choices. 

The libraries archive goes back pretty far and email threading seems to scale far better for participating in complex discussions than does githubs comment collapsing on large discussions.  

On Fri, Sep 11, 2020 at 3:20 PM chessai <[hidden email]> wrote:
All,


There is a new Libraries Proposal process, inspired by the GHC Proposals process.

Core Library APIs are critical. It's easy for a sensible proposal to languish or simply get dropped on the floor; and (in the other direction) a bit too easy for a proposal to make it into the core libraries without receiving the scrutiny it deserves. Most of the proposals that have been made on this mailing list, become lost to the archives. It's not easy for anyone to answer the question "what decisions has the CLC made recently?" without trawling a huge email archive. 

Of course, this is mostly for breaking changes or "big" introductions; we don't need a full proposal over something tiny, e.g. "a module from vector is missing a fold". That would be more appropriate on vector's issue tracker, and left to the maintainers to deal with.

I encourage anyone interested to get started by reading the README at https://github.com/haskell-core/core-libraries-proposals.



_______________________________________________

Libraries mailing list

[hidden email]

http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries






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

Re: New Libraries Proposal process

chessai .
I think that is good feedback.

I have been talking with a lot of people since the announcement who have made similar points, and CLC has decided to roll back this proposals process. Discussion is going to be happening on the CLC mailing list about what to do.

On Fri, Sep 11, 2020, 22:36 Carter Schonwald <[hidden email]> wrote:
Are you sure about this approach? I think you need to start with an open discussion , And have a open ended thread about ideas for how to improve how we do things. 

A proposals process / formal process isn’t always a win. This sortah approach demands a lot more dedicated human power and support admin than I think is tenable for the libraries ecosystem today. 

Merry Friday and be well
-Carter 

---------- Forwarded message ---------
From: chessai <[hidden email]>
Date: Fri, Sep 11, 2020 at 10:02 PM
Subject: Re: New Libraries Proposal process
To: Carter Schonwald <[hidden email]>


This has been discussed on and off for a few months now, amongst CLC, between members of CLC and GHC Steering/Haskell.org, Tweag, Target, IOHK, Serokell, etc. My only regret is that a lot of the conversation happened privately.

> All libraries process needs to start on the libraries mailing list

Not anymore. 

The libraries mailing list has proven to be ineffective when it comes to getting stuff done. Mailing lists are not the right format for this. Furthermore, I don't see how emails are more conducive to deep discussion than github comments. There are many GitHub issue trackers and PRs which show otherwise.

This new process will never be perfect and of course will need some tweaking, but the current process is very poor and gets little done. Most proposals I ever see end up with no resolution.

Since the GHC Proposals process has proven to be a net positive, much of the structure was taken from there and adapted to core libraries.


On Fri, Sep 11, 2020, 19:52 Carter Schonwald <[hidden email]> wrote:
Where was this discussed or proposed? All libraries process needs to start on the libraries mailing list. And soemtimes Perhaps moving to clc list for resolving tie breaking on controversial choices. 

The libraries archive goes back pretty far and email threading seems to scale far better for participating in complex discussions than does githubs comment collapsing on large discussions.  

On Fri, Sep 11, 2020 at 3:20 PM chessai <[hidden email]> wrote:
All,


There is a new Libraries Proposal process, inspired by the GHC Proposals process.

Core Library APIs are critical. It's easy for a sensible proposal to languish or simply get dropped on the floor; and (in the other direction) a bit too easy for a proposal to make it into the core libraries without receiving the scrutiny it deserves. Most of the proposals that have been made on this mailing list, become lost to the archives. It's not easy for anyone to answer the question "what decisions has the CLC made recently?" without trawling a huge email archive. 

Of course, this is mostly for breaking changes or "big" introductions; we don't need a full proposal over something tiny, e.g. "a module from vector is missing a fold". That would be more appropriate on vector's issue tracker, and left to the maintainers to deal with.

I encourage anyone interested to get started by reading the README at https://github.com/haskell-core/core-libraries-proposals.



_______________________________________________

Libraries mailing list

[hidden email]

http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries





_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

Re: New Libraries Proposal process

David Feuer
In reply to this post by Carter Schonwald
In terms of decision-making process for this new process, I must agree with Carter. To the best of my knowledge,  neither CLC nor the GHC steering committee have general authority to make decisions about libraries on behalf of the community without first going through the mailing list proposal process. As far as I'm concerned, that should include changing said process. Any discussions that happened in private must be considered mere preparation for formal process, which should begin on the libraries list.

On Fri, Sep 11, 2020, 11:36 PM Carter Schonwald <[hidden email]> wrote:
Are you sure about this approach? I think you need to start with an open discussion , And have a open ended thread about ideas for how to improve how we do things. 

A proposals process / formal process isn’t always a win. This sortah approach demands a lot more dedicated human power and support admin than I think is tenable for the libraries ecosystem today. 

Merry Friday and be well
-Carter 

---------- Forwarded message ---------
From: chessai <[hidden email]>
Date: Fri, Sep 11, 2020 at 10:02 PM
Subject: Re: New Libraries Proposal process
To: Carter Schonwald <[hidden email]>


This has been discussed on and off for a few months now, amongst CLC, between members of CLC and GHC Steering/Haskell.org, Tweag, Target, IOHK, Serokell, etc. My only regret is that a lot of the conversation happened privately.

> All libraries process needs to start on the libraries mailing list

Not anymore. 

The libraries mailing list has proven to be ineffective when it comes to getting stuff done. Mailing lists are not the right format for this. Furthermore, I don't see how emails are more conducive to deep discussion than github comments. There are many GitHub issue trackers and PRs which show otherwise.

This new process will never be perfect and of course will need some tweaking, but the current process is very poor and gets little done. Most proposals I ever see end up with no resolution.

Since the GHC Proposals process has proven to be a net positive, much of the structure was taken from there and adapted to core libraries.


On Fri, Sep 11, 2020, 19:52 Carter Schonwald <[hidden email]> wrote:
Where was this discussed or proposed? All libraries process needs to start on the libraries mailing list. And soemtimes Perhaps moving to clc list for resolving tie breaking on controversial choices. 

The libraries archive goes back pretty far and email threading seems to scale far better for participating in complex discussions than does githubs comment collapsing on large discussions.  

On Fri, Sep 11, 2020 at 3:20 PM chessai <[hidden email]> wrote:
All,


There is a new Libraries Proposal process, inspired by the GHC Proposals process.

Core Library APIs are critical. It's easy for a sensible proposal to languish or simply get dropped on the floor; and (in the other direction) a bit too easy for a proposal to make it into the core libraries without receiving the scrutiny it deserves. Most of the proposals that have been made on this mailing list, become lost to the archives. It's not easy for anyone to answer the question "what decisions has the CLC made recently?" without trawling a huge email archive. 

Of course, this is mostly for breaking changes or "big" introductions; we don't need a full proposal over something tiny, e.g. "a module from vector is missing a fold". That would be more appropriate on vector's issue tracker, and left to the maintainers to deal with.

I encourage anyone interested to get started by reading the README at https://github.com/haskell-core/core-libraries-proposals.



_______________________________________________

Libraries mailing list

[hidden email]

http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries





_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

Re: Fwd: New Libraries Proposal process

Haskell - Libraries mailing list
In reply to this post by Carter Schonwald
Carter Schonwald wrote:
> Are you sure about this approach? I think you need to start with an
> open discussion , And have a open ended thread about ideas for how to
> improve how we do things.

I totally agree with this, though fleshing out ideas in a smaller
forum first is helpful.

An important consideration here is that there are several types of
stakeholders in the library proposal process, including

* the CLC members, who ultimately decide on core library changes;
* proponents ("authors"), who originate proposals for such changes;
  and
* observers ("the wider Haskell community"), users of the core
  libraries who want to keep track of upcoming library changes and
  chime in when a proposal affects their own uses of a library.

I suspect that the observers are a silent majority, and that a mailing
list with public archives is close to optimal for them. (I consider
myself an observer and I do like the mailing list for precisely this
reason. But I also grew up with mailing lists, not forums, so I'm
surely biased here.)

In any case I think that any change to the library proposal process
should cater to all three types of stakeholders (and possibly others
I have failed to think of). In its current form, I believe

  https://github.com/haskell-core/core-libraries-proposals

fails to do that for observers.

Cheers,

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

Re: Fwd: New Libraries Proposal process

Oliver Charles-3


On Sat, 12 Sep 2020, at 2:44 PM, Bertram Felgenhauer via Libraries wrote:
In any case I think that any change to the library proposal process
should cater to all three types of stakeholders (and possibly others
I have failed to think of). In its current form, I believe


fails to do that for observers.

Could you explain why this fails? I watch the ghc-proposals GitHub project and get notified of all comments, so feel as an observer my needs are well catered for. Furthermore, having each proposal be a PR can let me see how a discussion is factored back in to the proposal, as comments become a diff.

What do you feel a ML has that GitHub + watching does not have?

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

Re: Fwd: New Libraries Proposal process

Haskell - Libraries mailing list
Oliver Charles wrote:

> On Sat, 12 Sep 2020, at 2:44 PM, Bertram Felgenhauer via Libraries
> wrote:
>
> In any case I think that any change to the library proposal process
> should cater to all three types of stakeholders (and possibly others
> I have failed to think of). In its current form, I believe
>
>   [1]https://github.com/haskell-core/core-libraries-proposals
>
> fails to do that for observers.
>
> Could you explain why this fails? I watch the ghc-proposals GitHub
> project and get notified of all comments, so feel as an observer my
> needs are well catered for. Furthermore, having each proposal be a PR
> can let me see how a discussion is factored back in to the proposal, as
> comments become a diff.

Unless somebody force-pushes a new version, in which case I think
the old version is lost forever.

> What do you feel a ML has that GitHub + watching does not have?

I suppose that works, for people with a GitHub account (possibly a
strawman; I do have one). But it should be mentioned somewhere! The
experience can also be improved by conventions. For example, I'd like
the PRs that constitute proposals to come with a synopsis of the
proposal as the description, because the descriptions end up in the
notifications, whereas the actual commits do not. So to avoid having
to check every proposal on GitHub, such a synopsis would be useful.
Maybe this should be self-evident, but it's not mentioned in the
README document.

There's also the loss of threading mentioned elsewhere. I cannot say
how bad this is in practice (I delete GitHub notifications after
reading them). We can see in the libraries archive that for larger
proposals we often have several subthreads about different aspects of
the proposal (and I frequently skip over whole subthreads when I'm
not intersted the aspect under consideration).

I also find that with email it's easy to send a comment just to the
author (e.g. for typos). GitHub makes this harder (I suppose you /can/
open a ticket in the author's clone of the repo...).

And, obviously, there's resistance to change.

While we're comparing these things, what are the problems that the new
process is meant to solve?

Cheers,

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

Re: Fwd: New Libraries Proposal process

Tikhon Jelvis
One thing I find valuable with the GitHub proposal style—which I've observed in GHC proposals and in Rust—is that each proposal has a document that contains all of the information and gets updated over time. Later on, it's nice to read the final version of a proposal document without needing to go into all of the discussion that led up to it.

We could still do that while having discussions on a mailing list, of course, but it seems that GitHub makes the connection between discussions and the proposal document more direct.

On Sat, Sep 12, 2020, 09:15 Bertram Felgenhauer via Libraries <[hidden email]> wrote:
Oliver Charles wrote:
> On Sat, 12 Sep 2020, at 2:44 PM, Bertram Felgenhauer via Libraries
> wrote:
>
> In any case I think that any change to the library proposal process
> should cater to all three types of stakeholders (and possibly others
> I have failed to think of). In its current form, I believe
>
>   [1]https://github.com/haskell-core/core-libraries-proposals
>
> fails to do that for observers.
>
> Could you explain why this fails? I watch the ghc-proposals GitHub
> project and get notified of all comments, so feel as an observer my
> needs are well catered for. Furthermore, having each proposal be a PR
> can let me see how a discussion is factored back in to the proposal, as
> comments become a diff.

Unless somebody force-pushes a new version, in which case I think
the old version is lost forever.

> What do you feel a ML has that GitHub + watching does not have?

I suppose that works, for people with a GitHub account (possibly a
strawman; I do have one). But it should be mentioned somewhere! The
experience can also be improved by conventions. For example, I'd like
the PRs that constitute proposals to come with a synopsis of the
proposal as the description, because the descriptions end up in the
notifications, whereas the actual commits do not. So to avoid having
to check every proposal on GitHub, such a synopsis would be useful.
Maybe this should be self-evident, but it's not mentioned in the
README document.

There's also the loss of threading mentioned elsewhere. I cannot say
how bad this is in practice (I delete GitHub notifications after
reading them). We can see in the libraries archive that for larger
proposals we often have several subthreads about different aspects of
the proposal (and I frequently skip over whole subthreads when I'm
not intersted the aspect under consideration).

I also find that with email it's easy to send a comment just to the
author (e.g. for typos). GitHub makes this harder (I suppose you /can/
open a ticket in the author's clone of the repo...).

And, obviously, there's resistance to change.

While we're comparing these things, what are the problems that the new
process is meant to solve?

Cheers,

Bertram
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

Re: New Libraries Proposal process

David Feuer
In reply to this post by David Feuer
I'd like to clarify that I actually support moving the proposal discussions to something easier to track and search. I'm just not that pleased with the way the announcement came down from on high.

On Fri, Sep 11, 2020, 11:47 PM David Feuer <[hidden email]> wrote:
In terms of decision-making process for this new process, I must agree with Carter. To the best of my knowledge,  neither CLC nor the GHC steering committee have general authority to make decisions about libraries on behalf of the community without first going through the mailing list proposal process. As far as I'm concerned, that should include changing said process. Any discussions that happened in private must be considered mere preparation for formal process, which should begin on the libraries list.

On Fri, Sep 11, 2020, 11:36 PM Carter Schonwald <[hidden email]> wrote:
Are you sure about this approach? I think you need to start with an open discussion , And have a open ended thread about ideas for how to improve how we do things. 

A proposals process / formal process isn’t always a win. This sortah approach demands a lot more dedicated human power and support admin than I think is tenable for the libraries ecosystem today. 

Merry Friday and be well
-Carter 

---------- Forwarded message ---------
From: chessai <[hidden email]>
Date: Fri, Sep 11, 2020 at 10:02 PM
Subject: Re: New Libraries Proposal process
To: Carter Schonwald <[hidden email]>


This has been discussed on and off for a few months now, amongst CLC, between members of CLC and GHC Steering/Haskell.org, Tweag, Target, IOHK, Serokell, etc. My only regret is that a lot of the conversation happened privately.

> All libraries process needs to start on the libraries mailing list

Not anymore. 

The libraries mailing list has proven to be ineffective when it comes to getting stuff done. Mailing lists are not the right format for this. Furthermore, I don't see how emails are more conducive to deep discussion than github comments. There are many GitHub issue trackers and PRs which show otherwise.

This new process will never be perfect and of course will need some tweaking, but the current process is very poor and gets little done. Most proposals I ever see end up with no resolution.

Since the GHC Proposals process has proven to be a net positive, much of the structure was taken from there and adapted to core libraries.


On Fri, Sep 11, 2020, 19:52 Carter Schonwald <[hidden email]> wrote:
Where was this discussed or proposed? All libraries process needs to start on the libraries mailing list. And soemtimes Perhaps moving to clc list for resolving tie breaking on controversial choices. 

The libraries archive goes back pretty far and email threading seems to scale far better for participating in complex discussions than does githubs comment collapsing on large discussions.  

On Fri, Sep 11, 2020 at 3:20 PM chessai <[hidden email]> wrote:
All,


There is a new Libraries Proposal process, inspired by the GHC Proposals process.

Core Library APIs are critical. It's easy for a sensible proposal to languish or simply get dropped on the floor; and (in the other direction) a bit too easy for a proposal to make it into the core libraries without receiving the scrutiny it deserves. Most of the proposals that have been made on this mailing list, become lost to the archives. It's not easy for anyone to answer the question "what decisions has the CLC made recently?" without trawling a huge email archive. 

Of course, this is mostly for breaking changes or "big" introductions; we don't need a full proposal over something tiny, e.g. "a module from vector is missing a fold". That would be more appropriate on vector's issue tracker, and left to the maintainers to deal with.

I encourage anyone interested to get started by reading the README at https://github.com/haskell-core/core-libraries-proposals.



_______________________________________________

Libraries mailing list

[hidden email]

http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries





_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

Re: Fwd: New Libraries Proposal process

Carter Schonwald
In reply to this post by Haskell - Libraries mailing list
Thank you Bertram! 
I think these are very important perspectives and questions  that I feel arent being answered. 

Secondarily, I worry that some of these approaches turn into professionalizing activities people do as volunteers for fun! Supporting contributors of all walks and backgrounds is very different from workflow management with full time administrative supoort... 

If certain folks find an issue tracker helps them, great! But it would be good to clearly articulate who benefits and who it hinders and what are examples where actually progressing improvements has been stymied where the issue indeed lies with not having an issue tracker.  I absolutely agree that all things being equal, having task journals of items and their specifications is great. But ... that presupposes a lot more suport Labor is available in a semi professional capacity than I think can be done while being inclusive. 

I could be totally wrong, but it’s a concern I have 

On Sat, Sep 12, 2020 at 12:15 PM Bertram Felgenhauer via Libraries <[hidden email]> wrote:
Oliver Charles wrote:

> On Sat, 12 Sep 2020, at 2:44 PM, Bertram Felgenhauer via Libraries

> wrote:

>

> In any case I think that any change to the library proposal process

> should cater to all three types of stakeholders (and possibly others

> I have failed to think of). In its current form, I believe

>

>   [1]https://github.com/haskell-core/core-libraries-proposals

>

> fails to do that for observers.

>

> Could you explain why this fails? I watch the ghc-proposals GitHub

> project and get notified of all comments, so feel as an observer my

> needs are well catered for. Furthermore, having each proposal be a PR

> can let me see how a discussion is factored back in to the proposal, as

> comments become a diff.



Unless somebody force-pushes a new version, in which case I think

the old version is lost forever.



> What do you feel a ML has that GitHub + watching does not have?



I suppose that works, for people with a GitHub account (possibly a

strawman; I do have one). But it should be mentioned somewhere! The

experience can also be improved by conventions. For example, I'd like

the PRs that constitute proposals to come with a synopsis of the

proposal as the description, because the descriptions end up in the

notifications, whereas the actual commits do not. So to avoid having

to check every proposal on GitHub, such a synopsis would be useful.

Maybe this should be self-evident, but it's not mentioned in the

README document.



There's also the loss of threading mentioned elsewhere. I cannot say

how bad this is in practice (I delete GitHub notifications after

reading them). We can see in the libraries archive that for larger

proposals we often have several subthreads about different aspects of

the proposal (and I frequently skip over whole subthreads when I'm

not intersted the aspect under consideration).



I also find that with email it's easy to send a comment just to the

author (e.g. for typos). GitHub makes this harder (I suppose you /can/

open a ticket in the author's clone of the repo...).



And, obviously, there's resistance to change.



While we're comparing these things, what are the problems that the new

process is meant to solve?



Cheers,



Bertram

_______________________________________________

Libraries mailing list

[hidden email]

http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


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

Re: New Libraries Proposal process

amindfv@mailbox.org
In reply to this post by Haskell - Libraries mailing list
I'd like to +1 everything said here, and say as an observer it's strange to have the decision made privately and announced here as a fait accompli.

Another thing to note about email is that it's decentralized and has (and presumably always will have) plenty of clients and tools. I've seen discussions linking to email conversations that are significantly older than GitHub itself - there's value to archives of old discussions. If GitHub folds or starts charging money or redesigns its site in an unhelpful way, all discussion would be lost or made less accessible. Whereas mailing list archives can jump to new hosts indefinitely.

Tom


On Sat, Sep 12, 2020 at 03:44:10PM +0200, Bertram Felgenhauer via Libraries wrote:

> Carter Schonwald wrote:
> > Are you sure about this approach? I think you need to start with an
> > open discussion , And have a open ended thread about ideas for how to
> > improve how we do things.
>
> I totally agree with this, though fleshing out ideas in a smaller
> forum first is helpful.
>
> An important consideration here is that there are several types of
> stakeholders in the library proposal process, including
>
> * the CLC members, who ultimately decide on core library changes;
> * proponents ("authors"), who originate proposals for such changes;
>   and
> * observers ("the wider Haskell community"), users of the core
>   libraries who want to keep track of upcoming library changes and
>   chime in when a proposal affects their own uses of a library.
>
> I suspect that the observers are a silent majority, and that a mailing
> list with public archives is close to optimal for them. (I consider
> myself an observer and I do like the mailing list for precisely this
> reason. But I also grew up with mailing lists, not forums, so I'm
> surely biased here.)
>
> In any case I think that any change to the library proposal process
> should cater to all three types of stakeholders (and possibly others
> I have failed to think of). In its current form, I believe
>
>   https://github.com/haskell-core/core-libraries-proposals
>
> fails to do that for observers.
>
> Cheers,
>
> Bertram
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: New Libraries Proposal process

Ignat Insarov
I apologise for intrusion but I have a question.

I would like to ask if all this was ever supposed to work for simple
folk — a hobbyist or a small-time freelancer. _(I am that.)_ I tried
bringing up small _«proposals»_ on this list previously, such as
adding `\x → (x, x)` to `Data.Tuple`.[1] It was akin to throwing a
stone into a pond — there may be a splash, a few responses, but in the
end nothing is accomplished. On the other hand, bringing issues up on
the issue tracker of an individual package would result in a rebuttal
with a reference to the higher authority of the faceless crowd on the
mailing list.[2]

So now it looks like things are going to get even more industry and
research oriented, even less friendly to people of common standing.
Has any thought been given to that?

[1]: https://mail.haskell.org/pipermail/libraries/2019-July/029747.html
[2]: https://github.com/haskell/containers/issues/744


On Sun, 13 Sep 2020 at 04:26, [hidden email] <[hidden email]> wrote:

>
> I'd like to +1 everything said here, and say as an observer it's strange to have the decision made privately and announced here as a fait accompli.
>
> Another thing to note about email is that it's decentralized and has (and presumably always will have) plenty of clients and tools. I've seen discussions linking to email conversations that are significantly older than GitHub itself - there's value to archives of old discussions. If GitHub folds or starts charging money or redesigns its site in an unhelpful way, all discussion would be lost or made less accessible. Whereas mailing list archives can jump to new hosts indefinitely.
>
> Tom
>
>
> On Sat, Sep 12, 2020 at 03:44:10PM +0200, Bertram Felgenhauer via Libraries wrote:
> > Carter Schonwald wrote:
> > > Are you sure about this approach? I think you need to start with an
> > > open discussion , And have a open ended thread about ideas for how to
> > > improve how we do things.
> >
> > I totally agree with this, though fleshing out ideas in a smaller
> > forum first is helpful.
> >
> > An important consideration here is that there are several types of
> > stakeholders in the library proposal process, including
> >
> > * the CLC members, who ultimately decide on core library changes;
> > * proponents ("authors"), who originate proposals for such changes;
> >   and
> > * observers ("the wider Haskell community"), users of the core
> >   libraries who want to keep track of upcoming library changes and
> >   chime in when a proposal affects their own uses of a library.
> >
> > I suspect that the observers are a silent majority, and that a mailing
> > list with public archives is close to optimal for them. (I consider
> > myself an observer and I do like the mailing list for precisely this
> > reason. But I also grew up with mailing lists, not forums, so I'm
> > surely biased here.)
> >
> > In any case I think that any change to the library proposal process
> > should cater to all three types of stakeholders (and possibly others
> > I have failed to think of). In its current form, I believe
> >
> >   https://github.com/haskell-core/core-libraries-proposals
> >
> > fails to do that for observers.
> >
> > Cheers,
> >
> > Bertram
> > _______________________________________________
> > Libraries mailing list
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: New Libraries Proposal process

Haskell - Libraries mailing list
|  adding `\x → (x, x)` to `Data.Tuple`.[1] It was akin to throwing a
|  stone into a pond — there may be a splash, a few responses, but in the
|  end nothing is accomplished. 

That has indeed been a problem.  But the process Chessai has described should eliminate the problem.

* You write a short proposal (20 mins work)
* You submit it to the committee
* It lands on their machine-supported to-do list
* You should get a yes or no decision within the timescale
  specified by the process

So you throw in the stone, and something happens, even if it's "thank you but no".

|  So now it looks like things are going to get even more industry and
|  research oriented, even less friendly to people of common standing.
|  Has any thought been given to that?

You are not the only person who has expressed these sentiments.  These responses have made it clear that it's easy to interpret the proposed new process as adding new slow and bureaucratic overheads.  I think we should try to make clearer that, quite to the contrary, it's designed to make sure that every proposal gets timely attention.

Simon

|  -----Original Message-----
|  From: Libraries <[hidden email]> On Behalf Of Ignat Insarov
|  Sent: 16 September 2020 17:29
|  To: [hidden email]
|  Cc: Bertram Felgenhauer via Libraries <[hidden email]>
|  Subject: Re: New Libraries Proposal process
|  
|  I apologise for intrusion but I have a question.
|  
|  I would like to ask if all this was ever supposed to work for simple
|  folk — a hobbyist or a small-time freelancer. _(I am that.)_ I tried
|  bringing up small _«proposals»_ on this list previously, such as
|  adding `\x → (x, x)` to `Data.Tuple`.[1] It was akin to throwing a
|  stone into a pond — there may be a splash, a few responses, but in the
|  end nothing is accomplished. On the other hand, bringing issues up on
|  the issue tracker of an individual package would result in a rebuttal
|  with a reference to the higher authority of the faceless crowd on the
|  mailing list.[2]
|  
|  So now it looks like things are going to get even more industry and
|  research oriented, even less friendly to people of common standing.
|  Has any thought been given to that?
|  
|  [1]:
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske
|  ll.org%2Fpipermail%2Flibraries%2F2019-
|  July%2F029747.html&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C2ca841705125
|  4bd7205608d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373587055
|  20838463&amp;sdata=oTK%2Fkx6PaRa1jct92polqMfGddaqGZiIkyhIQaivSOg%3D&amp;rese
|  rved=0
|  [2]:
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com
|  %2Fhaskell%2Fcontainers%2Fissues%2F744&amp;data=02%7C01%7Csimonpj%40microsof
|  t.com%7C2ca8417051254bd7205608d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%
|  7C1%7C0%7C637358705520838463&amp;sdata=U6iXUJLRGktuwTrO5bwX4HwmKrR1rAdoPEsBZ
|  bPdJd0%3D&amp;reserved=0
|  
|  
|  On Sun, 13 Sep 2020 at 04:26, [hidden email] <[hidden email]>
|  wrote:
|  >
|  > I'd like to +1 everything said here, and say as an observer it's strange
|  to have the decision made privately and announced here as a fait accompli.
|  >
|  > Another thing to note about email is that it's decentralized and has (and
|  presumably always will have) plenty of clients and tools. I've seen
|  discussions linking to email conversations that are significantly older than
|  GitHub itself - there's value to archives of old discussions. If GitHub
|  folds or starts charging money or redesigns its site in an unhelpful way,
|  all discussion would be lost or made less accessible. Whereas mailing list
|  archives can jump to new hosts indefinitely.
|  >
|  > Tom
|  >
|  >
|  > On Sat, Sep 12, 2020 at 03:44:10PM +0200, Bertram Felgenhauer via
|  Libraries wrote:
|  > > Carter Schonwald wrote:
|  > > > Are you sure about this approach? I think you need to start with an
|  > > > open discussion , And have a open ended thread about ideas for how to
|  > > > improve how we do things.
|  > >
|  > > I totally agree with this, though fleshing out ideas in a smaller
|  > > forum first is helpful.
|  > >
|  > > An important consideration here is that there are several types of
|  > > stakeholders in the library proposal process, including
|  > >
|  > > * the CLC members, who ultimately decide on core library changes;
|  > > * proponents ("authors"), who originate proposals for such changes;
|  > >   and
|  > > * observers ("the wider Haskell community"), users of the core
|  > >   libraries who want to keep track of upcoming library changes and
|  > >   chime in when a proposal affects their own uses of a library.
|  > >
|  > > I suspect that the observers are a silent majority, and that a mailing
|  > > list with public archives is close to optimal for them. (I consider
|  > > myself an observer and I do like the mailing list for precisely this
|  > > reason. But I also grew up with mailing lists, not forums, so I'm
|  > > surely biased here.)
|  > >
|  > > In any case I think that any change to the library proposal process
|  > > should cater to all three types of stakeholders (and possibly others
|  > > I have failed to think of). In its current form, I believe
|  > >
|  > >
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com
|  %2Fhaskell-core%2Fcore-libraries-
|  proposals&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C2ca8417051254bd720560
|  8d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358705520838463&
|  amp;sdata=bOP4zOD6oPG8p5EnSJPr2EeTFGWfMrggpYrLVmS9xgA%3D&amp;reserved=0
|  > >
|  > > fails to do that for observers.
|  > >
|  > > Cheers,
|  > >
|  > > Bertram
|  > > _______________________________________________
|  > > Libraries mailing list
|  > > [hidden email]
|  > >
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel
|  l.org%2Fcgi-
|  bin%2Fmailman%2Flistinfo%2Flibraries&amp;data=02%7C01%7Csimonpj%40microsoft.
|  com%7C2ca8417051254bd7205608d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%7C
|  1%7C0%7C637358705520838463&amp;sdata=htbnzKwMR22jhgKRrkWWH%2BS4KQfHs5rKsJ%2F
|  TCoXp9CI%3D&amp;reserved=0
|  > _______________________________________________
|  > Libraries mailing list
|  > [hidden email]
|  >
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel
|  l.org%2Fcgi-
|  bin%2Fmailman%2Flistinfo%2Flibraries&amp;data=02%7C01%7Csimonpj%40microsoft.
|  com%7C2ca8417051254bd7205608d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%7C
|  1%7C0%7C637358705520838463&amp;sdata=htbnzKwMR22jhgKRrkWWH%2BS4KQfHs5rKsJ%2F
|  TCoXp9CI%3D&amp;reserved=0
|  _______________________________________________
|  Libraries mailing list
|  [hidden email]
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel
|  l.org%2Fcgi-
|  bin%2Fmailman%2Flistinfo%2Flibraries&amp;data=02%7C01%7Csimonpj%40microsoft.
|  com%7C2ca8417051254bd7205608d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%7C
|  1%7C0%7C637358705520838463&amp;sdata=htbnzKwMR22jhgKRrkWWH%2BS4KQfHs5rKsJ%2F
|  TCoXp9CI%3D&amp;reserved=0
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Regarding dupe Re: New Libraries Proposal process

Carter Schonwald
I think wrt to the dup/dupe proposal the answer at the time was nope.  
1) there wasn’t a clear name that wouldn’t collide with user code 

2) it wasn’t clear that it provided new expressive power / reduced complexity.  

To be clear, there’s a higher bar for adding / changing exports of preexisting modules, and preexisting wide spread conventions in programming practice is often a good way to motivate including such operations. Or that it adds a meaningful abstraction that helps all users.  

Also there didn’t seem to be much wide spread support in the discussion that followed. 

@simon : that process doesn’t have clear buy in by those who participate actively in the libraries ecosystem. And raises questions around 

1) I don’t think we have enough volunteer effort to actually manage / support Such a process (it’s tantamount to expecting full time professionalization expectations for libraries core contrib... which I think our community and industrial sponsorship isn’t large enough to facilitate.  ). Plus that dramatically increases the participation expectations / requirements from clc members. 

2) it creates authority that frankly clc did not have before. (Ed and others who have been part of clc historically  please correct me if I’m wrong).  Clc is supposed to be a facilitator and tie breaker and guider of evolution of base and a mechanisms for engaging in community consensus of how to improve important libraries.  

3) if we are to have an entity which we will call clc but WILL have more authority than being a Coordination point for community collab and agreement, I strongly suggest we ground this in what a reboot with a more open selection / participation structure as guards / rail posts to ensure Adequate  community representation and enablement.  All authority is a social construct, and frankly if we are giving these leadership elements more formal authority there needs to be bylaws or other such structure to make sure process and communication function and accountability exists. 

On Wed, Sep 16, 2020 at 12:40 PM Simon Peyton Jones via Libraries <[hidden email]> wrote:
|  adding `\x → (x, x)` to `Data.Tuple`.[1] It was akin to throwing a

|  stone into a pond — there may be a splash, a few responses, but in the

|  end nothing is accomplished. 



That has indeed been a problem.  But the process Chessai has described should eliminate the problem.



* You write a short proposal (20 mins work)

* You submit it to the committee

* It lands on their machine-supported to-do list

* You should get a yes or no decision within the timescale

  specified by the process



So you throw in the stone, and something happens, even if it's "thank you but no".



|  So now it looks like things are going to get even more industry and

|  research oriented, even less friendly to people of common standing.

|  Has any thought been given to that?



You are not the only person who has expressed these sentiments.  These responses have made it clear that it's easy to interpret the proposed new process as adding new slow and bureaucratic overheads.  I think we should try to make clearer that, quite to the contrary, it's designed to make sure that every proposal gets timely attention.



Simon



|  -----Original Message-----

|  From: Libraries <[hidden email]> On Behalf Of Ignat Insarov

|  Sent: 16 September 2020 17:29

|  To: [hidden email]

|  Cc: Bertram Felgenhauer via Libraries <[hidden email]>

|  Subject: Re: New Libraries Proposal process



|  I apologise for intrusion but I have a question.



|  I would like to ask if all this was ever supposed to work for simple

|  folk — a hobbyist or a small-time freelancer. _(I am that.)_ I tried

|  bringing up small _«proposals»_ on this list previously, such as

|  adding `\x → (x, x)` to `Data.Tuple`.[1] It was akin to throwing a

|  stone into a pond — there may be a splash, a few responses, but in the

|  end nothing is accomplished. On the other hand, bringing issues up on

|  the issue tracker of an individual package would result in a rebuttal

|  with a reference to the higher authority of the faceless crowd on the

|  mailing list.[2]



|  So now it looks like things are going to get even more industry and

|  research oriented, even less friendly to people of common standing.

|  Has any thought been given to that?



|  [1]:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske

ll.org%2Fpipermail%2Flibraries%2F2019-

|  July%2F029747.html&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C2ca841705125

|  4bd7205608d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373587055

|  20838463&amp;sdata=oTK%2Fkx6PaRa1jct92polqMfGddaqGZiIkyhIQaivSOg%3D&amp;rese

|  rved=0

|  [2]:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com

|  %2Fhaskell%2Fcontainers%2Fissues%2F744&amp;data=02%7C01%7Csimonpj%40microsof

t.com%7C2ca8417051254bd7205608d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%

|  7C1%7C0%7C637358705520838463&amp;sdata=U6iXUJLRGktuwTrO5bwX4HwmKrR1rAdoPEsBZ

|  bPdJd0%3D&amp;reserved=0





|  On Sun, 13 Sep 2020 at 04:26, [hidden email] <[hidden email]>

|  wrote:

|  >

|  > I'd like to +1 everything said here, and say as an observer it's strange

|  to have the decision made privately and announced here as a fait accompli.

|  >

|  > Another thing to note about email is that it's decentralized and has (and

|  presumably always will have) plenty of clients and tools. I've seen

|  discussions linking to email conversations that are significantly older than

|  GitHub itself - there's value to archives of old discussions. If GitHub

|  folds or starts charging money or redesigns its site in an unhelpful way,

|  all discussion would be lost or made less accessible. Whereas mailing list

|  archives can jump to new hosts indefinitely.

|  >

|  > Tom

|  >

|  >

|  > On Sat, Sep 12, 2020 at 03:44:10PM +0200, Bertram Felgenhauer via

|  Libraries wrote:

|  > > Carter Schonwald wrote:

|  > > > Are you sure about this approach? I think you need to start with an

|  > > > open discussion , And have a open ended thread about ideas for how to

|  > > > improve how we do things.

|  > >

|  > > I totally agree with this, though fleshing out ideas in a smaller

|  > > forum first is helpful.

|  > >

|  > > An important consideration here is that there are several types of

|  > > stakeholders in the library proposal process, including

|  > >

|  > > * the CLC members, who ultimately decide on core library changes;

|  > > * proponents ("authors"), who originate proposals for such changes;

|  > >   and

|  > > * observers ("the wider Haskell community"), users of the core

|  > >   libraries who want to keep track of upcoming library changes and

|  > >   chime in when a proposal affects their own uses of a library.

|  > >

|  > > I suspect that the observers are a silent majority, and that a mailing

|  > > list with public archives is close to optimal for them. (I consider

|  > > myself an observer and I do like the mailing list for precisely this

|  > > reason. But I also grew up with mailing lists, not forums, so I'm

|  > > surely biased here.)

|  > >

|  > > In any case I think that any change to the library proposal process

|  > > should cater to all three types of stakeholders (and possibly others

|  > > I have failed to think of). In its current form, I believe

|  > >

|  > >

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com

|  %2Fhaskell-core%2Fcore-libraries-

|  proposals&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C2ca8417051254bd720560

|  8d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358705520838463&

|  amp;sdata=bOP4zOD6oPG8p5EnSJPr2EeTFGWfMrggpYrLVmS9xgA%3D&amp;reserved=0

|  > >

|  > > fails to do that for observers.

|  > >

|  > > Cheers,

|  > >

|  > > Bertram

|  > > _______________________________________________

|  > > Libraries mailing list

|  > > [hidden email]

|  > >

https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel

l.org%2Fcgi-

|  bin%2Fmailman%2Flistinfo%2Flibraries&amp;data=02%7C01%7Csimonpj%40microsoft.

|  com%7C2ca8417051254bd7205608d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%7C

|  1%7C0%7C637358705520838463&amp;sdata=htbnzKwMR22jhgKRrkWWH%2BS4KQfHs5rKsJ%2F

|  TCoXp9CI%3D&amp;reserved=0

|  > _______________________________________________

|  > Libraries mailing list

|  > [hidden email]

|  >

https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel

l.org%2Fcgi-

|  bin%2Fmailman%2Flistinfo%2Flibraries&amp;data=02%7C01%7Csimonpj%40microsoft.

|  com%7C2ca8417051254bd7205608d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%7C

|  1%7C0%7C637358705520838463&amp;sdata=htbnzKwMR22jhgKRrkWWH%2BS4KQfHs5rKsJ%2F

|  TCoXp9CI%3D&amp;reserved=0

|  _______________________________________________

|  Libraries mailing list

[hidden email]

https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel

l.org%2Fcgi-

|  bin%2Fmailman%2Flistinfo%2Flibraries&amp;data=02%7C01%7Csimonpj%40microsoft.

|  com%7C2ca8417051254bd7205608d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%7C

|  1%7C0%7C637358705520838463&amp;sdata=htbnzKwMR22jhgKRrkWWH%2BS4KQfHs5rKsJ%2F

|  TCoXp9CI%3D&amp;reserved=0

_______________________________________________

Libraries mailing list

[hidden email]

http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries