Fair point. We did catch it internally in testing (as we use VS Code for all our work, so some folks did stumble on it), but I think we underestimated the impact and should do a better job at that.
This is honestly the most concerning part of all of this. You're saying you knew that this exact bug was present up front and still decided to release it?
This basically invalidates the entire premise that it was an innocent mistake. It's impossible for me to believe that you actually thought that people wouldn't care about 100% of their commits being attributed to Copilot even when it was never used. Either you're misconstruing what you caught with the testing beforehand or your entire development process is tainted, because there's no way that a non-evil corporation would see this default behavior and think that people would be fine with it. It seems far more likely you just thought you could get away with it.
I think there is a "ship fast" component here that should be adjusted. Product Management introduced weekly "stable" releases in March, no matter the content.
I think so too, but my point is that even according to their own words about what happened, the best possible interpretation is that they didn't mean to do it but knowingly let it happen. I agree that a worse version is more likely, but it's pretty damning when even the ceiling for what they can plausibly claim is "we intentionally didn't bother stopping it once it happened accidentally".
A generous read of this comment might be that you did catch it internally in testing AFTER it shipped but shrugged it off as something you'd patch in the next release in a week or two. Is that what you meant here?
Or that it was caught but didn't surface fully before release?
A helpful governance policy here might be that anything that mutates user content without opt-in consent requires a distinct sign-off or a double sign-off. If the goal is to prevent this from happening in future.
