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