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)?
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?
Source: my workflow once they required various TPS forms to be completed before you were allowed to create a new repository.
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.
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.
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.
Just pick someone and give them the task.
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.
Yes they did. I mean, GitHub is pretty durable.
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.
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.
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")