alt Hacker NewsThis was a performance driven change. We added this as loading a cross repo issue is a much slower experience than loading an issue in the same repo due to the way the header is loaded (which is being worked on).
But we hear you on the feedback - we will roll this back while we keep pushing on the root performance causes.
[update - this change has been reverted and the previous behaviour is back]
Replies
How did the performance of GitHub become so slow in the first place? It didn't used to be this bad years ago.
> update - this change has been reverted and the previous behaviour is back
was an on-call engineer paged for this on the weekend just to roll a revert instead of waiting until Monday?
To be honest GitHub should have like a switch for "preview stuff adopter" where you guys could give any benefits for it (maybe more copilot usage?). This way you can test with a specific public, using metrics and feedback, while testing and people could comment more about it.
Can you elaborate? The header meaning the top part of the page? I just checked on a recent repo I visited and it has the usual banner (which would stay the same), the repo path, some links, and some stats. Considering every page navigation would likely pull which links and stats are shown, why is this a delta to go to another repo and why are presumably 3 database entries (possible links, stars, forks) so slow?
> loading a cross repo issue is a much slower experience
Why not solve the real problem instead of putting in a janky workaround?
At risk of being cliche, it seems like you guys could benefit from the 5 Whys approach here: "Why is loading a cross repo issue slow?" and iterate until you discover the root cause, and fix that.
I suspect fixing the root cause is going to be a lot less glorious career-wise than implementing a UX change that is easier to tout at review time (well maybe not so much after this debacle).