Clarifying the situation of the packages under the github.com/haskell organisation

[Kleidukos]

I know the subject has been raised a couple of times in private discussions, but I'd like to know the official position of the CLC regarding the repositories in the Haskell organisation.

Most of them do belong to the following groups:

1. "core" and "boot" packages;
2. IDE packages (HLS, hie-bios, VScode extension, haskell-mode for emacs);
3. Infrastructure like Hackage, docker image, etc

And then we have some outliers like HTTP, statistics, critbit, hoopl, text-format, and a fork of test-framework.

I know it's not a pleasant thing to do, but I'd like to ask the hard questions:

1. Have those projects adopted the Guidelines for Respectful Communication (GRC);
2. Do admins of the organisation have upload rights for those packages so that the absence of their original maintainer does not impact downstream users.
3. Since those packages are under the Haskell organisation, should they be held to high standards of compatibility with recent GHC versions, and more generally high code quality?

[treeowl]

1. I don't think there's been any formal process to that effect.
2. Effectively automatic. They can take whatever privileges they need when they need them.
3. Compatibility with recent (not latest) GHC versions is not required, to the best of my knowledge.

[Kleidukos]

@treeowl Thank you for the insights. I wonder if some of those packages would best live elsewhere if they do not have an official relationship with the Core or Boot libraries, or even be compatible with a recent (let's stay 8.10.7 as it's considered an LTS) compiler.

[treeowl]

Do you know of any packages in the haskell organization that are not core/boot packages and are not compatible with the last few GHC versions?

[Kleidukos]

Yes:

• critbit is not compatible with 9.2, 9.0 or 8.10
• hoopl is not compatible with 9.2, 9.0 or 8.10
• text-format is not compatible with 9.2, 9.0 or 8.10
• bzlib is not compatible with 9.2, 9.0 or 8.10
• network-bsd is not compatible with 9.2
• wreq is not compatible with 9.2
• ThreadScope needs stack, cannot build with cabal on the last 3 compilers

[Kleidukos]

Effectively automatic. They can take whatever privileges they need when they need them.

@treeowl Is this something that's been mutually agreed upon when the original maintainers have transferred their packages to the Haskell organisation? Do we risk any conflict if the Haskell admins rightfully use their prerogative?

[gbaz]

There is no risk of conflict. The purpose and nature of github orgs is that admins can add more people to the projects within them. (and note that with hackage upload permissions, the usual procedures for takeover and NMU continue to apply as far as I know).

I do not believe there is any sense in asking these projects adopt GRC, which is only for HF affiliation. And I do not believe there is any purpose in asking that there be any continued standards of code quality and maintainership.

The haskell github organization was never intended to only be for core or boot libraries, and attempting to change it to be so many years after the fact seems like it would create needless churn to no good purpose.

[goldfirere]

I respectfully disagree with @gbaz, above, about the role of github.com/haskell in our ecosystem -- specifically, around the GRC and code quality / maintainership.

github.com/haskell is part of our front lobby for the Haskell programming language, along with haskell.org and perhaps a few other places. Accordingly, github.com/haskell should present our best face forward. The projects here should have high standards of maintainership and should, in my opinion, subscribe to some agreement that we treat people with respect. (The GRC, as written, has some good aspects and some not as good aspects. I am not advocating for that text specifically at this point -- just the idea that writing down standards of communication, and ways to address problems that may arise, is cited as an attribute of an inclusive community.) Whether or not a library in github.com/haskell is labeled as a "core" or "boot" library, a passerby would reasonably think that a repo in this org is somehow important enough to the Haskell ecosystem to be part of its Official GitHub Organization.

On the subject of churn: one way to perhaps avoid churn is not to necessarily move less maintained projects out, but instead label them clearly. That might be sufficient.

To be clear: I am agnostic on whether the org should be about core/boot libraries or not -- just that what is stored here is worthy of a pride of place.

And, I support, as ever, a clear posting of who is in charge where, along the lines of the discussion in haskell-org/committee#10.

[gbaz]

In my experience, I have never seen anyone consider a github organization as a "front lobby". They see it as a grab-bag of repos, some of which are active, some of which are legacy. The individual project repos are what they focus their attention on. This is in part because organizations don't have any standard place to present a "public face" in terms of a single place for a README, etc. Nearly every large github organization I have encountered has had some very active and well-maintained projects, as well as a bunch of less active and legacy stuff. I have never seen anybody in good faith say "if some organization has some less-maintained repos, then this makes this organization look suspect." Note that these less maintained repos are not immediately obvious in the organization page either, as it is sorted by recent activity.

I am opposed to any disruptive change to things that are working just fine. It would be good to have individual libraries self-labeling in their README.md to make clear that the are boot or core libraries, etc.

I would also be fine with a policy statement that organization admins of the organization as a will intervene in the case of any disruptive violations of the GRC in any of the subrepos. I imagine this has been implicit anyway -- if a rude flamewar broke out in some more obscure repo in the org, I would probably just intervene anyway. This does not require hunting down and getting signoff from every hosted project. It is just a new org policy, and in the unlikely event that a maintainer finds this exorbitantly onerous, they can leave.

The one thing I want to underline is that removing a project from an organization is highly disruptive -- it needs to find a new home, links are broken, any existing workflows referencing a repo break, and typically some of that is never properly cleaned up. Github also does not provide a good way to mitigate any of this with redirects. Preservation of historic code (even if not actively maintained) for reference and stability is very important, and often undervalued until somebody actually needs it, at which point it is a frustrating mess.

[goldfirere]

In my experience, I have never seen anyone consider a github organization as a "front lobby".

I do. That is, when I'm looking at a repo, I will look to see who owns it. Depending on what I find, I will adjust my expectations of that repo. If it's a person I've never heard of before, I react accordingly -- not knowing what, exactly, to expect. On the other hand, if I see that a repo is in the main org of a large project, I will expect a certain quality level. Maybe this isn't a "front lobby" exactly, but when I look at a repo, the quality of what I find there reflects on the place where the repo is hosted.

I am opposed to any disruptive change to things that are working just fine.

So am I. That's why I suggested that perhaps it's best just to be clear, in the repo READMEs, for example, what the status of each project is. We seem to be in agreement here.

I would also be fine with a policy statement that organization admins of the organization as a will intervene in the case of any disruptive violations of the GRC in any of the subrepos.

Great. I'm fine with this -- in fact, it's more or less exactly what I was hoping for.

The one thing I want to underline is that removing a project from an organization is highly disruptive

Yes, I see this and do not want this, either.

To reiterate, I think we're on the same page here: add some documentation (incrementally) to the repos here describing whether each one is core / boot / neither / maintained actively / retained for archival reasons / whatever, and articulate a (discoverable) policy of what contributors can do if they feel mistreated (bonus points if the policy attempts to describe what "mistreated" means).

[tomjaguarpaw]

On visiting https://github.com/python I expect it to be an official repo, and I expect that what goes on there reflects the Python community broadly. Part of my rationale for that is that the header of the organisation page displays the official Python logo, and it links to https://www.python.org/. Those are strongly suggestive of officialness, to me.

Now, the header of https://github.com/haskell has the Haskell logo and it links to http://haskell.org, so I suspect the newcomers to the Haskell community see https://github.com/haskell as official.

Now, what does that imply? I think at the very least it implies that there should a clear governance model for it, that is, a group of people with authority over the organisation and clear principles on how it should be run and to what end. "The current maintainers" and "the current set of packages" serve fine as the components of a governance model as long as that is broadly accepted by the community and serves its purpose. I don't think it's acceptable to leave this governance model implicit, however.

I agree with @gbaz about avoiding needless disruption and churn. On the specific point:

Preservation of historic code (even if not actively maintained) for reference and stability is very important

the feature of repo archival (i.e. closing the repo to new contributions but keeping all existing code, issues, etc. in place) can be a useful middle ground in some circumstances.

organizations don't have any standard place to present a "public face" in terms of a single place for a README

To me this is a weakness of GitHub organisations. Perhaps all of our GitHub organisations could contain a meta repo for exactly this sort of thing.

[Kleidukos]

@tomjaguarpaw I have a governance repository for the Haskell Cryptography Group that clarifies a bunch of things: https://github.com/haskell-cryptography/governance.
Maybe this can give you some ideas. :)

[tomjaguarpaw]

@Kleidukos Nice detailed documents, thanks for the pointer. It would be great if eventually https://github.com/haskell could have something similarly detailed, but for now even the basic step of having a named group of responsible people and an explanation of what exactly are their responsibilities would be a great improvement.

[andreasabel]

My 2 cents:
I do agree that https://github.com/haskell has the air of office and power.
I'd think that this org is a great place for libraries and tools vital for the Haskell ecosystem (recently alex and happy moved to this home).
Also, I expect a high standard of maintenance of packages admitted here. (Legacy packages can remain here but should be explained as such.)

Since this repo has the flair of representation, I think these rules make sense:

• membership should be public
• ownership should be carefully maintained:
  • long inactive owners should be pruned
  • new owners should be admitted from time to time, e.g. based on merits
• information how to join should be public (see the suggested meta repo), e.g. whom to apply to for membership

[Bodigrim]

Historically github.com/haskell organisation did not imply any additional requirements on members. Strictly speaking, the answer to all three questions is "no". My opinion is that any proposed new rules require a clear buy-in from (the majority of) current participants and should not be imposed top down or come without a transition plan.

[jaspervdj]

My personal opinion is that the answer to hard questions (1) and (2) should be yes.

The answer to (3) is more complex -- clearly it should also be yes -- but it's not clear how this can be achieved, where do we find maintainers for unmaintained packages? Where do packages move if they don't work with the latest compiler version? Who decides what "high code quality" is? So I'd argue for taking less of a hard stance there, and @goldfirere's idea of incrementally documenting this seems like a good approach.

[treeowl]

My personal opinion is that the answer to hard questions (1) and (2) should be yes.

As I pointed out earlier, (2) is not really a valid question in the context of GitHub organizations. There's no use discussing it further.

[Kleidukos]

Regarding the orphaned packages, I'd like to point that other communities like Rust have an -unofficial org, like https://github.com/rust-unofficial.

[hasufell]

I don't think github.com/haskell can or should be considered any sort of front lobby. Yes, it's true some boot packages are maintained here, some are not.

The most important project doesn't even live here, but at gitlab.haskell.org, which also is a much more appropriate place to be a front lobby: because it's entirely controlled by the community.

The github organization is nice for visibility and mirroring (that can be automated), but I urge most of the core projects hosted here to move over to gitlab: cabal and HLS releases are already cut there, because the CI is better. It's getting a devops now thanks to HF, so things should be even smoother soon.

Apart from that, I agree that governance should be clarified, but I also don't see a particularly strong case to change scope. It might make more sense for the CLC to prepare a nice landing page about core libraries, boot packages, base etc.

[goldfirere]

I don't have an informed opinion on the benefits / drawbacks of migrating projects to GitLab. But I do want to respond to

I don't think github.com/haskell can or should be considered any sort of front lobby.

Whether we think it can or should be considered a front lobby isn't quite the question, because it's other people's impressions that matter here. And, some people (for example, me; others have agreed, too), would consider an organization hosted at github.com/haskell to be an official face of the Haskell language. If we don't want to design / enforce higher standards here, that may be OK -- but then we should say somewhere that the organization is unofficial (with a link to more official places).

If I were assessing the strength / stability / enterprise-readiness of a language ecosystem, the main org at GitHub is likely one place I would look. We should make sure that this page is communicating the message we want to communicate. My ideal would be a set of up-to-date, important repos that support the core capabilities of Haskell. (Unless e.g. moving to GitLab would be more productive.) But I'm also quite happy with other designs, such as a mix of up-to-date and less up-to-date repos (with clear labels on the out-of-date projects that they are no longer core parts of Haskell), or a link for visitors to look elsewhere.

[hasufell]

Whether we think it can or should be considered a front lobby isn't quite the question, because it's other people's impressions that matter here.

Maybe, but I don't think we should let network effects impose decisions on us.

Github namespaces are not necessarily signals of officialness. Anyone can reserve a namespace, e.g. https://github.com/haskell-foundation

To me the question that needs solving is: what is official?

Is haskell.org "official"? This was challenged in the past, e.g.: https://web.archive.org/web/20170120104254/https://haskell-lang.org/ (note that some of the current/past HF board members were involved in that).

Until we can solve this question, I believe any decision is really up to the current maintainers of the organization.

[Bodigrim]

I cannot find a rationale to support the view that Haskell GitHub organisation is a lobby; it's a garage or a bike shed. And while we are free to discuss its repainting, it functions pretty well. Please do not disturb people at work. If I had time, I'd be more concerned about our front door or reception room.

[Bodigrim]

Closing, since the discussion has fizzled out and is more suitable for https://github.com/haskell/meta/
Feel free to reopen if there is a specific request for CLC.