How GitHub gave every repository a durable owner

https://github.blog/security/application-security/how-github-gave-every-repository-a-durable-owner/

by ascertain • 13 days ago

88 26 13 days ago

simonw• 13 days ago

A previous employer hit the problem where there were a ton of legacy features that didn't have clear owners and so it wasn't clear where to route bug reports.

Their solution was to build a catalog of every feature and then assign EVERY one of them to an existing team.

Teams might end up responsible for features that they had never seen before and had no knowledge of... but that was fine, because every other team was in the same situation.

It worked great. Bugs got fixed. Teams figured it out.

MeetingsBrowser• 13 days ago

It’s like the bystander effect but for code, lol.

Just pick someone and give them the task.

infinite_spin• 13 days ago

One thing I've learned from responding to emergencies is that you can't just yell "help" at a crowd, you have to pick out someone specific and say "You, dial 911."

We had someone collapse on campus and have a seizure. An entire group of people stood around this person as they wet themselves, nobody doing anything but watching. I picked out specific people from the group to help, told them what to do, and told everyone else to back away. There was even some guy who got pissed at me for telling him to leave the area, but he's exactly the kind of person you want out of the way.

Lesson here, be specific, be aggressive, and take charge when it's needed, because it's very unlikely that a bystander will do anything but watch.

Chaosvex2• 4 days ago

On complex codebases, I've seen this strategy absolutely decimate team moral.

A large tech company decided to stop having subteams responsible for particular features or areas of the code for one of their products. The result was developers having to spend inordinate amounts of time researching highly complex spec documents and reference manuals on a daily basis for even the smallest of fixes. It drove moral into the ground and developers started a mass exodus to other teams or tech companies.

After some changes of management for the team, the policy had to be reversed to stem the bleeding. Turns out that developers don't like permanently being in unfamiliar territory.

hilariously• 13 days ago

The truth is that accountability isn't the problem, its the lack of resources, prioritization, and ability to change things that make them burdensome. After a certain point you're just trying to solve the problem in the least annoying way possible.

alexpotato• 13 days ago

I've often seen something similar happen in places with high turnover.

Team owner leaves or is let go and then their projects get randomly assigned to other people.

That's not terrible. What is terrible is when there is no mechanism for swapping or trading projects.

warumdarum• 4 days ago

Git blame -> graph of all employees , route from ex employees to successor or departmenthead

esafak• 4 days ago

Just make sure you retain the org tree history.

onion2k• 4 days ago

This is a top-down incentive problem. If teams are rewarded for making things work, fixing problems, and keeping the lights on they'll pick up ownership of orphaned projects.

If they're only rewarded for feature delivery then they won't, and they'll push back on being given any non-feature work like maintaining things.

lloydatkinson• 4 days ago

I don't know how I feel about this. Ingenious perhaps. But then again, being assigned some absolute slop riddled with tech debt arbitrarily could be particularly cruel.

shevy-java• 4 days ago

GitHub needs to solve the problem when one owner suddenly becomes inactive. Yes, you can fork things, but it would be so much easier if just new maintainers could continue as-is.

Naturally some problems must be solved for this to work, but I now have a few examples of projects that kind of died when the old maintainer (solo guy) became inactive. For instance the guys at BG2 at spellhold-studio solved this via a fork (from spellholdstudio to spellhold-studio). But it would have been so much easier to just let them continue as-is. This is one example of many more that could be given here.

dimes• 4 days ago

Don’t organizations solve this problem?

flyingshelf• 4 days ago

How do you prevent hostile takeovers? That's the core issue here.

Owner X died and the next 6 contributors don't care about the project. Here comes Ron, with his 3 PRs from 2020, suddenly able to publish releases as if X is still here.

There are so many dead projects where the author doesn't even care to assign the next person, what do you do then?

I think forks are the best thing we got at the moment, with potential for some social bidding at the package registry level ("I vouch for Ron to take over the package, as I'm a known FOSS contributor")

johnny22• 4 days ago

that's exactly the kind of thing that would cause another xz-like attack or all the recent credential stealing malware .. except you can skip the malware part a lot of the time.

wseqyrku• 4 days ago

How GitHub gave every repository a durable owner

Yes they did. I mean, GitHub is pretty durable.

dotwaffle• 4 days ago

Needing to list an "executive sponsor" (an individual, not a role or a team) for each and every item in a service catalogue seems like mindless bureaucracy.

Meanwhile, having "custom properties" attached to each repo feels very much like administering JIRA, and schema-less YAML blobs that pervade the GitOps world.

Is it just me, or isn't the glaringly obvious solution to this an actual database and API, rather than just tacking on random bits of metadata that have no real-time validation etc?

dandellion• 4 days ago

This is Microsoft we're talking about, they'd never do the glaringly obvious solution when mindless bureaucracy is an option.

3eb7988a1663• 4 days ago

As to the "executive sponsor" -clearly this is going to result in more "god" repos which keep accumulating responsibilities because nobody can be arsed to go through the official approval channels.

Source: my workflow once they required various TPS forms to be completed before you were allowed to create a new repository.

charcircuit• 4 days ago

GitHub had over 14,000 repositories.

I'm surprised the idea of reducing the number of repositories wasn't floated. Having extremely big cardinality, 1 github repo to 14,000 repositories you are going to struggle with ownership compared to an organization owning a few folders within a repository and those folders hold multiple projects. This feeling of closeness to other projects makes ownership feel more natural than where a repository feels like it's out in the middle of nowhere.

It's easier to assign ownership to a single directory than having to track it for n possible projects within it.

roadbuster• 4 days ago

If there weren't "clear owners," who was approving code changes for merge?

Every other major arm of Microsoft has been tasked with burdensome controls over tracking any and all production changes to source code, but Github was operating without a useful system and record of ownership for nearly 80% of its repos (11000/14000)?

woodruffw• 4 days ago

I think they mean "clear owners" as in "responsible individuals," not that the repos literally lacked people with merge approval rights.

Onavo• 4 days ago

And presumably a bunch of employees left and no longer has access to it.

hamdingers• 4 days ago

Given over half were archived as part of this effort it's likely nobody was making code changes that needed approving.

Guvante• 4 days ago

For repositories attached to production services, we have historically had robust durable ownership, but for repositories with no associated service, there was no reliable way to tell who the owner is.

How GitHub gave every repository a durable owner

Related Stories