In email environments, this axiom governs the dreaded FYI (for your information) syndrome. A scrap of information reaches Bob’s desk. He forwards it by email to Richard and Ellen, guessing rightly that Richard needs it, guessing wrongly that Ellen will care, and forgetting to include Sally, who for reasons unknown to Richard has just developed a vital interest in the matter. In a conferencing environment, Bob posts his message to a newsgroup that the whole team visits regularly. Richard briefly scans the message; Ellen skips it; Sally seizes it and puts it to immediate use.

When you offer information to a group, the push method (email) obliges you to identify the right set of recipients. The pull method (conferencing) allows recipients to self-select. But it imposes a different obligation on the sender. It’s Bob’s responsibility to post to an appropriate newsgroup, using an appropriate subject header, so everyone can rapidly evaluate the purpose and significance of the message relative to their needs.

In an email-only scenario, Bob’s correct identification of Richard as an appropriate receiver may still go to waste. Why? Richard didn’t need the information at the time Bob sent it; his need arose months later. With luck, Richard will remember Bob’s message and will be able to find it in his mailbox. But it might have been purged; it might not be locatable using full-text search; it might never have been downloaded to the laptop Richard’s using at the moment. In these cases Richard might prefer that Bob had posted the message to a newsgroup, so access to it would not depend on the state of Richard’s email client. Private newsgroups, like Notes discussion databases and Exchange public folders, are server-based data stores that can remember things more effectively than many email clients can.

When Bob emails Richard a message for which Richard has no immediate use, Bob may still have performed a useful service. Assuming that the information will become useful to Richard at a later time, Bob has a) transmitted it and b) alerted Richard to its existence. When Richard does need what Bob sent, he may remember that Bob sent it. But what if Richard doesn’t? What if Bob doesn’t either? Nobody else knows about this messaging event, so nobody else can help. Had Bob posted the message to the team’s newsgroup, the following dialogue might then occur:

Richard: “I’m researching LDAP and I can’t find a description of the LDIF file format.”

You can see the power of the hive-mind at work. But isn’t there a downside to all this wonderful information sharing? Not everything merits the attention of the group. Overloading the conferencing system with endless chatter will pollute it in the same way that email systems often are. Later I’ll show how scoped conferences can help you optimize discussions and cut down on information overload. Here, though, I want to raise the crucial issue of privacy. No matter how a conferencing system is organized, much vital collaboration will need to occur privately between individuals or among ad hoc groups. In these cases the mode of choice is clearly email. It’s no accident that the Netscape/Microsoft newsreaders use the same tools to view and compose messages as do their respective mail clients. Fundamental to the idea of Internet groupware is the synergy between these two modes.

To show how email and conferencing work together, let’s suppose that Bob and Sally decide to start a new project. They begin developing the idea face-to-face, but since Sally is often on the road, it evolves through a series of phone calls and email messages. Some of these messages are cc’d to Ellen, whom Bob and Sally recruit as an informal project advisor. When the idea gels sufficiently, they post an announcement to the whole group. The anouncement serves three purposes:

In the ensuing discussion, George raises an issue that Bob and Sally wish they had clarified before taking their idea public. Bob therefore responds not with a posting to the newsgroup, but privately to George and Sally using email. Because the mail and news clients share the same messaging tool, the switch from public to private discourse is seamless. Instead of replying to the newsgroup, Bob replies to George with a Cc: to Sally. He also uses Bcc: (blind carbon copy) to Ellen, to quietly keep the project advisor in the loop. (See the following tip.) Alternatively, George himself could have taken the matter offline with Bob and Sally before posting, and next time he will. In either case, public discussion can resume after an interlude of negotiation and compromise. For users of Internet groupware, the membrane that separates group from interpersonal spaces is selectively permeable. The tools enable you to cross back and forth as needed. Doing that effectively requires skill in the operational mechanics of email and conferencing, and equal skill in the social arts of computer-mediated discourse.

In one sense a newsgroup is a public space. A message posted there addresses nobody in particular but rather all current—and future—members of a group. In groupware lingo, we could say that that this form of communication is “role-oriented.” That suggests newsgroup structures ought to mirror organizational structures. For example, you might want to create one set of newsgroups for the engineering division and, within that, subtrees for project teams. I’ll talk more about why to scope discussion areas in the next chapter and show how to do it in Chapter 13. Here let’s just note an important fact about these kinds of scoped newsgroups: they can be made inaccessible, and even invisible, to nonmembers. Such a newsgroup is both public, because it stores messages that group members would otherwise exchange as email, and private, because only group members are present in the newsgroup.

A good basic design puts a few companywide groups at the tip of the iceberg and a larger substructure of departmental and team groups below the waterline. The companywide groups can carry broadcast announcements. These will typically be emailed too, but a newsgroup can store those emails centrally and make them available to people who weren’t on board when the announcements first went out. (See the following tip.) Can’t an email archive do the same thing? Yes, it can. There are, for example, innumerable ways to convert sets of email messages (or newsgroup messages, which are nearly the same thing) into web-based archives.

Companywide newsgroups aren’t just for announcements. They can also serve as a key rendezvous point for teams that usually collaborate in more private spaces. Sometimes a departmental issue needs to bubble up to the surface, gather broad-spectrum input, then return to a more private realm for detailed discussion and implementation. Companywide newsgroups are an excellent way to achieve that effect. In Chapter 4 we’ll see other examples of how and why discussions migrate among newsgroup scopes.

Although some people will speak up in public (sometimes too much!), others won’t. Departmental or team newsgroups that are too broadly visible will intimidate shy people. Sometimes these people will participate more actively in a more private setting. Do everything you can to make them comfortable. The more communication people are willing to share, department by department and team by team, the more likely it is that the system as a whole will reach critical mass.

When you ask industry analysts why groupware systems fail to reach critical mass, they usually point out—correctly—that there’s a kind of “tragedy of the commons” dilemma. Everybody benefits from the ability to tap into a store of pooled knowledge. But contributors aren’t rewarded. “Free riders” who never contribute enjoy an equal benefit, so where’s the incentive to add to the pool of knowledge?

You can appeal to the greater good, arguing that effective communication creates a competitive advantage for a company and yields benefits that trickle down to everybody. But trickle-down rewards are notoriously poor motivators. Why not appeal instead to enlightened self-interest? If I store my project-related documents in a newsgroup that serves as a central repository, I can realize purely selfish benefits. Just as with email, I can find those documents later by scanning the newsgroup along its dimensions of subject, author, and date. But unlike my client-centric email, this server-based newsgroup can be available to me anywhere, anytime, from any computer (see the earlier tip). When newsgroups are indexed for full-text search (we’ll see examples of how to do this in Chapter 8 and Chapter 13), the case is even more compelling. It’s ironic but true that relatively few local filesystems can be searched as effectively as can the Web. We can often find things “out there” more easily than we can find them on our own hard disks. If I might want to find something later, I have an incentive to put it someplace where it will get indexed automatically.

For example, I ran a development team for several years that not only discussed ongoing work in team newsgroups, but also routinely posted project-related documents there. These included email messages received from elsewhere in the company or from outside, web pages we found while researching hardware, software, and networking issues, and records of all the changes we made to our servers, the commercial software we ran on them, and the custom software we built ourselves. We could have used a combination of email and our local filesystems to store all this stuff. As we got into the habit of posting documents to our newsgroups, though, we found this was no more difficult than the email or “File Save As...” methods of saving the stuff. Since we all tended to work from multiple machines and multiple locations, the central and searchable newsgroup paid big dividends. If you know you’ll have “anywhere, anytime” access to a document, you’re more likely to take the trouble to file it properly. That’s enlightened self-interest at work.

Knowledge workers deal with a relentless flood of information. Even when people want to categorize, file, and share the most important documents that they create, receive, and find every day, they’re operating under brutal time constraints. If it takes more than a couple of seconds to move a document into a shared repository, it’s just not going to happen. Here’s where the close integration between the news, mail, and web clients really shines. A newsgroup isn’t just a place for discussion. It can also be a convenient repository for email, and for web pages, that are of interest to a group. It’s true that a newsgroup doesn’t enable you to define custom fields—things like ProjectName, Category, CompletionDate, or Summary, for example. Sometimes, though, less is more. Customized docbases are great for certain uses, and Part II is full of examples showing how to build and manage them. But these are really for line-of-business applications: status reports, trouble tickets, and other sorts of documents that people are required to create. Many more documents can be usefully shared in a team repository—for example, an email from a vendor about a software bug, or the web page on the vendor’s site describing the workaround. These kinds of documents are, in aggregate, a vital information resource. Yet there’s never time to build forms to catalog them, and even if you did, nobody would have time to fill out those forms. But it’s a two-second operation to route an email or a web page into a project newsgroup. You can do it from your mailreader, or your web browser, with virtually no disruption or loss of context. It’s as easy as mailing the email or web page to your team but better for a number of reasons.

How do you route an email into a newsgroup archive? Netscape Collabra can forward a message from the mail domain to the newsgroup domain. While reading an email message in the mailreader, use the Forward button to launch an instance of the message composer that contains a copy of the message you were reading. By default the composer presents a To: header that invites you to type an email address. Use the dropdown list of headers to instead select a Group: header, which invites you to specify a newsgroup. Then type the name of an appropriate local newsgroup—this might be something like webteam.mailarchive. Note that this newsgroup name implicitly refers to the default news server specified in Communicator’s preferences—that is, Preferences → Mail & Newsgroups → Newsgroup Servers. When you use local newsgroups as described in this chapter, you can also maintain connections to external news servers (e.g., msnews.microsoft.com), but your local NNTP server will be most effective when it’s the default server.

In Outlook Express, the Forward button works only in the email domain. The message composer that it invokes won’t let you specify a Newsgroups: header. Fortunately there’s another—and arguably better—way to get the job done. You can drag the message from the inbox and drop it onto a local newsgroup! This action launches a message composer with a copy of the email message. And unlike Collabra, which requires that you type the name of a local newsgroup, Outlook Express automatically fills in the Newsgroups: header.

You should always try to write a descriptive Subject: header for newsgroup postings. In this case, Collabra prepends “Fwd:” to the existing message title, while Outlook Express leaves this field blank. Neither method is adequate. When you route email into a newsgroup, you’re consuming a scarce resource—the attention of the people who monitor that newsgroup. Write a Subject: header that tells readers of the newsgroup specifically what this message contains. My email inbox, for example, currently contains several dozen messages labeled Subject: re: server-side performance. That title tells me nothing about the fact that the server in question is a web server or that the performance issue at stake has to do with Perl’s XML parser. Only a few of these messages are keepers. Were I to forward one such message to a local newsgroup, I’d retitle it “Perl-XML performance: Nathan Kurz’s benchmark results.”

This rule about rewriting Subject: headers applies to responses as well as to new postings. If you take the trouble to respond to a posting, it’s presumably because you’re contributing something new to the discussion. Say so in your message’s title! Some people think that the default title—e.g., “re: Perl-XML performance: Nathan Kurz’s benchmark results”—must be retained in order to preserve thread hierarchy. Not so. In some email environments, threading may depend on pattern-matching in message titles. But newsreaders don’t use titles for threading; they use NNTP message IDs in the References: header. There’s no reason not to write a fresh, descriptive title for every message that you post to a newsgroup. When you do write fresh titles, you help everyone scan the newsgroup more effectively.