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)?
show comments
dotwaffle
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?
show comments
simonw
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.
show comments
wseqyrku
> How GitHub gave every repository a durable owner
Yes they did. I mean, GitHub is pretty durable.
charcircuit
>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.
shevy-java
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.
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)?
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?
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.
> How GitHub gave every repository a durable owner
Yes they did. I mean, GitHub is pretty durable.
>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.
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.