But, as it appears, I'm only human....
I work in the web development industry (as most of you know). I write J2EE web applications. I've done so for a while now.
How we work is this: We all work individually on the project, using source control (mostly clearcase, which is a blessing, but sometimes we have to settle with CVS). Anyway, once we get to a milestone, or fix our critical bugs, we send the entire code to the 'integration' step. In this step we compile everything, and do you 'basic run-through' of the app to ensure that the basic functionality still works. If everything is ok, it gets sent to 'QA' where it is hit with regression testing (mostly scripts) and human testing of the new functionality (or fixed functionality). When it clears QA, the user base is notified that a change in the production server will be made (given plenty of notice), then the change is made when the app is used least (middle-of-the-night).
Is that so odd? Why doesn't slashdot use this basic software lifecycle (most coding houses use this, it isn't a rarity)? Bugs, like making all users post without +1 would be caught in the integration step (if not, it would DEFINATELY be caught in the QA step). And, if it was a more complex of a change and makes it through QA without the bug being caught (yeah, it does happen often), when the users know, they will be on the lookout for it.
Is this just how open source projects work? Since there isn't much rhyme and reason, just developers itching a scratch, does QA and testing just blow out the door, and all changes go through without notification and the assumption is that it won't hurt anything? It that's the case, there is a serious problem here... Or is slashdot simply the testing ground for slashcode?
Addendum: For clarification, we do use RUP for our projects (not waterfall).