-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Who owns github.com/haskell? #1
Comments
https://github.com/orgs/haskell/repositories
|
Has this conversation progressed in another forum? I was linked here from discourse when hoping to better understand the github.com/haskell organization. Surely the owners of the group could declare by fiat what the ownership structure is, or work with HF and other groups if there's a desire to be part of something larger. |
I'd also be interested in moving this discussion forward. E.g. I've recently been doing a bit of code renovation on Typing Haskell in Haskell (https://discourse.haskell.org/t/reviving-typing-haskell-in-haskell/5072, https://github.com/ocramz/thih ), which IMO is a landmark resource for understanding GHC type inference up to ~2000. I'm mentioning this here because I'd find it fitting for that code to exist as a public Haskell resource (e.g. here) rather than tied to any private account. I'm currently discussing the idea in an email thread with the original author, Prof Mark P Jones. If he and everyone else is ok with this, I'd be happy to transfer the up-to date repo here. |
(Rephrasing my old comments left elsewhere back in February) I suggest github.org/haskell to be owned by CLC, as a body which was historically most involved with it and has a clear interest in upkeeping it. Governance changes will require buy in from Hackage admins, embodied in @gbaz, who retain ownership for technical purposes and moderation. This is similar to the management of PVP, for example. To be very clear: this is not because I want more power for CLC (we have plenty on our plate, to be honest), but because I don’t want to see a new dysfunctional group or committee (because we have more than plenty of them). Even the current situation, when at least some, very conservative decisions can be made, is better than a situation, where nothing can be decided at all. Let me ask it straight: if you are opposed to the suggestion above, what is your specific vision and what kind of effort you are willing to put into its implementation? |
I like how the haskell.org committee has been operating lately, and I’d welcome them taking over the GitHub organization. CLC is an option too. |
Could the current admins vote on a way forward? There were not many proposed. Afais:
|
I vote for 3 (first preference) and 2 (second preference). I don't see Haskell.org committee to have much stake in github.com/haskell (after all their remit is unsurprisingly limited to haskell.org), but if they are willing to take this burden, I have no objections at all. |
Any movements? |
Alternative option: the HF owns it (unclear if they have bandwidth either). I had mistakenly assumed they did own it in the past! EDIT: I now disagree with this, see below |
This question has arisen on Discourse: https://discourse.haskell.org/t/how-is-github-com-haskell-affiliated/9367/2 |
When one creates an "Organization" on GitHub one has to specify a "business or institution" that it belongs do. Do we know what business or institution was chosen for this organization? Was it perhaps "Haskell.org" or "the Haskell community"? Is there some way we can discover this information in the settings? (I'm not an "Owner" so I don't have access to the settings.) cc @mpilgrem |
@tomjaguarpaw it says just "Haskell". If your question is whether the organization ever belonged to Haskell.Org committee or was meant to belong to it, the answer is - up to my best knowledge - no. The organisation was originally created by @hvr, who later passed superadmin rights to @chessai, who was a CLC chair at that time. That's why my suggestions above. |
@Bodigrim, if it is not private information, may I ask who currently is assigned |
Current users marked "owner" for the Haskell GitHub organisation are: @andreasabel This is significantly cut down from a few years ago, because there were a lot of people who were very inactive who had been added for no reason. Most of the people on this list are involved in coordination of multiple significant Haskell projects. I am no longer a part of the CLC, nor any committee, so I will remove my own admin privileges, as I don't need them/shouldn't have them. I'll do that right after hitting "Comment" on this message. Maybe there are some people in the owners list who aren't active enough in any project to need the permissions as well. I do think it makes sense from a security perspective to evaluate why every person on this last has that role. From my own eyeballing, I can come up with reasons for everyone on the list but me, but I'm not sure if I'm entirely accurate for my evaluation of others. I think CLC/GHC steering/Haskell.org or some subset thereof makes sense, plus people who manage multiple big projects, plus people who manage critical infrastructure. |
The Core Libraries Committee team is outdated: https://github.com/orgs/haskell/teams/core-libraries-committee |
Okay, I just learned that you cannot change your own role. @Bodigrim or someone else I mentioned, can you please change my role away from "owner"? |
Thanks, updated.
Done, thanks for upkeeping our control environment. |
@Bodigrim billing, gravatar and sponsors update email are still pointing to chessai |
ngl i have no clue why i'm still on there. Seems stale. |
If my assistance is needed for the transition, please email me. I don't think it is, though. |
Thanks, updated.
Changed your role to a member, thanks. I also downgraded @david-christiansen: he has not been active here for quite some time and no longer requires this kind of access ex officio. I hope it's alright. |
Yes, that's absolutely the right thing to do - thanks! |
I'd like to have another go at making the case that the Haskell.org committee should own the What makes the The "Haskell" name is an intangible piece of "community property". Putting the "Haskell" name on something makes it look official, and as such I think it's good that many things which have the "Haskell" branding are owned by the Haskell.org committee. I think they've done a pretty good job of managing those about as neutrally as we can hope for, and that shows that they can be trusted to manage more such things. So the github organization falls close to the Haskell.org committee's remit in that way. We can also see the closeness if we think about the big decisions that need to be made about the github organzation: what projects are in it or out of it.The big effect of adding something to the github organization is that now it has that "Haskell" branding, it looks official, it's more of a "brand representative" for us as a community. In that respect it's quite a similar decision to deciding what content should go on the haskell.org website! There are also going to be technical components to such decisions. That brings it closer to the CLC's remit. But the CLC's remit is about stability of the core Haskell libraries. Does that naturally extend to, say, deciding whether some hot new code formatter is "good enough" to get the official Haskell branding? I'm not sure! So overall I think at the moment the Haskell.org committee is the best fit. I would also love us to have some kind of policy for organization membership, and probably that should have some technical component, but I don't think that would be too difficult for the Haskell.org committee. |
I'm sympathetic to this (as I said ages ago on a linked discussion I had always thought the committee ultimately did "own" it in some sense), but I think there's no forcing function on ownership unless we actually have some serious discussions that need resolution, and where a clear "owner" will help with this. In the other linked discussion we talked about rationale for how to think of the organization, and that's where I tend to disagree -- there's no "front lobby" aspect or whatever, its a grabbag of stuff, intended to serve working purposes, not "showcase" or "brand". Packages existing in this organization should not be seen as a measure of their quality, endorsement, or support, for the most part. Are there any particular proposals for adding packages that are in the pipes and you think need more formal discussion? |
+1. |
Actually, I take all that back! We do have a forcing function, and we should proceed rapidly. Github will be reorganizing their plans, and if we wish to continue to use the provisioned "enterprise" features we need to sign their new terms of service as an institution -- and that's precisely what haskell.org exists for -- see attached screenshot. As such, we should probably at least for the purposes of signing the corporate TOS and getting as many features out of github as possible make haskell.org ownership "official". In terms of how that affects any decision making, if at all, we can work that out going forward. |
I suggest:
Keep in mind that haskell.org already allows rather loose arrangements on their homepage (e.g. the ghcup subpage is controlled/maintained by the ghcup project). The github org has private runners attached to it from various people. Those are sensitive resources. The repos are sensitive resources. We must be mindful about this, otherwise projects may drop out. |
I agree with @hasufell :
I think we need to be careful not to disrupt arrangements that are in good function today.
I am a bit skeptical concerning the last point. Folks will intuitively ascribe some air of authority to an organization with the name |
We can say this... but I'm not sure it's wise. We get much less choice about how we're perceived. I think that people will continue to think that
I agree with this stuff. I am not suggesting we have some tight control over I do think it would be helpful to have some kind of policy that the haskell.org committee could implement. From the discussion threads it's not clear to me that the current set of loose owners particularly want to be in the position of deciding the membership of Having some clear rubric would also help with the general confusion about what is and is not in |
This is just not how opensource works. I'm sorry, but if people lack this basic understanding, then we need to point to disclaimers and documentation that make it clear. It's very well possible that in 5 years time, someone rewrites GHC, integrates it well with stack and the old Haskell tooling just dies out, including GHCup and hackage. What is "official" or not is in the end just ecosystem effects. There have been times where distros switched packages to forks without renaming them. |
(And to be clear, I'm not suggesting we do anything as heavyweight as most of these!) I'll stop there for now. My point is just: I don't think it's fair to say that this is "not how open source works". Plenty of open-source projects work this way. While in principle there is no truth about what is "official", in practice there are often structures that provide a good enough guide. We could say the same about |
Yes and what is official now happened through network effects and not authority. GHCup is "official", because people use it, not because haskell.org endorses it. My point is not that managing projects or organizations doesn't make sense. My point is that it's a non-argument to say "we need strict organization management, otherwise people get confused about what is official". There's likely some other motivation behind this, like a quality or support stamp (like @andreasabel mentioned). So you'd have to be more precise about the actual criteria you are thinking of. And once you have criteria, you need to start enforcing them or get the maintainers to buy into them. This is hard to do proper retroactively. And I personally don't want that. I make promises to my users, not to haskell.org or a github org. |
And stuff should go in
Sure. The criteria I would think of would probably be:
i.e I'm very much not proposing "strict", I'm proposing "minimal but written down"! We very much need any such criteria to be acceptable to the people already in the org, which is why I think they should be minimal. It's pretty plausible to me that the criteria I suggested above would be acceptable to everyone. I am proposing something that suggests some actions: e.g. we might want to gradually put some stricter limits on "actively maintained" such that we shuffle out dead projects. |
What do you do with projects that become unmaintained suddenly or slowly over time? This is exactly what the CLC deals with and it effectively means taking ownership over a project, because otherwise you can't appoint new maintainers. Dropping the project from the namespace is even worse. It sounds minimal, but it's really not. And if that was the policy, I'd not want ghcup to stay there (because I have my own policy on what happens when I become absent: https://www.haskell.org/ghcup/about/#transition-plan-in-case-of-maintainer-absence) |
I'd be extremely cautious with introducing any new policies. It's not uncommon even for key projects not to receive updates for a year, shall we push them out and then invite in every time it happens? While I understand good intentions behing "bringing order to chaos", please let's not break what works already. As for the legal side of things, there is very little difference between HF and haskell.org in terms of incorporation. They share the same board of directors, so in terms of governance / billing it would be simpler to ask HF to take over. (HO committee is different from HO board, but this is irrelevant unless we want them to moderate the space instead of the current admin team). |
@Bodigrim In the meantime, can you push for a decision sufficient for you to fill out the terms of service form and ensure we can be an enterprise organization? Then we can continue to have a more specific discussion over what policies if any we need following (which I think is the real issue, not whose purview it is, which as I have argued will be more obvious as the scope of work needed [or not needed] becomes evident). |
We should
(I'm the only person who is both HF board member and admin of https://github.com/orgs/haskell, but alternatively we can promote @jmct to an admin ex-officio and let him sign) I'm exceedingly busy at the moment, so would appreciate if someone else takes a lead on this. |
Currently, there are two charitable Not-for-Profit Corporations without members incorporated under the Not-for-Profit Corporaton Law of the State of New York: (1) Haskell Foundation, Inc. and (2) Haskell.org, Inc. These corporations have identical bylaws (save for their names) - see https://gitlab.haskell.org/hf/meta/-/tree/main/bylaws?ref_type=heads - and the composition of their boards of directors is identical. I have not discussed this with my fellow directors or @jmct, but given the plans of both corporations, I think if one of these corporations is to be the counterparty of GitHub, Inc. it should be Haskell.org, Inc. |
I agree it should be haskell.org. Its always been the holder of community assets for the community to me. Haskell Foundation came into existence to be more active. Having them being separate, even in name only, allows HF to take more risk. But yes, we should make h.o official and keep ad hoc administration as we have. (+1) I do think we should be clear that it is not an endorsement though. We want to be able to be aggressively inclusive. Some of what the org does is act as an archive. |
I don't have a strong opinion, but I'm also leaning towards haskell.org. |
I'm happy to drive this from the HF side since @Bodigrim is busy. I do have a few questions for the group, though:
Notice this second question is slightly different than me becoming an owner just to sign (which I'm happy to do and then go away if that's what folks want). What I'm suggesting is "if we're asking an entity to take some form of liability, they should probably have representation?" But this does not have to be me. In fact, I'd rather it be someone from the haskell.org committee! There's also an HF board meeting today, so we'll probably do an urgent agenda item on this since it's time sensitive. One of us will report back. |
Update on the forced upgrade to enterprise accounts. My plan this morning was for us to invite the Haskell GitHub org under the Haskell Foundation enterprise account, but there was a hitch. For whatever reason (I will be asking GitHub support about it) the Haskell Foundation GitHub org would not upgrade to an enterprise account for free. At $21/user/month it was a bit steep to pay all of the seats we would need for the HF and Haskell [1]. Luckily, the Haskell GitHub org was able to be upgraded to an enterprise account for $0. So we've made that the enterprise account The Haskell-Org Enterprise, and made the Haskell and Haskell Foundation GitHub orgs sub-organizations [2]. As part of the organizing we've ensured that the Haskell Foundation is down as the billing contact. We hope that nothing changes about the day-to-day operation of working on repos in the Haskell GitHub org. As for what other GitHub orgs should come under the same banner, my thoughts are as follows: If any GitHub org that is Haskell-based wants to sit under the Haskell-Org Enterprise, I think the answer should be yes by default unless it starts to cost the HF/H.org money. In that case it should still lean toward yes, but with slightly more scrutiny. But if the organization owners do not see value in coming under the same banner, that's also fine. There shouldn't be pressure to join. If something comes up, let me know. [1]: The current estimate per month for the Haskell GitHub org was ~$3k a month. @Bodigrim pointed out that there would be ways to reduce this cost significantly (changing as many organization members to 'outside collaborators' as possible), but it was still a significant sticker shock as compared to the expected $0. [2]: If you're wondering why we didn't grab 'Haskell', GitHub didn't let us! Claims it was taken already... |
Earlier discussions:
haskell-org/committee#10
haskell/core-libraries-committee#43
A good first step would be to document the repositories that are currently under this organization, who the owners are for those, and perhaps which repositories should be considered deprecated.
The text was updated successfully, but these errors were encountered: