Proposal: Expanding the CLC

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

Proposal: Expanding the CLC

Emily Pillmore
Hi All,

Over the past year, two things have become increasingly clear to me as I've carried out my CLC duties:


1. The CLC is under-resourced. This is evidenced by the fact that several maintainers who are not CLC members have been forced to step up to help take on some of the maintenance burden for many of the CLC libraries. Namely, `vector`, `bytestring`, `random`, `unix`, and more. The current CLC head count is not enough to dedicate at least one maintainer per package, which is leading to us all being spread thin, and the less-loved packages are falling into disrepair as a result. Couple this with the fact that roughly half the CLC do not have these packages actively within their maintenance cycles, and we arrive at the current problem.

2. The current set of "core" libraries does not cover what is generally considered "core" in the community. From now on, I'll refer to "core" packages as "boot" packages, and identify core packages to be those that are have proven to be incredibly popular tools for building things in Haskell. For example `zlib`, `parsec`, `regex-base`, `regex-posix`, `network`, etc. In particular, if any of these core packages saw their current authors disappear, or incapacitated in any sense, it would seriously harm the Haskell ecosystem. `cabal-install`, for example, requires several of those packages as upstream dependencies. Currently, we are dealing with this nightmare situation where work is stalled across many packages due to a particular set of maintainers being very difficult to reach, one of whom having disappeared completely for all maintenance intents and purposes.

Ergo, we have a problem. Thankfully, many people have stepped up showing renewed interest in maintaining such packages with the latest crop of CLC folks, and this poses an interesting opportunity.

My proposal is this:

1. We expand the CLC from 9 members to 22 members such that we have at least 1 CLC maintainer per boot package. There are a large number of fantastic candidates already available, who would be perfect for the role. In fact, many of the candidates whom we would ask are already maintaining these packages. In particular, Andrew Lelechenko, Simon Jakobi, Viktor Dukhovni, Dominic Steinitz, Alexey Khuedyakov are already serving within this role (and thank you for it!). Andreas Abel has also offered to help take on one of the core packages.

2. We consider a dedicated "Haskell Action Team" (name and idea courtesy of Carter Schonwald) to oversee packages in the Haskell github repo that can act as supplementary maintainers for many of the core packages contained therein. Currently, there are many in need of help. `zlib` comes to mind, which is currently blocking `bytestring-0.11` migration work due to having no available maintainer with the permissions to do a release. This, in turn, is stalling `cabal-install`. Short of taking over the package, we would have to ask for an emergency Hackage release if the neither maintainer shows up to do it in a reasonable time frame.

This is just one step towards helping ease the burden of maintenance of so-called core and boot packages. I hope you agree that this is a good idea, and if we get enough thumbs up, then Chessai and I will draw up the necessary changes to the CLC remit and we'll get started!

Cheers,
Emily


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

Re: Proposal: Expanding the CLC

Carter Schonwald
These are good points

I think this is actually 3-5  points: 


CLC  related 
1) clc authority is strictly about leadership for helping make design decisions for base the package 

2) clc is meant to be a fallback to ensure that there’s backup continuity for maintainership of ghc boot libraries and a design aid for Haskell library authors who are the current maintainers. 

But as long as the current maintainership is reachable for communication, the maintainer has final authority. 
— the clc violated this in spring 2020, while there were car burnings in the neighborhood of the maintainer in question . Bad taste. 

3) peripherically clc via base maintainership is the design authority for the library section of the Haskell standard.  

—- point being: if you’re not contributing to design decisions for base.  you shouldn’t be on the clc.  If you are, then you should perhaps be on clc.  The current makeup of the clc does not reflect that.  

— further more , growing clc should be a reflection of contributors being recognized for their design/hackery contribs 

HAT related
4) the idea/goal of hat: empowering and supporting active contributors while not saddling them with official commitments. Rather, HAT is about somone (myself initially), acting as a shield to support current active contributors to enable them to act with greater confidence. I like to think  I helped enable that with some of the folks emily mentioned, especially Simon jakobi, viktor and Andrew L.  

On Thu, Feb 11, 2021 at 6:54 PM Emily Pillmore <[hidden email]> wrote:
Hi All,

Over the past year, two things have become increasingly clear to me as I've carried out my CLC duties:


1. The CLC is under-resourced. This is evidenced by the fact that several maintainers who are not CLC members have been forced to step up to help take on some of the maintenance burden for many of the CLC libraries. Namely, `vector`, `bytestring`, `random`, `unix`, and more. The current CLC head count is not enough to dedicate at least one maintainer per package, which is leading to us all being spread thin, and the less-loved packages are falling into disrepair as a result. Couple this with the fact that roughly half the CLC do not have these packages actively within their maintenance cycles, and we arrive at the current problem.

2. The current set of "core" libraries does not cover what is generally considered "core" in the community. From now on, I'll refer to "core" packages as "boot" packages, and identify core packages to be those that are have proven to be incredibly popular tools for building things in Haskell. For example `zlib`, `parsec`, `regex-base`, `regex-posix`, `network`, etc. In particular, if any of these core packages saw their current authors disappear, or incapacitated in any sense, it would seriously harm the Haskell ecosystem. `cabal-install`, for example, requires several of those packages as upstream dependencies. Currently, we are dealing with this nightmare situation where work is stalled across many packages due to a particular set of maintainers being very difficult to reach, one of whom having disappeared completely for all maintenance intents and purposes.

Ergo, we have a problem. Thankfully, many people have stepped up showing renewed interest in maintaining such packages with the latest crop of CLC folks, and this poses an interesting opportunity.

My proposal is this:

1. We expand the CLC from 9 members to 22 members such that we have at least 1 CLC maintainer per boot package. There are a large number of fantastic candidates already available, who would be perfect for the role. In fact, many of the candidates whom we would ask are already maintaining these packages. In particular, Andrew Lelechenko, Simon Jakobi, Viktor Dukhovni, Dominic Steinitz, Alexey Khuedyakov are already serving within this role (and thank you for it!). Andreas Abel has also offered to help take on one of the core packages.

2. We consider a dedicated "Haskell Action Team" (name and idea courtesy of Carter Schonwald) to oversee packages in the Haskell github repo that can act as supplementary maintainers for many of the core packages contained therein. Currently, there are many in need of help. `zlib` comes to mind, which is currently blocking `bytestring-0.11` migration work due to having no available maintainer with the permissions to do a release. This, in turn, is stalling `cabal-install`. Short of taking over the package, we would have to ask for an emergency Hackage release if the neither maintainer shows up to do it in a reasonable time frame.

This is just one step towards helping ease the burden of maintenance of so-called core and boot packages. I hope you agree that this is a good idea, and if we get enough thumbs up, then Chessai and I will draw up the necessary changes to the CLC remit and we'll get started!

Cheers,
Emily

_______________________________________________
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: Proposal: Expanding the CLC

Carter Schonwald
I guess my main point is that this mailing list reflects and via predating clc, defines what clc is for.  

And rather than scope creep a single responsibility, articulating that need and facilitating is as a distinct entity is valuable.  My idea with HAT is like a modern volunteer organizing touch point of Ye olde Haskell janitors, with each year some different set of folks who were active the previous year as new leadership/organizing touch points for helping facilitate active contributors the subsequent year.  Designing for churn to stay fresh as a different take than how we’ve done many of these entity’s for Haskell.  

Actual Maintainer-ship  responsibility should not be via Hat (at least as I envision it), though supporting and empowering active contributors may happily result in some of them being contrib i/ comaintainer. 

Equally important: library maintainers being responsive about bug fixes is important. Just as important is allowing them agency to evolve the Libs they maintain.  I do worry that some Libs that fall under clc atm / as of the spring are likely to never have serious evolution / improvement. But that’s a different issue. 

On Thu, Feb 11, 2021 at 7:13 PM Carter Schonwald <[hidden email]> wrote:
These are good points

I think this is actually 3-5  points: 


CLC  related 
1) clc authority is strictly about leadership for helping make design decisions for base the package 

2) clc is meant to be a fallback to ensure that there’s backup continuity for maintainership of ghc boot libraries and a design aid for Haskell library authors who are the current maintainers. 

But as long as the current maintainership is reachable for communication, the maintainer has final authority. 
— the clc violated this in spring 2020, while there were car burnings in the neighborhood of the maintainer in question . Bad taste. 

3) peripherically clc via base maintainership is the design authority for the library section of the Haskell standard.  

—- point being: if you’re not contributing to design decisions for base.  you shouldn’t be on the clc.  If you are, then you should perhaps be on clc.  The current makeup of the clc does not reflect that.  

— further more , growing clc should be a reflection of contributors being recognized for their design/hackery contribs 

HAT related
4) the idea/goal of hat: empowering and supporting active contributors while not saddling them with official commitments. Rather, HAT is about somone (myself initially), acting as a shield to support current active contributors to enable them to act with greater confidence. I like to think  I helped enable that with some of the folks emily mentioned, especially Simon jakobi, viktor and Andrew L.  

On Thu, Feb 11, 2021 at 6:54 PM Emily Pillmore <[hidden email]> wrote:
Hi All,

Over the past year, two things have become increasingly clear to me as I've carried out my CLC duties:


1. The CLC is under-resourced. This is evidenced by the fact that several maintainers who are not CLC members have been forced to step up to help take on some of the maintenance burden for many of the CLC libraries. Namely, `vector`, `bytestring`, `random`, `unix`, and more. The current CLC head count is not enough to dedicate at least one maintainer per package, which is leading to us all being spread thin, and the less-loved packages are falling into disrepair as a result. Couple this with the fact that roughly half the CLC do not have these packages actively within their maintenance cycles, and we arrive at the current problem.

2. The current set of "core" libraries does not cover what is generally considered "core" in the community. From now on, I'll refer to "core" packages as "boot" packages, and identify core packages to be those that are have proven to be incredibly popular tools for building things in Haskell. For example `zlib`, `parsec`, `regex-base`, `regex-posix`, `network`, etc. In particular, if any of these core packages saw their current authors disappear, or incapacitated in any sense, it would seriously harm the Haskell ecosystem. `cabal-install`, for example, requires several of those packages as upstream dependencies. Currently, we are dealing with this nightmare situation where work is stalled across many packages due to a particular set of maintainers being very difficult to reach, one of whom having disappeared completely for all maintenance intents and purposes.

Ergo, we have a problem. Thankfully, many people have stepped up showing renewed interest in maintaining such packages with the latest crop of CLC folks, and this poses an interesting opportunity.

My proposal is this:

1. We expand the CLC from 9 members to 22 members such that we have at least 1 CLC maintainer per boot package. There are a large number of fantastic candidates already available, who would be perfect for the role. In fact, many of the candidates whom we would ask are already maintaining these packages. In particular, Andrew Lelechenko, Simon Jakobi, Viktor Dukhovni, Dominic Steinitz, Alexey Khuedyakov are already serving within this role (and thank you for it!). Andreas Abel has also offered to help take on one of the core packages.

2. We consider a dedicated "Haskell Action Team" (name and idea courtesy of Carter Schonwald) to oversee packages in the Haskell github repo that can act as supplementary maintainers for many of the core packages contained therein. Currently, there are many in need of help. `zlib` comes to mind, which is currently blocking `bytestring-0.11` migration work due to having no available maintainer with the permissions to do a release. This, in turn, is stalling `cabal-install`. Short of taking over the package, we would have to ask for an emergency Hackage release if the neither maintainer shows up to do it in a reasonable time frame.

This is just one step towards helping ease the burden of maintenance of so-called core and boot packages. I hope you agree that this is a good idea, and if we get enough thumbs up, then Chessai and I will draw up the necessary changes to the CLC remit and we'll get started!

Cheers,
Emily

_______________________________________________
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: Proposal: Expanding the CLC

Julian Ospald
In reply to this post by Emily Pillmore
Hi,

my opinion is that we should develop a zero tolerance towards unresponsive maintainership.

Contributors shouldn't have to escalate on the ML and shouldn't have to request package takeovers. These things are awkward and require more dedication than necessary to be a valuable co-maintainer.

The CLC should proactively scan for popular packages that require new maintainer juice, contact the current maintainers and call for help on the ML (whether core/boot/something-else doesn't really matter to me... redefine the CLC competencies if you must).

I've had many PRs over the years that took 6-12 months for a response. This is not an acceptable response time.

Cheers,
Julian

On February 11, 2021 11:54:19 PM UTC, Emily Pillmore <[hidden email]> wrote:
Hi All,

Over the past year, two things have become increasingly clear to me as I've carried out my CLC duties:


1. The CLC is under-resourced. This is evidenced by the fact that several maintainers who are not CLC members have been forced to step up to help take on some of the maintenance burden for many of the CLC libraries. Namely, `vector`, `bytestring`, `random`, `unix`, and more. The current CLC head count is not enough to dedicate at least one maintainer per package, which is leading to us all being spread thin, and the less-loved packages are falling into disrepair as a result. Couple this with the fact that roughly half the CLC do not have these packages actively within their maintenance cycles, and we arrive at the current problem.

2. The current set of "core" libraries does not cover what is generally considered "core" in the community. From now on, I'll refer to "core" packages as "boot" packages, and identify core packages to be those that are have proven to be incredibly popular tools for building things in Haskell. For example `zlib`, `parsec`, `regex-base`, `regex-posix`, `network`, etc. In particular, if any of these core packages saw their current authors disappear, or incapacitated in any sense, it would seriously harm the Haskell ecosystem. `cabal-install`, for example, requires several of those packages as upstream dependencies. Currently, we are dealing with this nightmare situation where work is stalled across many packages due to a particular set of maintainers being very difficult to reach, one of whom having disappeared completely for all maintenance intents and purposes.

Ergo, we have a problem. Thankfully, many people have stepped up showing renewed interest in maintaining such packages with the latest crop of CLC folks, and this poses an interesting opportunity.

My proposal is this:

1. We expand the CLC from 9 members to 22 members such that we have at least 1 CLC maintainer per boot package. There are a large number of fantastic candidates already available, who would be perfect for the role. In fact, many of the candidates whom we would ask are already maintaining these packages. In particular, Andrew Lelechenko, Simon Jakobi, Viktor Dukhovni, Dominic Steinitz, Alexey Khuedyakov are already serving within this role (and thank you for it!). Andreas Abel has also offered to help take on one of the core packages.

2. We consider a dedicated "Haskell Action Team" (name and idea courtesy of Carter Schonwald) to oversee packages in the Haskell github repo that can act as supplementary maintainers for many of the core packages contained therein. Currently, there are many in need of help. `zlib` comes to mind, which is currently blocking `bytestring-0.11` migration work due to having no available maintainer with the permissions to do a release. This, in turn, is stalling `cabal-install`. Short of taking over the package, we would have to ask for an emergency Hackage release if the neither maintainer shows up to do it in a reasonable time frame.

This is just one step towards helping ease the burden of maintenance of so-called core and boot packages. I hope you agree that this is a good idea, and if we get enough thumbs up, then Chessai and I will draw up the necessary changes to the CLC remit and we'll get started!

Cheers,
Emily


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

Re: Proposal: Expanding the CLC

Oleg Grenrus
In reply to this post by Emily Pillmore

Re: Short of taking over the package, we would have to ask for an emergency Hackage release if the neither maintainer shows up to do it in a reasonable time frame.

These are non-maintainer uploads and is a job of Hackage Trustees (for all of Hackage, not only some "better" packages). https://github.com/haskell-infra/hackage-trustees/blob/master/policy.md#3-source-changes-simple-patches

Anyone can prepare the patch.

- Oleg

On 12.2.2021 1.54, Emily Pillmore wrote:
Hi All,

Over the past year, two things have become increasingly clear to me as I've carried out my CLC duties:


1. The CLC is under-resourced. This is evidenced by the fact that several maintainers who are not CLC members have been forced to step up to help take on some of the maintenance burden for many of the CLC libraries. Namely, `vector`, `bytestring`, `random`, `unix`, and more. The current CLC head count is not enough to dedicate at least one maintainer per package, which is leading to us all being spread thin, and the less-loved packages are falling into disrepair as a result. Couple this with the fact that roughly half the CLC do not have these packages actively within their maintenance cycles, and we arrive at the current problem.

2. The current set of "core" libraries does not cover what is generally considered "core" in the community. From now on, I'll refer to "core" packages as "boot" packages, and identify core packages to be those that are have proven to be incredibly popular tools for building things in Haskell. For example `zlib`, `parsec`, `regex-base`, `regex-posix`, `network`, etc. In particular, if any of these core packages saw their current authors disappear, or incapacitated in any sense, it would seriously harm the Haskell ecosystem. `cabal-install`, for example, requires several of those packages as upstream dependencies. Currently, we are dealing with this nightmare situation where work is stalled across many packages due to a particular set of maintainers being very difficult to reach, one of whom having disappeared completely for all maintenance intents and purposes.

Ergo, we have a problem. Thankfully, many people have stepped up showing renewed interest in maintaining such packages with the latest crop of CLC folks, and this poses an interesting opportunity.

My proposal is this:

1. We expand the CLC from 9 members to 22 members such that we have at least 1 CLC maintainer per boot package. There are a large number of fantastic candidates already available, who would be perfect for the role. In fact, many of the candidates whom we would ask are already maintaining these packages. In particular, Andrew Lelechenko, Simon Jakobi, Viktor Dukhovni, Dominic Steinitz, Alexey Khuedyakov are already serving within this role (and thank you for it!). Andreas Abel has also offered to help take on one of the core packages.

2. We consider a dedicated "Haskell Action Team" (name and idea courtesy of Carter Schonwald) to oversee packages in the Haskell github repo that can act as supplementary maintainers for many of the core packages contained therein. Currently, there are many in need of help. `zlib` comes to mind, which is currently blocking `bytestring-0.11` migration work due to having no available maintainer with the permissions to do a release. This, in turn, is stalling `cabal-install`. Short of taking over the package, we would have to ask for an emergency Hackage release if the neither maintainer shows up to do it in a reasonable time frame.

This is just one step towards helping ease the burden of maintenance of so-called core and boot packages. I hope you agree that this is a good idea, and if we get enough thumbs up, then Chessai and I will draw up the necessary changes to the CLC remit and we'll get started!

Cheers,
Emily


_______________________________________________
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: Proposal: Expanding the CLC

John Ericson-2
In reply to this post by Julian Ospald

Yeah I strongly agree with the sentiments here, and the concrete measures. Thank you, Emily, for proposing them.

I assume some people will be worried about undermining the prerogative of individual maintainers. My view is this *not* a good reason to "hold the CLC back". A bit off topic, but In the long term, I am optimistic for technical solutions to make dealing with libraries and versions, alternative ecosystems, etc. easier. Basically I want it all---both collaborative ownership and authorship, and healthy decentralized experimentation---and I think that's possible.

John

On 2/12/21 1:46 AM, Julian Ospald wrote:
Hi,

my opinion is that we should develop a zero tolerance towards unresponsive maintainership.

Contributors shouldn't have to escalate on the ML and shouldn't have to request package takeovers. These things are awkward and require more dedication than necessary to be a valuable co-maintainer.

The CLC should proactively scan for popular packages that require new maintainer juice, contact the current maintainers and call for help on the ML (whether core/boot/something-else doesn't really matter to me... redefine the CLC competencies if you must).

I've had many PRs over the years that took 6-12 months for a response. This is not an acceptable response time.

Cheers,
Julian

On February 11, 2021 11:54:19 PM UTC, Emily Pillmore [hidden email] wrote:
Hi All,

Over the past year, two things have become increasingly clear to me as I've carried out my CLC duties:


1. The CLC is under-resourced. This is evidenced by the fact that several maintainers who are not CLC members have been forced to step up to help take on some of the maintenance burden for many of the CLC libraries. Namely, `vector`, `bytestring`, `random`, `unix`, and more. The current CLC head count is not enough to dedicate at least one maintainer per package, which is leading to us all being spread thin, and the less-loved packages are falling into disrepair as a result. Couple this with the fact that roughly half the CLC do not have these packages actively within their maintenance cycles, and we arrive at the current problem.

2. The current set of "core" libraries does not cover what is generally considered "core" in the community. From now on, I'll refer to "core" packages as "boot" packages, and identify core packages to be those that are have proven to be incredibly popular tools for building things in Haskell. For example `zlib`, `parsec`, `regex-base`, `regex-posix`, `network`, etc. In particular, if any of these core packages saw their current authors disappear, or incapacitated in any sense, it would seriously harm the Haskell ecosystem. `cabal-install`, for example, requires several of those packages as upstream dependencies. Currently, we are dealing with this nightmare situation where work is stalled across many packages due to a particular set of maintainers being very difficult to reach, one of whom having disappeared completely for all maintenance intents and purposes.

Ergo, we have a problem. Thankfully, many people have stepped up showing renewed interest in maintaining such packages with the latest crop of CLC folks, and this poses an interesting opportunity.

My proposal is this:

1. We expand the CLC from 9 members to 22 members such that we have at least 1 CLC maintainer per boot package. There are a large number of fantastic candidates already available, who would be perfect for the role. In fact, many of the candidates whom we would ask are already maintaining these packages. In particular, Andrew Lelechenko, Simon Jakobi, Viktor Dukhovni, Dominic Steinitz, Alexey Khuedyakov are already serving within this role (and thank you for it!). Andreas Abel has also offered to help take on one of the core packages.

2. We consider a dedicated "Haskell Action Team" (name and idea courtesy of Carter Schonwald) to oversee packages in the Haskell github repo that can act as supplementary maintainers for many of the core packages contained therein. Currently, there are many in need of help. `zlib` comes to mind, which is currently blocking `bytestring-0.11` migration work due to having no available maintainer with the permissions to do a release. This, in turn, is stalling `cabal-install`. Short of taking over the package, we would have to ask for an emergency Hackage release if the neither maintainer shows up to do it in a reasonable time frame.

This is just one step towards helping ease the burden of maintenance of so-called core and boot packages. I hope you agree that this is a good idea, and if we get enough thumbs up, then Chessai and I will draw up the necessary changes to the CLC remit and we'll get started!

Cheers,
Emily


_______________________________________________
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: Proposal: Expanding the CLC

Julian Ospald
Absolutely. I think there could very well be a platform that focuses solely on authorship. This could be made easier by enforcing package names to contain the authors username and then relying on package-qualified imports or something. Just random thoughts.

But yeah, hackage is not that. It already contains various means to deal with maintainership that exceeds authorship.

There's a good counter-argument to my proposal though, namely that it may undermine a users trust in a package, which may be based on the authors quality standards and their attitude. I agree it is an argument, but I also believe a body like the CLC has sufficient competency to make up for this. And it's also a reminder to every maintainer: make sure you have co-maintainers you trust, such that this will never become a problem.

On February 13, 2021 8:03:04 PM UTC, John Ericson <[hidden email]> wrote:

Yeah I strongly agree with the sentiments here, and the concrete measures. Thank you, Emily, for proposing them.

I assume some people will be worried about undermining the prerogative of individual maintainers. My view is this *not* a good reason to "hold the CLC back". A bit off topic, but In the long term, I am optimistic for technical solutions to make dealing with libraries and versions, alternative ecosystems, etc. easier. Basically I want it all---both collaborative ownership and authorship, and healthy decentralized experimentation---and I think that's possible.

John

On 2/12/21 1:46 AM, Julian Ospald wrote:
Hi,

my opinion is that we should develop a zero tolerance towards unresponsive maintainership.

Contributors shouldn't have to escalate on the ML and shouldn't have to request package takeovers. These things are awkward and require more dedication than necessary to be a valuable co-maintainer.

The CLC should proactively scan for popular packages that require new maintainer juice, contact the current maintainers and call for help on the ML (whether core/boot/something-else doesn't really matter to me... redefine the CLC competencies if you must).

I've had many PRs over the years that took 6-12 months for a response. This is not an acceptable response time.

Cheers,
Julian

On February 11, 2021 11:54:19 PM UTC, Emily Pillmore [hidden email] wrote:
Hi All,

Over the past year, two things have become increasingly clear to me as I've carried out my CLC duties:


1. The CLC is under-resourced. This is evidenced by the fact that several maintainers who are not CLC members have been forced to step up to help take on some of the maintenance burden for many of the CLC libraries. Namely, `vector`, `bytestring`, `random`, `unix`, and more. The current CLC head count is not enough to dedicate at least one maintainer per package, which is leading to us all being spread thin, and the less-loved packages are falling into disrepair as a result. Couple this with the fact that roughly half the CLC do not have these packages actively within their maintenance cycles, and we arrive at the current problem.

2. The current set of "core" libraries does not cover what is generally considered "core" in the community. From now on, I'll refer to "core" packages as "boot" packages, and identify core packages to be those that are have proven to be incredibly popular tools for building things in Haskell. For example `zlib`, `parsec`, `regex-base`, `regex-posix`, `network`, etc. In particular, if any of these core packages saw their current authors disappear, or incapacitated in any sense, it would seriously harm the Haskell ecosystem. `cabal-install`, for example, requires several of those packages as upstream dependencies. Currently, we are dealing with this nightmare situation where work is stalled across many packages due to a particular set of maintainers being very difficult to reach, one of whom having disappeared completely for all maintenance intents and purposes.

Ergo, we have a problem. Thankfully, many people have stepped up showing renewed interest in maintaining such packages with the latest crop of CLC folks, and this poses an interesting opportunity.

My proposal is this:

1. We expand the CLC from 9 members to 22 members such that we have at least 1 CLC maintainer per boot package. There are a large number of fantastic candidates already available, who would be perfect for the role. In fact, many of the candidates whom we would ask are already maintaining these packages. In particular, Andrew Lelechenko, Simon Jakobi, Viktor Dukhovni, Dominic Steinitz, Alexey Khuedyakov are already serving within this role (and thank you for it!). Andreas Abel has also offered to help take on one of the core packages.

2. We consider a dedicated "Haskell Action Team" (name and idea courtesy of Carter Schonwald) to oversee packages in the Haskell github repo that can act as supplementary maintainers for many of the core packages contained therein. Currently, there are many in need of help. `zlib` comes to mind, which is currently blocking `bytestring-0.11` migration work due to having no available maintainer with the permissions to do a release. This, in turn, is stalling `cabal-install`. Short of taking over the package, we would have to ask for an emergency Hackage release if the neither maintainer shows up to do it in a reasonable time frame.

This is just one step towards helping ease the burden of maintenance of so-called core and boot packages. I hope you agree that this is a good idea, and if we get enough thumbs up, then Chessai and I will draw up the necessary changes to the CLC remit and we'll get started!

Cheers,
Emily


_______________________________________________
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: Proposal: Expanding the CLC

Carter Schonwald
In reply to this post by John Ericson-2
I agree with your articulated long term goal points, I just worry that we’re not investing in the right structures of organization to support that.  I’m more than happy to be wrong though 

On Sat, Feb 13, 2021 at 3:03 PM John Ericson <[hidden email]> wrote:

Yeah I strongly agree with the sentiments here, and the concrete measures. Thank you, Emily, for proposing them.

I assume some people will be worried about undermining the prerogative of individual maintainers. My view is this *not* a good reason to "hold the CLC back". A bit off topic, but In the long term, I am optimistic for technical solutions to make dealing with libraries and versions, alternative ecosystems, etc. easier. Basically I want it all---both collaborative ownership and authorship, and healthy decentralized experimentation---and I think that's possible.

John

On 2/12/21 1:46 AM, Julian Ospald wrote:
Hi,

my opinion is that we should develop a zero tolerance towards unresponsive maintainership.

Contributors shouldn't have to escalate on the ML and shouldn't have to request package takeovers. These things are awkward and require more dedication than necessary to be a valuable co-maintainer.

The CLC should proactively scan for popular packages that require new maintainer juice, contact the current maintainers and call for help on the ML (whether core/boot/something-else doesn't really matter to me... redefine the CLC competencies if you must).

I've had many PRs over the years that took 6-12 months for a response. This is not an acceptable response time.

Cheers,
Julian

On February 11, 2021 11:54:19 PM UTC, Emily Pillmore [hidden email] wrote:
Hi All,

Over the past year, two things have become increasingly clear to me as I've carried out my CLC duties:


1. The CLC is under-resourced. This is evidenced by the fact that several maintainers who are not CLC members have been forced to step up to help take on some of the maintenance burden for many of the CLC libraries. Namely, `vector`, `bytestring`, `random`, `unix`, and more. The current CLC head count is not enough to dedicate at least one maintainer per package, which is leading to us all being spread thin, and the less-loved packages are falling into disrepair as a result. Couple this with the fact that roughly half the CLC do not have these packages actively within their maintenance cycles, and we arrive at the current problem.

2. The current set of "core" libraries does not cover what is generally considered "core" in the community. From now on, I'll refer to "core" packages as "boot" packages, and identify core packages to be those that are have proven to be incredibly popular tools for building things in Haskell. For example `zlib`, `parsec`, `regex-base`, `regex-posix`, `network`, etc. In particular, if any of these core packages saw their current authors disappear, or incapacitated in any sense, it would seriously harm the Haskell ecosystem. `cabal-install`, for example, requires several of those packages as upstream dependencies. Currently, we are dealing with this nightmare situation where work is stalled across many packages due to a particular set of maintainers being very difficult to reach, one of whom having disappeared completely for all maintenance intents and purposes.

Ergo, we have a problem. Thankfully, many people have stepped up showing renewed interest in maintaining such packages with the latest crop of CLC folks, and this poses an interesting opportunity.

My proposal is this:

1. We expand the CLC from 9 members to 22 members such that we have at least 1 CLC maintainer per boot package. There are a large number of fantastic candidates already available, who would be perfect for the role. In fact, many of the candidates whom we would ask are already maintaining these packages. In particular, Andrew Lelechenko, Simon Jakobi, Viktor Dukhovni, Dominic Steinitz, Alexey Khuedyakov are already serving within this role (and thank you for it!). Andreas Abel has also offered to help take on one of the core packages.

2. We consider a dedicated "Haskell Action Team" (name and idea courtesy of Carter Schonwald) to oversee packages in the Haskell github repo that can act as supplementary maintainers for many of the core packages contained therein. Currently, there are many in need of help. `zlib` comes to mind, which is currently blocking `bytestring-0.11` migration work due to having no available maintainer with the permissions to do a release. This, in turn, is stalling `cabal-install`. Short of taking over the package, we would have to ask for an emergency Hackage release if the neither maintainer shows up to do it in a reasonable time frame.

This is just one step towards helping ease the burden of maintenance of so-called core and boot packages. I hope you agree that this is a good idea, and if we get enough thumbs up, then Chessai and I will draw up the necessary changes to the CLC remit and we'll get started!

Cheers,
Emily


_______________________________________________
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: Proposal: Expanding the CLC

John Ericson-2

Carter,

It's not exactly clear to me where your two proposals differ? It seems like Emily said "bigger CLC" with HAT, while you are saying a separate org, perhaps with the CLC inside the HAT? I'm guessing the idea there is to make the degree of control inversely vary with the number of libraries in the purview?

> I do worry that some Libs that fall under clc atm / as of the spring are likely to never have serious evolution / improvement. But that’s a different issue.

Yes I would like to get into that at some point too. (Pithily put, my view is chop up each library until its contents are uncontroversial.) This is what makes me less concerned about the difference between a bigger CLC and rings of orgs.

John

On 2/13/21 7:01 PM, Carter Schonwald wrote:
I agree with your articulated long term goal points, I just worry that we’re not investing in the right structures of organization to support that.  I’m more than happy to be wrong though 

On Sat, Feb 13, 2021 at 3:03 PM John Ericson [hidden email] wrote:

Yeah I strongly agree with the sentiments here, and the concrete measures. Thank you, Emily, for proposing them.

I assume some people will be worried about undermining the prerogative of individual maintainers. My view is this *not* a good reason to "hold the CLC back". A bit off topic, but In the long term, I am optimistic for technical solutions to make dealing with libraries and versions, alternative ecosystems, etc. easier. Basically I want it all---both collaborative ownership and authorship, and healthy decentralized experimentation---and I think that's possible.

John

On 2/12/21 1:46 AM, Julian Ospald wrote:
Hi,

my opinion is that we should develop a zero tolerance towards unresponsive maintainership.

Contributors shouldn't have to escalate on the ML and shouldn't have to request package takeovers. These things are awkward and require more dedication than necessary to be a valuable co-maintainer.

The CLC should proactively scan for popular packages that require new maintainer juice, contact the current maintainers and call for help on the ML (whether core/boot/something-else doesn't really matter to me... redefine the CLC competencies if you must).

I've had many PRs over the years that took 6-12 months for a response. This is not an acceptable response time.

Cheers,
Julian

On February 11, 2021 11:54:19 PM UTC, Emily Pillmore [hidden email] wrote:
Hi All,

Over the past year, two things have become increasingly clear to me as I've carried out my CLC duties:


1. The CLC is under-resourced. This is evidenced by the fact that several maintainers who are not CLC members have been forced to step up to help take on some of the maintenance burden for many of the CLC libraries. Namely, `vector`, `bytestring`, `random`, `unix`, and more. The current CLC head count is not enough to dedicate at least one maintainer per package, which is leading to us all being spread thin, and the less-loved packages are falling into disrepair as a result. Couple this with the fact that roughly half the CLC do not have these packages actively within their maintenance cycles, and we arrive at the current problem.

2. The current set of "core" libraries does not cover what is generally considered "core" in the community. From now on, I'll refer to "core" packages as "boot" packages, and identify core packages to be those that are have proven to be incredibly popular tools for building things in Haskell. For example `zlib`, `parsec`, `regex-base`, `regex-posix`, `network`, etc. In particular, if any of these core packages saw their current authors disappear, or incapacitated in any sense, it would seriously harm the Haskell ecosystem. `cabal-install`, for example, requires several of those packages as upstream dependencies. Currently, we are dealing with this nightmare situation where work is stalled across many packages due to a particular set of maintainers being very difficult to reach, one of whom having disappeared completely for all maintenance intents and purposes.

Ergo, we have a problem. Thankfully, many people have stepped up showing renewed interest in maintaining such packages with the latest crop of CLC folks, and this poses an interesting opportunity.

My proposal is this:

1. We expand the CLC from 9 members to 22 members such that we have at least 1 CLC maintainer per boot package. There are a large number of fantastic candidates already available, who would be perfect for the role. In fact, many of the candidates whom we would ask are already maintaining these packages. In particular, Andrew Lelechenko, Simon Jakobi, Viktor Dukhovni, Dominic Steinitz, Alexey Khuedyakov are already serving within this role (and thank you for it!). Andreas Abel has also offered to help take on one of the core packages.

2. We consider a dedicated "Haskell Action Team" (name and idea courtesy of Carter Schonwald) to oversee packages in the Haskell github repo that can act as supplementary maintainers for many of the core packages contained therein. Currently, there are many in need of help. `zlib` comes to mind, which is currently blocking `bytestring-0.11` migration work due to having no available maintainer with the permissions to do a release. This, in turn, is stalling `cabal-install`. Short of taking over the package, we would have to ask for an emergency Hackage release if the neither maintainer shows up to do it in a reasonable time frame.

This is just one step towards helping ease the burden of maintenance of so-called core and boot packages. I hope you agree that this is a good idea, and if we get enough thumbs up, then Chessai and I will draw up the necessary changes to the CLC remit and we'll get started!

Cheers,
Emily


_______________________________________________
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: Proposal: Expanding the CLC

George Wilson
I would be happy for the CLC to expand, assuming that qualified candidates step forward.
Twenty-two seems rather optimistic to me, since we typically don't see many applicants. Perhaps it can be an aspirational goal.

Regarding a "Haskell Action Team", I definitely think more maintainers on some core libraries and more active members of the Haskell github organisation would help, but I'm not sure we really need another named volunteer organisation established within Haskell.  Between the CLC, the Hackage trustees, the Haskell.org Committee, the GHC Steering Committee, the Haskell Prime Committee (if it gets going again), and now the Foundation, we really do have a lot of those already. I bet I have even forgotten at least one!
To attempt to form this new group, on top of expanding the CLC to twenty-two, would surely involve a significant overlap between the groups. Otherwise you'd have to conjure a lot more trusted, highly-advanced Haskellers with free time than I think exist.

Cheers,
George

On Tue, 16 Feb 2021 at 04:11, John Ericson <[hidden email]> wrote:

Carter,

It's not exactly clear to me where your two proposals differ? It seems like Emily said "bigger CLC" with HAT, while you are saying a separate org, perhaps with the CLC inside the HAT? I'm guessing the idea there is to make the degree of control inversely vary with the number of libraries in the purview?

> I do worry that some Libs that fall under clc atm / as of the spring are likely to never have serious evolution / improvement. But that’s a different issue.

Yes I would like to get into that at some point too. (Pithily put, my view is chop up each library until its contents are uncontroversial.) This is what makes me less concerned about the difference between a bigger CLC and rings of orgs.

John

On 2/13/21 7:01 PM, Carter Schonwald wrote:
I agree with your articulated long term goal points, I just worry that we’re not investing in the right structures of organization to support that.  I’m more than happy to be wrong though 

On Sat, Feb 13, 2021 at 3:03 PM John Ericson [hidden email] wrote:

Yeah I strongly agree with the sentiments here, and the concrete measures. Thank you, Emily, for proposing them.

I assume some people will be worried about undermining the prerogative of individual maintainers. My view is this *not* a good reason to "hold the CLC back". A bit off topic, but In the long term, I am optimistic for technical solutions to make dealing with libraries and versions, alternative ecosystems, etc. easier. Basically I want it all---both collaborative ownership and authorship, and healthy decentralized experimentation---and I think that's possible.

John

On 2/12/21 1:46 AM, Julian Ospald wrote:
Hi,

my opinion is that we should develop a zero tolerance towards unresponsive maintainership.

Contributors shouldn't have to escalate on the ML and shouldn't have to request package takeovers. These things are awkward and require more dedication than necessary to be a valuable co-maintainer.

The CLC should proactively scan for popular packages that require new maintainer juice, contact the current maintainers and call for help on the ML (whether core/boot/something-else doesn't really matter to me... redefine the CLC competencies if you must).

I've had many PRs over the years that took 6-12 months for a response. This is not an acceptable response time.

Cheers,
Julian

On February 11, 2021 11:54:19 PM UTC, Emily Pillmore [hidden email] wrote:
Hi All,

Over the past year, two things have become increasingly clear to me as I've carried out my CLC duties:


1. The CLC is under-resourced. This is evidenced by the fact that several maintainers who are not CLC members have been forced to step up to help take on some of the maintenance burden for many of the CLC libraries. Namely, `vector`, `bytestring`, `random`, `unix`, and more. The current CLC head count is not enough to dedicate at least one maintainer per package, which is leading to us all being spread thin, and the less-loved packages are falling into disrepair as a result. Couple this with the fact that roughly half the CLC do not have these packages actively within their maintenance cycles, and we arrive at the current problem.

2. The current set of "core" libraries does not cover what is generally considered "core" in the community. From now on, I'll refer to "core" packages as "boot" packages, and identify core packages to be those that are have proven to be incredibly popular tools for building things in Haskell. For example `zlib`, `parsec`, `regex-base`, `regex-posix`, `network`, etc. In particular, if any of these core packages saw their current authors disappear, or incapacitated in any sense, it would seriously harm the Haskell ecosystem. `cabal-install`, for example, requires several of those packages as upstream dependencies. Currently, we are dealing with this nightmare situation where work is stalled across many packages due to a particular set of maintainers being very difficult to reach, one of whom having disappeared completely for all maintenance intents and purposes.

Ergo, we have a problem. Thankfully, many people have stepped up showing renewed interest in maintaining such packages with the latest crop of CLC folks, and this poses an interesting opportunity.

My proposal is this:

1. We expand the CLC from 9 members to 22 members such that we have at least 1 CLC maintainer per boot package. There are a large number of fantastic candidates already available, who would be perfect for the role. In fact, many of the candidates whom we would ask are already maintaining these packages. In particular, Andrew Lelechenko, Simon Jakobi, Viktor Dukhovni, Dominic Steinitz, Alexey Khuedyakov are already serving within this role (and thank you for it!). Andreas Abel has also offered to help take on one of the core packages.

2. We consider a dedicated "Haskell Action Team" (name and idea courtesy of Carter Schonwald) to oversee packages in the Haskell github repo that can act as supplementary maintainers for many of the core packages contained therein. Currently, there are many in need of help. `zlib` comes to mind, which is currently blocking `bytestring-0.11` migration work due to having no available maintainer with the permissions to do a release. This, in turn, is stalling `cabal-install`. Short of taking over the package, we would have to ask for an emergency Hackage release if the neither maintainer shows up to do it in a reasonable time frame.

This is just one step towards helping ease the burden of maintenance of so-called core and boot packages. I hope you agree that this is a good idea, and if we get enough thumbs up, then Chessai and I will draw up the necessary changes to the CLC remit and we'll get started!

Cheers,
Emily


_______________________________________________
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

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

Re: Proposal: Expanding the CLC

Carter Schonwald
There’s a lot more smart quiet folks who just need the right cheerleading and guidance out there than you’d expect.  Or any of us can imagine. 

The way anyone gets great at stuff starts from somewhere, and we need to seriously consider and work at making sure the ramp/funnel of participation and inclusion is as wide as possible. Current Haskell processes are not really setup to handle continuity and growth of participation as well as we should aim for. 

The entire premise/ point of new efforts like the Haskell foundation is that we need to genuinely ask: how do we help more folks get great at their software needs, and facilitate Haskell and or ideas embodied thereof, empowering more folks over time. And this attitude should be reflected in how we evolve and improve and maintain core infra tools and libraries. 

On Tue, Feb 16, 2021 at 4:04 AM George Wilson <[hidden email]> wrote:
I would be happy for the CLC to expand, assuming that qualified candidates step forward.
Twenty-two seems rather optimistic to me, since we typically don't see many applicants. Perhaps it can be an aspirational goal.

Regarding a "Haskell Action Team", I definitely think more maintainers on some core libraries and more active members of the Haskell github organisation would help, but I'm not sure we really need another named volunteer organisation established within Haskell.  Between the CLC, the Hackage trustees, the Haskell.org Committee, the GHC Steering Committee, the Haskell Prime Committee (if it gets going again), and now the Foundation, we really do have a lot of those already. I bet I have even forgotten at least one!
To attempt to form this new group, on top of expanding the CLC to twenty-two, would surely involve a significant overlap between the groups. Otherwise you'd have to conjure a lot more trusted, highly-advanced Haskellers with free time than I think exist.

Cheers,
George

On Tue, 16 Feb 2021 at 04:11, John Ericson <[hidden email]> wrote:

Carter,

It's not exactly clear to me where your two proposals differ? It seems like Emily said "bigger CLC" with HAT, while you are saying a separate org, perhaps with the CLC inside the HAT? I'm guessing the idea there is to make the degree of control inversely vary with the number of libraries in the purview?

> I do worry that some Libs that fall under clc atm / as of the spring are likely to never have serious evolution / improvement. But that’s a different issue.

Yes I would like to get into that at some point too. (Pithily put, my view is chop up each library until its contents are uncontroversial.) This is what makes me less concerned about the difference between a bigger CLC and rings of orgs.

John

On 2/13/21 7:01 PM, Carter Schonwald wrote:
I agree with your articulated long term goal points, I just worry that we’re not investing in the right structures of organization to support that.  I’m more than happy to be wrong though 

On Sat, Feb 13, 2021 at 3:03 PM John Ericson [hidden email] wrote:

Yeah I strongly agree with the sentiments here, and the concrete measures. Thank you, Emily, for proposing them.

I assume some people will be worried about undermining the prerogative of individual maintainers. My view is this *not* a good reason to "hold the CLC back". A bit off topic, but In the long term, I am optimistic for technical solutions to make dealing with libraries and versions, alternative ecosystems, etc. easier. Basically I want it all---both collaborative ownership and authorship, and healthy decentralized experimentation---and I think that's possible.

John

On 2/12/21 1:46 AM, Julian Ospald wrote:
Hi,

my opinion is that we should develop a zero tolerance towards unresponsive maintainership.

Contributors shouldn't have to escalate on the ML and shouldn't have to request package takeovers. These things are awkward and require more dedication than necessary to be a valuable co-maintainer.

The CLC should proactively scan for popular packages that require new maintainer juice, contact the current maintainers and call for help on the ML (whether core/boot/something-else doesn't really matter to me... redefine the CLC competencies if you must).

I've had many PRs over the years that took 6-12 months for a response. This is not an acceptable response time.

Cheers,
Julian

On February 11, 2021 11:54:19 PM UTC, Emily Pillmore [hidden email] wrote:
Hi All,

Over the past year, two things have become increasingly clear to me as I've carried out my CLC duties:


1. The CLC is under-resourced. This is evidenced by the fact that several maintainers who are not CLC members have been forced to step up to help take on some of the maintenance burden for many of the CLC libraries. Namely, `vector`, `bytestring`, `random`, `unix`, and more. The current CLC head count is not enough to dedicate at least one maintainer per package, which is leading to us all being spread thin, and the less-loved packages are falling into disrepair as a result. Couple this with the fact that roughly half the CLC do not have these packages actively within their maintenance cycles, and we arrive at the current problem.

2. The current set of "core" libraries does not cover what is generally considered "core" in the community. From now on, I'll refer to "core" packages as "boot" packages, and identify core packages to be those that are have proven to be incredibly popular tools for building things in Haskell. For example `zlib`, `parsec`, `regex-base`, `regex-posix`, `network`, etc. In particular, if any of these core packages saw their current authors disappear, or incapacitated in any sense, it would seriously harm the Haskell ecosystem. `cabal-install`, for example, requires several of those packages as upstream dependencies. Currently, we are dealing with this nightmare situation where work is stalled across many packages due to a particular set of maintainers being very difficult to reach, one of whom having disappeared completely for all maintenance intents and purposes.

Ergo, we have a problem. Thankfully, many people have stepped up showing renewed interest in maintaining such packages with the latest crop of CLC folks, and this poses an interesting opportunity.

My proposal is this:

1. We expand the CLC from 9 members to 22 members such that we have at least 1 CLC maintainer per boot package. There are a large number of fantastic candidates already available, who would be perfect for the role. In fact, many of the candidates whom we would ask are already maintaining these packages. In particular, Andrew Lelechenko, Simon Jakobi, Viktor Dukhovni, Dominic Steinitz, Alexey Khuedyakov are already serving within this role (and thank you for it!). Andreas Abel has also offered to help take on one of the core packages.

2. We consider a dedicated "Haskell Action Team" (name and idea courtesy of Carter Schonwald) to oversee packages in the Haskell github repo that can act as supplementary maintainers for many of the core packages contained therein. Currently, there are many in need of help. `zlib` comes to mind, which is currently blocking `bytestring-0.11` migration work due to having no available maintainer with the permissions to do a release. This, in turn, is stalling `cabal-install`. Short of taking over the package, we would have to ask for an emergency Hackage release if the neither maintainer shows up to do it in a reasonable time frame.

This is just one step towards helping ease the burden of maintenance of so-called core and boot packages. I hope you agree that this is a good idea, and if we get enough thumbs up, then Chessai and I will draw up the necessary changes to the CLC remit and we'll get started!

Cheers,
Emily


_______________________________________________
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

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

Re: Proposal: Expanding the CLC

Ignat Insarov
Carter's words touched me. Ever neither smart nor silent, I am going to be a
little loud once more.

Being an outside spectator of this venue, a beneficiary _(one of innumerably
many)_ of the work being inconspicuously done by the persons present, and a
skilled developer that potentially may shoulder some of the burden, I would
really like to understand better the structure of power and the philosophy
behind the CLC enterprise — it is not observable, therefore I cannot decide who
to be thankful to and whether my participation is reasonably warranted. I know
there are people that do a huge amount of work continuously fixing a vaguely
defined cloud of _«core»_ packages — but I also know these people have no idea
that I exist, from which it follows that my needs and wishes are respected only
accidentally.

I am voicing this thought for these reasons:

* I am a small scale commercial Haskell user — on its face it classifies me as
  the target audience. I am invested into Haskell but not a luminary like those
  others present here — rather an ordinary person, an average. In some way this
  makes me a representative example.

* I am somewhat altruistic. I contribute open source code, answer questions
  about Haskell and even help people privately without mercantile aims. This
  suggests that I should want to participate in an effort that is beneficial to
  many — being an altruist, I may as well be an effective one.

If there is a person that should be caught in the wave, that is me here. But it
is very evident that I am not. The story is that I asked `\x → (x, x)` to be
given a place in standard libraries — hard to find a more innocent
proposition. As some know, it did not go well. _(This is not an only example but
the most striking.)_ There are several possible explanations.

1. This is meritocracy at work. Haskell collects some of the most gifted
   programmers of the world. A mere mortal cannot possibly suggest any
   beneficial change to `base` or `containers` or `vector` or `cabal-install` —
   in all likelihood it was already considered by the wise council.

2. The philosophy is unclear and undisputed. For example, it was suggested to me
   in private correspondence that the reason the standard libraries are not
   being extended more often is because exporting more names is wrong. This is
   of course as valid a principle as any — but I do not see it being spelled out
   and considered on the basis of evidence. Perhaps the wizards of code are not
   that good at other things, like being clear about their design goals.

3. The power structure is set up in favour of a specific invisible group that
   sets the tune. Recall the story about Stack and Cabal. It had been shown
   clearly that the interests of the community at large are not represented in
   the group of maintainers of Cabal. It is hard to triangulate from the
   distance what exactly went wrong, but on the basis of the meager evidence
   that I can have, the theory is plausible, and evidence keeps adding up.

There is also a question of who selects the libraries to be called _«core»_. For
example, Stack _(and, consequently, half the user base of Haskell)_ depends on
`rio`, and `typed-process` is a superiour replacement for `process`. Should the
_«core»_ include packages vital to half the user base? Should it include a
superiour replacement of a morally obsolete package? Or is it a place where
leviathans of the past come to die? What does it entail for a package to be
considered _«core»_? Does it get included in the standard distribution? What
sort of packages should we like to distribute?

Finally, there is a question of high principles. Haskell can be a pragmatic tool
of the trade or a paragon of elegance, rock-solid or bleeding edge… maybe even
all of it at once, but what does the _management_ want it to be? What do you
folks dream of? What is your ideal? I cannot see any — I only see reactive
efforts to fend off the inevitably approaching future. No one would be inspired
by that. I suspect there are a few people that get paid to contribute to
Haskell. Maybe that should be the main motive instead? Maybe it is time to say
that Haskell is a commercial language maintained by corporate employees? I would
not like to be one but at least expectations would be aligned.

Haskell has not only made me a programmer — it defined me as a person. There is
no other language and no other community like this one. I have reverence. Is it
the same for anyone else here? Or should I, rather, grow up and move on?
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Proposal: Expanding the CLC

Haskell - Libraries mailing list
Ignat

Thanks for writing.  You are just the sort of person that ought to feel welcome, and able to contribute. That you have not felt that way is a failure.

I'd like to suggest another explanation to the three you offer (none of which I subscribe to).

4.  The now-very-large Haskell ecosystem runs on the efforts of busy volunteers, all of whom have day jobs.  However well-meaning or high-minded we are, things will be left undone, or done less well than we aspire to.

I hope and believe that the Haskell Foundation will help with this challenge.  I don’t think it'll be a silver bullet.  But it should help; and making volunteers such as you feel both welcome and able to contribute meaningfully is certainly a major goal.

| Haskell has not only made me a programmer — it defined me as a person. 
| There is no other language and no other community like this one. I have
| reverence. Is it the same for anyone else here? Or should I, rather, grow
| up and move on?

Please don't grow up and move on!  We are working together to build not just a language to be proud of, but a community we can flourish in.  We will stumble for sure, but if we are humble, respectful of each other, and willing to keep trying, I think we can succeed.

Simon

| -----Original Message-----
| From: Libraries <[hidden email]> On Behalf Of Ignat
| Insarov
| Sent: 16 February 2021 21:57
| To: Carter Schonwald <[hidden email]>
| Cc: Haskell Libraries <[hidden email]>
| Subject: Re: Proposal: Expanding the CLC
|
| Carter's words touched me. Ever neither smart nor silent, I am going to
| be a little loud once more.
|
| Being an outside spectator of this venue, a beneficiary _(one of
| innumerably many)_ of the work being inconspicuously done by the persons
| present, and a skilled developer that potentially may shoulder some of
| the burden, I would really like to understand better the structure of
| power and the philosophy behind the CLC enterprise — it is not
| observable, therefore I cannot decide who to be thankful to and whether
| my participation is reasonably warranted. I know there are people that do
| a huge amount of work continuously fixing a vaguely defined cloud of
| _«core»_ packages — but I also know these people have no idea that I
| exist, from which it follows that my needs and wishes are respected only
| accidentally.
|
| I am voicing this thought for these reasons:
|
| * I am a small scale commercial Haskell user — on its face it classifies
| me as
|   the target audience. I am invested into Haskell but not a luminary like
| those
|   others present here — rather an ordinary person, an average. In some
| way this
|   makes me a representative example.
|
| * I am somewhat altruistic. I contribute open source code, answer
| questions
|   about Haskell and even help people privately without mercantile aims. 
| This
|   suggests that I should want to participate in an effort that is
| beneficial to
|   many — being an altruist, I may as well be an effective one.
|
| If there is a person that should be caught in the wave, that is me here. 
| But it is very evident that I am not. The story is that I asked `\x → (x,
| x)` to be given a place in standard libraries — hard to find a more
| innocent proposition. As some know, it did not go well. _(This is not an
| only example but the most striking.)_ There are several possible
| explanations.
|
| 1. This is meritocracy at work. Haskell collects some of the most gifted
|    programmers of the world. A mere mortal cannot possibly suggest any
|    beneficial change to `base` or `containers` or `vector` or `cabal-
| install` —
|    in all likelihood it was already considered by the wise council.
|
| 2. The philosophy is unclear and undisputed. For example, it was
| suggested to me
|    in private correspondence that the reason the standard libraries are
| not
|    being extended more often is because exporting more names is wrong. 
| This is
|    of course as valid a principle as any — but I do not see it being
| spelled out
|    and considered on the basis of evidence. Perhaps the wizards of code
| are not
|    that good at other things, like being clear about their design goals.
|
| 3. The power structure is set up in favour of a specific invisible group
| that
|    sets the tune. Recall the story about Stack and Cabal. It had been
| shown
|    clearly that the interests of the community at large are not
| represented in
|    the group of maintainers of Cabal. It is hard to triangulate from the
|    distance what exactly went wrong, but on the basis of the meager
| evidence
|    that I can have, the theory is plausible, and evidence keeps adding
| up.
|
| There is also a question of who selects the libraries to be called
| _«core»_. For example, Stack _(and, consequently, half the user base of
| Haskell)_ depends on `rio`, and `typed-process` is a superiour
| replacement for `process`. Should the _«core»_ include packages vital to
| half the user base? Should it include a superiour replacement of a
| morally obsolete package? Or is it a place where leviathans of the past
| come to die? What does it entail for a package to be considered _«core»_? 
| Does it get included in the standard distribution? What sort of packages
| should we like to distribute?
|
| Finally, there is a question of high principles. Haskell can be a
| pragmatic tool of the trade or a paragon of elegance, rock-solid or
| bleeding edge… maybe even all of it at once, but what does the
| _management_ want it to be? What do you folks dream of? What is your
| ideal? I cannot see any — I only see reactive efforts to fend off the
| inevitably approaching future. No one would be inspired by that. I
| suspect there are a few people that get paid to contribute to Haskell. 
| Maybe that should be the main motive instead? Maybe it is time to say
| that Haskell is a commercial language maintained by corporate employees? 
| I would not like to be one but at least expectations would be aligned.
|
| Haskell has not only made me a programmer — it defined me as a person. 
| There is no other language and no other community like this one. I have
| reverence. Is it the same for anyone else here? Or should I, rather, grow
| up and move on?
| _______________________________________________
| Libraries mailing list
| [hidden email]
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.has
| kell.org%2Fcgi-
| bin%2Fmailman%2Flistinfo%2Flibraries&amp;data=04%7C01%7Csimonpj%40microso
| ft.com%7C7f7bb62c42ac43639d6a08d8d2c5c706%7C72f988bf86f141af91ab2d7cd011d
| b47%7C1%7C0%7C637491094192227676%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
| MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VxR73
| 6V5TUUf%2B0OfzlBAQK9GG1CpaiBZahvqtiE7obM%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
|

Re: Proposal: Expanding the CLC

Tony Morris-4

I second Simon's words. I didn't read the previous thread, nor will I, so I have no idea what happened with your suggestion.

The Haskell Foundation is primed to work toward solving some of the problems with the standard library.

FWIW, your suggested operation is a primitive operation of the Extend/Comonad type-class called duplicate, though this is not in the standard libraries.

On 2/17/21 8:54 AM, Simon Peyton Jones via Libraries wrote:
Ignat

Thanks for writing.  You are just the sort of person that ought to feel welcome, and able to contribute. That you have not felt that way is a failure.

I'd like to suggest another explanation to the three you offer (none of which I subscribe to).

4.  The now-very-large Haskell ecosystem runs on the efforts of busy volunteers, all of whom have day jobs.  However well-meaning or high-minded we are, things will be left undone, or done less well than we aspire to.

I hope and believe that the Haskell Foundation will help with this challenge.  I don’t think it'll be a silver bullet.  But it should help; and making volunteers such as you feel both welcome and able to contribute meaningfully is certainly a major goal.

| Haskell has not only made me a programmer — it defined me as a person. 
| There is no other language and no other community like this one. I have
| reverence. Is it the same for anyone else here? Or should I, rather, grow
| up and move on?

Please don't grow up and move on!  We are working together to build not just a language to be proud of, but a community we can flourish in.  We will stumble for sure, but if we are humble, respectful of each other, and willing to keep trying, I think we can succeed.

Simon

| -----Original Message-----
| From: Libraries [hidden email] On Behalf Of Ignat
| Insarov
| Sent: 16 February 2021 21:57
| To: Carter Schonwald [hidden email]
| Cc: Haskell Libraries [hidden email]
| Subject: Re: Proposal: Expanding the CLC
| 
| Carter's words touched me. Ever neither smart nor silent, I am going to
| be a little loud once more.
| 
| Being an outside spectator of this venue, a beneficiary _(one of
| innumerably many)_ of the work being inconspicuously done by the persons
| present, and a skilled developer that potentially may shoulder some of
| the burden, I would really like to understand better the structure of
| power and the philosophy behind the CLC enterprise — it is not
| observable, therefore I cannot decide who to be thankful to and whether
| my participation is reasonably warranted. I know there are people that do
| a huge amount of work continuously fixing a vaguely defined cloud of
| _«core»_ packages — but I also know these people have no idea that I
| exist, from which it follows that my needs and wishes are respected only
| accidentally.
| 
| I am voicing this thought for these reasons:
| 
| * I am a small scale commercial Haskell user — on its face it classifies
| me as
|   the target audience. I am invested into Haskell but not a luminary like
| those
|   others present here — rather an ordinary person, an average. In some
| way this
|   makes me a representative example.
| 
| * I am somewhat altruistic. I contribute open source code, answer
| questions
|   about Haskell and even help people privately without mercantile aims. 
| This
|   suggests that I should want to participate in an effort that is
| beneficial to
|   many — being an altruist, I may as well be an effective one.
| 
| If there is a person that should be caught in the wave, that is me here. 
| But it is very evident that I am not. The story is that I asked `\x → (x,
| x)` to be given a place in standard libraries — hard to find a more
| innocent proposition. As some know, it did not go well. _(This is not an
| only example but the most striking.)_ There are several possible
| explanations.
| 
| 1. This is meritocracy at work. Haskell collects some of the most gifted
|    programmers of the world. A mere mortal cannot possibly suggest any
|    beneficial change to `base` or `containers` or `vector` or `cabal-
| install` —
|    in all likelihood it was already considered by the wise council.
| 
| 2. The philosophy is unclear and undisputed. For example, it was
| suggested to me
|    in private correspondence that the reason the standard libraries are
| not
|    being extended more often is because exporting more names is wrong. 
| This is
|    of course as valid a principle as any — but I do not see it being
| spelled out
|    and considered on the basis of evidence. Perhaps the wizards of code
| are not
|    that good at other things, like being clear about their design goals.
| 
| 3. The power structure is set up in favour of a specific invisible group
| that
|    sets the tune. Recall the story about Stack and Cabal. It had been
| shown
|    clearly that the interests of the community at large are not
| represented in
|    the group of maintainers of Cabal. It is hard to triangulate from the
|    distance what exactly went wrong, but on the basis of the meager
| evidence
|    that I can have, the theory is plausible, and evidence keeps adding
| up.
| 
| There is also a question of who selects the libraries to be called
| _«core»_. For example, Stack _(and, consequently, half the user base of
| Haskell)_ depends on `rio`, and `typed-process` is a superiour
| replacement for `process`. Should the _«core»_ include packages vital to
| half the user base? Should it include a superiour replacement of a
| morally obsolete package? Or is it a place where leviathans of the past
| come to die? What does it entail for a package to be considered _«core»_? 
| Does it get included in the standard distribution? What sort of packages
| should we like to distribute?
| 
| Finally, there is a question of high principles. Haskell can be a
| pragmatic tool of the trade or a paragon of elegance, rock-solid or
| bleeding edge… maybe even all of it at once, but what does the
| _management_ want it to be? What do you folks dream of? What is your
| ideal? I cannot see any — I only see reactive efforts to fend off the
| inevitably approaching future. No one would be inspired by that. I
| suspect there are a few people that get paid to contribute to Haskell. 
| Maybe that should be the main motive instead? Maybe it is time to say
| that Haskell is a commercial language maintained by corporate employees? 
| I would not like to be one but at least expectations would be aligned.
| 
| Haskell has not only made me a programmer — it defined me as a person. 
| There is no other language and no other community like this one. I have
| reverence. Is it the same for anyone else here? Or should I, rather, grow
| up and move on?
| _______________________________________________
| Libraries mailing list
| [hidden email]
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.has
| kell.org%2Fcgi-
| bin%2Fmailman%2Flistinfo%2Flibraries&amp;data=04%7C01%7Csimonpj%40microso
| ft.com%7C7f7bb62c42ac43639d6a08d8d2c5c706%7C72f988bf86f141af91ab2d7cd011d
| b47%7C1%7C0%7C637491094192227676%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
| MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VxR73
| 6V5TUUf%2B0OfzlBAQK9GG1CpaiBZahvqtiE7obM%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

OpenPGP_0xFC47318DEB073D0F.asc (1K) Download Attachment
OpenPGP_signature (505 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Expanding the CLC

Alexey Khudaykov
In reply to this post by Emily Pillmore

I think that we should understand what exactly does CLC do? What should it do?

What is the problem at hand? Important packages in haskell ecosystem are not
properly maintained. Solution? They need maintainers. Should they be members of
CLC? I'm not sure. CLC membership is 3 years, maintainers usually maintain
package until they stop. Should someone stop maintaining package if he's no
longer member of CLC?

Furthermore I would argue that:

> several maintainers who are not CLC members have been forced to step up to
> help take on some of the maintenance burden for many of the CLC
> libraries. Namely, `vector`, `bytestring`, `random`, `unix`, and more.

is step in the right direction. Committee in charge of maintaining package is
basically designed to just keep packages on life support without any significant
development. And it's exactly what happened. Package will be improved only when
maintainer cares about it. And it's not possible to care about all core libraries.

Should CLC maintain packages or find maintainers, resolve disputes etc? Does it
do software development or does it organize software development?

On 12.02.2021 02:54, Emily Pillmore wrote:
Hi All,

Over the past year, two things have become increasingly clear to me as I've carried out my CLC duties:


1. The CLC is under-resourced. This is evidenced by the fact that several maintainers who are not CLC members have been forced to step up to help take on some of the maintenance burden for many of the CLC libraries. Namely, `vector`, `bytestring`, `random`, `unix`, and more. The current CLC head count is not enough to dedicate at least one maintainer per package, which is leading to us all being spread thin, and the less-loved packages are falling into disrepair as a result. Couple this with the fact that roughly half the CLC do not have these packages actively within their maintenance cycles, and we arrive at the current problem.

2. The current set of "core" libraries does not cover what is generally considered "core" in the community. From now on, I'll refer to "core" packages as "boot" packages, and identify core packages to be those that are have proven to be incredibly popular tools for building things in Haskell. For example `zlib`, `parsec`, `regex-base`, `regex-posix`, `network`, etc. In particular, if any of these core packages saw their current authors disappear, or incapacitated in any sense, it would seriously harm the Haskell ecosystem. `cabal-install`, for example, requires several of those packages as upstream dependencies. Currently, we are dealing with this nightmare situation where work is stalled across many packages due to a particular set of maintainers being very difficult to reach, one of whom having disappeared completely for all maintenance intents and purposes.

Ergo, we have a problem. Thankfully, many people have stepped up showing renewed interest in maintaining such packages with the latest crop of CLC folks, and this poses an interesting opportunity.

My proposal is this:

1. We expand the CLC from 9 members to 22 members such that we have at least 1 CLC maintainer per boot package. There are a large number of fantastic candidates already available, who would be perfect for the role. In fact, many of the candidates whom we would ask are already maintaining these packages. In particular, Andrew Lelechenko, Simon Jakobi, Viktor Dukhovni, Dominic Steinitz, Alexey Khuedyakov are already serving within this role (and thank you for it!). Andreas Abel has also offered to help take on one of the core packages.

2. We consider a dedicated "Haskell Action Team" (name and idea courtesy of Carter Schonwald) to oversee packages in the Haskell github repo that can act as supplementary maintainers for many of the core packages contained therein. Currently, there are many in need of help. `zlib` comes to mind, which is currently blocking `bytestring-0.11` migration work due to having no available maintainer with the permissions to do a release. This, in turn, is stalling `cabal-install`. Short of taking over the package, we would have to ask for an emergency Hackage release if the neither maintainer shows up to do it in a reasonable time frame.

This is just one step towards helping ease the burden of maintenance of so-called core and boot packages. I hope you agree that this is a good idea, and if we get enough thumbs up, then Chessai and I will draw up the necessary changes to the CLC remit and we'll get started!

Cheers,
Emily


_______________________________________________
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: Proposal: Expanding the CLC

Gershom Bazerman

I tend to agree. The CLC is a deliberative body with some action components. (The name “committee” is a tell). One wants those smaller to reach consensus sooner. Having more maintainers for “core” and “near-core” packages (and perhaps formalizing more the latter) is very good. Asking these maintainers be on the CLC doesn’t seem to be necessary to solve any proximate problem?

-g

On Feb 17, 2021, 5:47 AM -0500, Alexey Khudaykov <[hidden email]>, wrote:

I think that we should understand what exactly does CLC do? What should it do?

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