alt Hacker NewsI recently left Google having worked on a number of projects with various YouTube teams. I think I can explain why it's being handled this way by YouTube.
This is a fairly nuanced/involved issue, so the task of classifying the bug likely made it's way to one of the engineers responsible for the implementation of this feature.
That engineer has already launched this project, and filed it away under their GRAD (performance) artifacts for when promo/annual review talks roll around. There's no motivation for this engineer to waste time fixing this bug because it won't benefit their promo packet, and they are already being put under pressure to launch other projects which _will_ benefit their promo packet.
So they do what they can to sweep it under the rug because that's what the promo/annual review framework (GRAD) incentivizes and rewards.
Replies
I feel like things have become so much more cynical in the last 5 years, in this regard.
I feel like part of it is the "over-systemization" of promos. I see the logic behind it to some extent - if there's a system, it's "fairer"/"more democratic". But, then we end up with ridiculous gamified promo systems.
Glad to hear this is a universal big tech experience. The promo process is entirely antithetical to shipping good products
This is what you get when the MBAs are in charge. They just go with P&L, Spreadsheets, etc. and care only about the current quarter and meeting the goals.
The rot is deep.
Of all the fucked up things in this comment, giving a single Engineer lifetime responsibility for all bugs in code they wrote is probably the dumbest.
And it's slowly becoming the norm. The last place I worked at, a large and well known Tech company, didn't even roll with QA's. That just wasn't a role anywhere in the division. You are fully responsible for all the bugs in all the code you ever wrote
Cute at first. Unsustainable in the long term
I also used to work at Google and what you have described is not the way the VRP works at all.
1. The engineers on the VRP teams set the severity of the bug based on impact. The engineering team responsible for the fix can argue the severity but only if they can show there is some other mitigating factor that the VRP team wasn't aware of.
2. Google has a great security culture and while it may be true that maintaining existing code may not be as sexy as building new features, fixing vulnerabilities does look good on GRAD (performance) because the impact is already well documented.
3. Believe it or not, the VRP team does like to give away rewards. However, to do this, they have to follow a rubric to keep all of the payouts consistent and fair.
4. Constructive and polite discourse is welcome and a researcher may reply to their bug asking for more details or to make their case in the event that they think the VRP team did not understand the severity. The team is made up of humans who are open to the idea that they missed something in the initial report. They, like all other bug bounty programs, are also struggling to keep up with the huge influx of AI generated slop so mistakes can happen.
It's ultimately Google's responsibility to ship bug free products. I don't care who implements a fix, but Google management should make sure someone fixes it.
[dead]
I design and build trains.
If I ignored a safety issue that I discovered - not one I caused by design but even one I discovered in an existing design - because of a performance review my engineering licence would be revoked and I would be kicked out of the industry.
This is a prime example of why programmers are not seriously considered engineers.