Use of GitHub Enterprise | Hacker News Reader

Use of GitHub Enterprise

github.com

83 pointsghuntley42 comments

This stood out to me

> The bulk of the projects were migrated around August 2020. This was achieved by filing a GitHub support ticket

My team were repeatedly told it's not possible to move an existing organization into an enterprise account. The documentation also stated at the time.

GitHub only announced this functionality recently. https://github.blog/changelog/2021-09-30-github-enterprise-c...

Interesting, Github moved two existing orgs into an enterprise account in the last month for me without any issue.

> The bulk of the projects were migrated around August 2020. This was achieved by filing a GitHub support ticket. This also required an admin user in the org to confirm the changes, for which the dnfadmin user account was used.

Wow. They filed a ticket and then secretly used an admin bot user to accept the change? That sounds incredibly dishonest - not just an oops situation there.

What are they trying to get away with here? Is there a benefit to the dotnet foundation and corresponding cost to maintainers for an org being moved to the enterprise account?

I agree that it shouldn’t have been done in secret, but beyond that I don’t see any bad intentions here.

I don't know that they're trying to get away with anything. From reading some of the linked blog posts and issues, it sounds like some people involved in the management of the DNF effectively consider all projects beneath the DNF umbrella to be theirs to administer and change as they see fit.

And it sounds like the maintainers, rightfully, are wary about continuing with the DNF particularly because they haven't been consulted in years.

That sounds about right. I always wonder what is the benefit of moving your open source project to a foundation. My best guess is that it’s when you are just done dealing with the project and want somebody else to maintain it, but you haven’t found an individual you trust to take it over.

Once an open source project gets successful, there's a lot of pressure to do it, and among other things, gives the incumbents in the space some modicum of control

I disagree.

Looking at the broader context, it seems that the foundation simply considered the projects as "theirs" in some key ways, honestly thought the migration was best for the projects, and so opted for a mechanism that would be quick and easy for everyone. From that point of view, you could even argue that bothering busy maintainers to get them to approve some minor housekeeping was just a waste of time...especially if you believe - as the foundation seemed to - that this change was both helpful and properly the foundations responsibility and not the maintainers.

Obviously, that viewpoint was not shared by the maintainers! And, thankfully, the foundation has now repudiated it, but if you take their statements at face value, I see nothing strange about how they did it.

Yes that's a fair lens to view this situation with, I think, and I've stated a similar view in a sibling comment.

> it seems that the foundation simply considered the projects as "theirs" in some key ways

This seems like the core issue. But I disagree it is a simple mistake. "Oops. I simply considered your work as mine. Sorry my bad!"

All of these projects joined the .NET Foundation though. Was there any contract they signed or agreed to as part of joining the foundation? What were the terms the orgs agreed to?

I think we can all agree how the foundation handled this was really bad, but if you don't like having the risk of a foundation unilaterally doing stuff, don't join it a foundation?

Joining something does not mean automatically mean giving them authority on your work. Reading this page: https://dotnetfoundation.org/projects/submit

> The .NET Foundation uses either an assignment model or a contribution model for on-boarding new projects. Under the assignment model, a project transfers ownership of the copyright to the .NET Foundation. Under the contribution model, a project retains ownership of the copyright, but grants the .NET Foundation a broad license to the project’s code and other intellectual property.

I guess the impacted projects had not selected the "assignment model" in the first place.

> This move was a mistake. The board deeply regrets that this happened.

This post makes the _action_ sound like a mistake when in fact it seems that the _decision_ was a mistake (loosely defined).

The board made the decision and followed through with it (i.e. did not make a mistake) and now “regrets the mistake happened”. So not only are they not actually apologizing for their actions but they are not even taking any real responsibility for them.

Like someone slipped on a damn banana peel and fell on the “take over all projects” button. Sploops!

I think move in this case means the decision, not the literal migration of accounts. Or it means both. At the start it says "This change was a mistake", which makes me think that it could also be interchangeable with decision. Here I think it would fit best under "A change in strategy". https://en.wiktionary.org/wiki/move#Noun

I think decision is a better word for this, but it mostly gets the point across.

I think they are taking responsibility. I think it takes effort to read it in a way in which they are not apologizing for the decision.

At this point taking responsibility would mean changing the board members. There is no way the .net foundation can have any trust with those members. I am not sure that the .net foundation can still be relevant for anything after this.

They are new board members. DNF runs board election every year around august/september

That line on its own does read as if they didn't intend to move the project, but reading the entire post makes it clear that they consider the decision to be the mistake.

This is a good example of how to apologize when you didn't have bad intentions but just made a mistake. Lead with the apology, explain clearly why you did that, and follow with lessons learned and the next steps.

I don't know. "We should have asked the project owners before moving their projects". Why did this lesson had to be learned? This seems so naïve it is hard not to interpret it as dishonest.

There must be an explanation on why they didn't have any second thought about it and did not even took the time to notify the owners that they were making this change without any action on their part.

I think they are trying to model it after the Apache foundation. They did request/demand admin privileges first.

I don't understand how asking for priviledges first and taking them anyway makes it better.

Yeah, I think it was a mistake for them to just do it. I see what led to that mistake, though. IMO was reasonable to want to have this migration all done within months. They probably should have told people they need to make this change and said if they don't think the program is right for them now that it's changed, they can leave, but that they must comply if they want to remain. It's difficult to run a hands-on open source organization like Apache. It would be hard to lose some members, but better than having a lot of disagreements and having to maintain old organizational processes.

Maybe they thought that it was clear that they had the authority to move member projects to GitHub Enterprise. Maybe they thought that moving to GitHub Enterprise is solely a helpful move since it gives extra features to the the projects for free (by that I mean that maybe they considered it to be the equivalent of simply setting a flag on the project that gives it access to those features). Maybe there was miscommunication internally due to not having well-define protocols and someone thought it was safe to move the project.

I don't know if they'll tell us exactly what was going through the mind of the person who triggered the move, but I don't see any reason to assume that they can't change how they operate to be respectful of the project maintainers.

> Maybe they thought that it was clear that they had the authority to move member projects to GitHub Enterprise.

Seeing the various owner reactions this was obviously not clear for them

> Maybe they thought that moving to GitHub Enterprise is solely a helpful move since it gives extra features to the the projects for free (by that I mean that maybe they considered it to be the equivalent of simply setting a flag on the project that gives it access to those features). Maybe there was miscommunication internally due to not having well-define protocols and someone thought it was safe to move the project.

If no one in the .net foundation was able to raise an alarm about those transfers because of a "simple" lack of awareness of the importance of project ownership, then I don't see how they can rebuild the lost trust. They have demonstrated an absolute lack of understanding of their OSS community.

As you said maybe it is a process issue but simply saying "sorry we shouldn't have done that" is not transparent enough. Clearly at some point they were ok with those transfers since they were carried. And now they understand that it was a bad thing. What happened? Did the twitter/blog post backlash suddenly opened their eyes on the perspective of the project owners? If that is the case then what are the other things they need to realise in order to avoid making other mistakes such as this one?

Yes, part of the point of a foundation like .NET, Django Software Foundation, or Apache, is to have authority. It helps the creators of an open source project focus on doing what they enjoy, which is typically creating and maintaining software, and removes a lot of the hassle.

It is not a real apology without the list of names of people involved.

I’m not sure what to think of this. The only thing that struck me was that dnf “deeply regrets” their actions but also makes maintainers opt out instead of opt in. Maybe that makes the most sense at this point to cause no disruption to the maintainers that don’t mind. It just kind of felt like a whole lot of nothing I’d you deeply regret it but didn’t undo your action. Idk maybe I’m in the minority.

Taking another automated step with the account before getting permission would just be the same thing all over again, no? i get your point, but they're acknowledging that making unrequested changes was bad. doing it again would contradict that, I'd think.

Yeah, maintainers are already by this point well aware of what's going on and are basically looking for a reason to claim ownership of their projects again. I don't think this is an unreasonable fix for a one-time mistake (even though it was severe).

If I were a maintainer I'd be removing that dnfadmin bot ASAP anyway.

If my understanding is correct they can initiate a move out on their side, and owners would have to approve it in GitHub. That would be better than forcing everyone to email them.

> The primary goal was to centralize billing to give member projects access to additional GitHub services. A secondary goal was to ensure the continuity of membership projects, using requestable admin access, as just described.

Seems like a pretty obvious lie.

One of the people in the issues forum post about this pointed out how they had not only failed to give them "more services," but rather taken those "services" away over time. (1)

Why is no one else calling the obvious here?

Their foundation exec director got mad when someone called bullshit on giving the foundation admin over their repo to enforce "code of conduct." So the foundation exec director set out to get them to add the foundation's account to the admin list on their repos so that they could be taken control of in the middle of the night with no warning.

This is what happens when you have self promoting people with a privileged political status in administrative positions.

1. https://github.com/dotnet-foundation/Home/discussions/38#dis...

From a corporate perspective this has very little to do with CoC. It has to do with simplifying their life. CoC enforcement is surely and element on the list, but there are many others. As you noted, no one talks about it. Why? Because that is not the problem.

This whole crisis is not because of GitHub Enterprise usage alone. It is because of the absolute lack of communication and the disrespect towards the maintainers. That is so much worse than some CoC enforcement.

The details don't support that assessment.

Chain of events:

1) The CLA library requested by the foundation was reported broken by an admin one of the member project repos. That member project repo had refused to turn over control of said repo to the foundation specifically because of the perceived overreach in authority stemming from the code of conduct policy of said foundation.

2) The exec director, or someone on the foundation's staff, told the person reporting the issue with the CLA library that the solution was to make the foundation account an admin on their repo.

3) When the foundation is made an admin on said repo, the repo is silently transferred to the foundation's account in the middle of the night with no warnings.

4) Then, exec director force-merges a pull in another repo, of the same CLA library.

This is all a very useful glimpse into how corporations will use their diversity hires to get rid of people who refuse to give the corporation what it wants without any compensation or resistance.

Trust: easily lost and hard won. Looks like a small step on the path to recovery.

Can someone explain to me what the problem is. People were moved to the Enterprise account, and this is bad because they got access to GitHub Action minutes and Codespaces? I'm confused.

Projects were moved to the .net foundation organization. The .net organization obtained administrative authority on those projects without asking or notifying their respective owners.

Weren't the projects already owned by the .NET organization?

>Going forward, the Foundation will not make changes to member projects unless asked to do so.

You shouldn't have in the first place. People trusted you with their projects.

Absolutely

What about projects where DNF owns the copyright?

Good. A step in the right direction. Many more needed. But there are good ideas in this GitHub discussions threads... So there is hope.

Reply on news.ycombinator.com