Hi, I have no idea why I got invited...

[liamzee]

Why I got invited here, but I want to point out that I'm a relative noob (not just to Haskell, but to programming, as in, I just discovered how to use malloc / calloc with peek today), but am willing to contribute hours, provided someone is willing to provide some level of mentorship.

I am currently working on trying to build a prototype (i.e, probably will have to be discarded) exact parser for .cabal files, and my immediate project is aiming to build a GUI caller around the cabal build tools, but am a bit stalled with reading the cabal codebase.

Well, in either case, thanks for the invitation.

[jamesdbrock]

Hi @liamzee ! I read your comment haskellfoundation/stability#12 (comment) and I thought you seem like a sensible and trustworthy person who is concerned with the problem of how to best maintain Haskell packages.

[liamzee]

The only way I might be able to contribute in the short-term might be to make tho following suggestions:

-1, get a census of current members and figure out how much time they might have available for projects per month and perhaps per year. It makes things way smoother if we have an idea of how much labor availability HGT has.

-2, put out a quarterly report of the projects HGT has supported, improvements made by HGT, etc. It helps with improving HGT's visibility and encouraging participation by community members without requiring invites.

[liamzee]

As a side effect of one, making it clear how much labor availability HGT has in theory actually makes HGT much more useful, because there's a number of floundering projects in the Haskell ecosystem that require significantly more labor. If HGT is, contrasting to existing projects, not overworked, it can provide a useful nexus for "hey, we're sort of overworked, we don't want to surrender our project to HGT, but we can go talk with the HGT team and see if we can borrow labor from them".

That helps with the Haskell ecosystem overall; i.e, not only do we have mechanisms to support abandoned projects, but we also have mechanisms to redistribute excess labor to projects that need it.

[jamesdbrock]

I like your ideas @liamzee but I think you're getting a bit too far ahead. I'm hoping that the HGT model will allow people to labor on undermaintained projects in an disorganized way, with the certainty that their work will not be blocked because they can merge PRs and publish packages from HGT unassisted. The disorganization is deliberate. Let's wait until we have some excess labor before we try to organize.

Community members who have not been invited to HGT can still submit PRs as usual. But if they are truly “community members” who know other people in the Haskell community then they should ask for an invite to HGT.