Regarding dupe Re: New Libraries Proposal process
Carter Schonwald
carter.schonwald at gmail.com
Wed Sep 16 17:14:46 UTC 2020
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 <
libraries at haskell.org> 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 <libraries-bounces at haskell.org> On Behalf Of Ignat
> Insarov
>
> | Sent: 16 September 2020 17:29
>
> | To: amindfv at mailbox.org
>
> | Cc: Bertram Felgenhauer via Libraries <libraries at haskell.org>
>
> | 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&data=02%7C01%7Csimonpj%40microsoft.com
> %7C2ca841705125
>
> |
> 4bd7205608d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373587055
>
> |
> 20838463&sdata=oTK%2Fkx6PaRa1jct92polqMfGddaqGZiIkyhIQaivSOg%3D&rese
>
> | rved=0
>
> | [2]:
>
> |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com
>
> |
> %2Fhaskell%2Fcontainers%2Fissues%2F744&data=02%7C01%7Csimonpj%40microsof
>
> | t.com
> %7C2ca8417051254bd7205608d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%
>
> |
> 7C1%7C0%7C637358705520838463&sdata=U6iXUJLRGktuwTrO5bwX4HwmKrR1rAdoPEsBZ
>
> | bPdJd0%3D&reserved=0
>
> |
>
> |
>
> | On Sun, 13 Sep 2020 at 04:26, amindfv at mailbox.org <amindfv at mailbox.org>
>
> | 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&data=02%7C01%7Csimonpj%40microsoft.com
> %7C2ca8417051254bd720560
>
> |
> 8d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358705520838463&
>
> | amp;sdata=bOP4zOD6oPG8p5EnSJPr2EeTFGWfMrggpYrLVmS9xgA%3D&reserved=0
>
> | > >
>
> | > > fails to do that for observers.
>
> | > >
>
> | > > Cheers,
>
> | > >
>
> | > > Bertram
>
> | > > _______________________________________________
>
> | > > Libraries mailing list
>
> | > > Libraries at haskell.org
>
> | > >
>
> |
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel
>
> | l.org%2Fcgi-
>
> |
> bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Csimonpj%40microsoft.
>
> |
> com%7C2ca8417051254bd7205608d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%7C
>
> |
> 1%7C0%7C637358705520838463&sdata=htbnzKwMR22jhgKRrkWWH%2BS4KQfHs5rKsJ%2F
>
> | TCoXp9CI%3D&reserved=0
>
> | > _______________________________________________
>
> | > Libraries mailing list
>
> | > Libraries at haskell.org
>
> | >
>
> |
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel
>
> | l.org%2Fcgi-
>
> |
> bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Csimonpj%40microsoft.
>
> |
> com%7C2ca8417051254bd7205608d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%7C
>
> |
> 1%7C0%7C637358705520838463&sdata=htbnzKwMR22jhgKRrkWWH%2BS4KQfHs5rKsJ%2F
>
> | TCoXp9CI%3D&reserved=0
>
> | _______________________________________________
>
> | Libraries mailing list
>
> | Libraries at haskell.org
>
> |
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel
>
> | l.org%2Fcgi-
>
> |
> bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Csimonpj%40microsoft.
>
> |
> com%7C2ca8417051254bd7205608d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%7C
>
> |
> 1%7C0%7C637358705520838463&sdata=htbnzKwMR22jhgKRrkWWH%2BS4KQfHs5rKsJ%2F
>
> | TCoXp9CI%3D&reserved=0
>
> _______________________________________________
>
> Libraries mailing list
>
> Libraries at haskell.org
>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200916/4c91ae82/attachment.html>
More information about the Libraries
mailing list