Bug Bar Limbo
I just read Larry Osterman's post where he describes Last Checkin Chicken (http://blogs.msdn.com/larryosterman/archive/2006/10/25/last-checkin-chicken.aspx). Here in the localization team we have sorta the opposite. I like to call it "Bug Bar Limbo".
Dev teams usually have bug bars that are gradually raised during the product cycle, so the closer you are to release, the higher the bar is for deciding which fixes to take. Towards the end, only really bad bugs are accepted. No fit and finish work. In my team, things are different.
In the localization team, we're free to check in almost anything we want until the day we hit the magic "showstopper mode". Even though we're really close to shipping Vista right now, Swedish Vista isn't in showstopper mode, so I can still change pretty much whatever I feel like: move a button two pixels to the left to prettify a dialog slightly; fix a spelling mistake in an event log message; correct a preposition here, change word order there... anything goes. No approval or justification needed.
But, soon we'll be in showstopper mode, and then any change I make must meet The Bar. If an issue does not meet The Bar, it is not considered a Showstopper Issue, and so I can not check in a fix. It's at this point people start playing Bug Bar Limbo.
The idea behind Bug Bar Limbo is simple: If you can't get over the bar, you can always try sneak under it. Any tactic is valid: exaggerate the importance of an issue to try and make it seem like it meets the bar, maybe by claiming that the users in the market in question will be confused or even offended; justify the change with "well, my language has had so few showstoppers, so cut us some slack"; compare with other dubious bugs that were already accepted, maybe even in a different language or even a previous product cycle; piggy-back on other approved fixes in the same binary; check if the bug is repro in more languages, and if so start recruiting supporters for your cause...
At times it can appear funny how hard some folks will fight for what's altogether fairly trivial issues. Objectively, it probably doesn't matter if we reject many of the changes - the overall quality of the product isn't improved in any noticeable way. At the same time, it's amazing to see how passionate people are for their language and their Windows. I guess that's part of why people rarely leave this team.