I'm interested in communication between people. This is part of the reason that I find LiveJournal and other social networking software so interesting - it shows relationships between people simply, and allows communication between them as well. (And if you think LiveJournal isn't social networking software, you don't understand the term: Building relationships and the results of them is a huge part of this site.)
There are a number of different ways that I communicate with people around me. The first is the people I'm physically close to: people who live on campus and near me, that I can actually see in real life. This method of communication is good in lots of ways - quick, face to face discussions can achieve a lot in the ways of interpersonal relationship building. However, it doesn't work very well in technical situations. You can't teach people how to program in a face to face situation. Spoken language can't convey many of the technical needs that learning non-spoken languages requires. Spoken language is great for relationships, but not for technical discussions.
The same applies to phone conversations, but even more so. In a conference call, you can discuss ideas, you can toss around plans, but you can't actually get down to the meat of implementation. I'm likely biased because that's where my work centers, but I'm a coder, and you can discuss high-idea plans over my head all day, but until you get down into telling me what the next feature to code is, and suggestions for coding it, I'm just going to sit and twiddle my thumbs.
Online communications are where this kind of thing. In group based online communications, there are a number of different ways of working through things. Some of the communications methods I use are email, IRC, and wiki-based information storage.
IRC is similar to phone conversations in that it's designed more for social and discussion based issues rather than coding. However, the ability to say "Let's take a look at line $foo in my patch at [link]" and actually discuss function calls, variable naming, and similar topics makes it a quick real-time medium for discussion of possible issues. Implementation ideas can be discussed, and then everyone can just kind of hang out and hack.
E-mail is one of the best methods for patch discussion. Technical patches can be attached, with long explanations of why things are done the way they are. At the same time, you get the group aspect with things like mailing lists, and you can discuss issues back and forth all day. Not the best way to build social relationships, perhaps, but a great way to hack on code. Bugzilla based systems are simply extensions of this - they allow you to do patch-level discussions in a mailing list format, a truth accentuated by the fact that many of Bugzilla's features are based around email and sending it out to people who want it. This is one reason why Bugzilla is a great system even in small setups - it's the forefront (as far as I know) of issue and feature tracking software.
Wiki based storage is great for a lot of things - documentation, general plans, outlining of todo lists, and so on. Wikis are much more of a form of permanent storage - slower than any of the previous methods mentioned, even with things like RSS feeds for Recent changes. Socialtext workspaces avoid this a little bit by creating mailing lists of recent changes that get sent out on a regular basis, keeping people up to date on what's changing in the workspace. However, the social aspects of most communications are almost completely gone.
Social communications exist in many aspects of almost all projects. Whether you're talking real life, phone, IRC, or email, there's always drama. (If you think that things like Zilla avoid Drama, just see some of my discussions with marksmith from a couple months ago. ;)) Wikis avoid this, obviously, but are clearly more of a form of permanent storage rather than an interactive communication medium. For idea discussion, real life or phone is best, but for patch discussion, email is the place to be.
Some people try to separate the social aspects of working on a project from the technical aspects. The idea that this can be done while achieving any kind of reasonable productivity level is ridiculous - you have to be able to interact with the people you work with to get anything done. This is part of the reason why people like bradfitz don't make the best project managers for large scale projects. He works pretty well on things like memcached where he's the maintainer and the largest contributor to the code, accepting patches from people who have a high level of technical skills. That kind of project is much easier to deal with, because the people act in a professional way - which many people who volunteer their time for LiveJournal do not. They (and I include myself in this) seem to have some kind of expectation of having their code looked at by people who can accept it - and when code is bad, many people don't have any desire to look at it. Managing a project with patches from people who really don't understand the technical aspects of the code they're patching is frustrating, and difficult to work with.
I'm a code monkey - I don't do management well, I'm a drama queen (or have been in the past at least - I like to think I'm starting to move past that), and I'm not the best at interacting with people. But interacting with people, through many of the media describe above, is necessary in so many cases that to ignore social interactions in a project is simply ludicrous.