One of the trickiest things about managing an open source project is getting people to be thoughtful about which forum they choose for different kinds of communications. It's tricky partly because it's not immediately obvious that it matters. During any given conversation, the participants are mostly concerned with what the people involved are saying, and won't usually stop to think about whether or not the forum itself gives others who might want to take part the opportunity to do so.
For example, a real-time forum like IRC is terrific for quick questions, for opportunistic synchronization of work, for reminding someone of something they promised to do, etc. But it's not a good forum for making decisions that affect the whole project, because the people who take part in a conversation in IRC are just whoever happened to be in the channel at that moment — it's very dependent on work schedules, time zones, etc. On the other hand, the development mailing list is a great place for making formal project-wide decisions, since every interested party will have an opportunity to see and respond to the relevant posts, even though it's not as well-suited to quick, real-time interactions as IRC is.
Another example comes up frequently in bug tracker usage, especially in the last few years as bug trackers have become so well integrated with email. Sometimes people will be drawn into a discussion in a bug ticket[44] and because they simply see project-related emails coming in to their email client, they treat the discussion as though it's happening on the real development list. But it's not: anyone who wasn't watching that bug and wasn't explicitly invited into the conversation won't even be aware it's happening. If things are discussed in that bug ticket that go beyond the scope of just that one bug, they'll be discussed without input from people who should at least have had a chance to participate.
The solution to this is to encourage conscious, intentional forum changes. If a discussion starts to get into questions beyond the scope of its original forum, then at some point someone involved should ask that the conversation move over to the main development list or some other wider forum.
It's not enough for you to do this on your own. You have to create a culture where it's normal for everyone to do it, so everyone thinks about forum appropriateness as a matter of course, and feels comfortable raising questions of forum whenever necessary in any discussion. Obviously, documenting the practice will help (see بخشی بنام “Writing It All Down” in فصل 4, Social and Political Infrastructure), but you'll probably also need to remind people of it often, especially when your project is starting out. A good rule of thumb is: if the conversation looks convergent, then it's okay to keep it in the bug ticket or other original forum. But if it looks likely to diverge for a while (e.g., widening into philosophical issues about how the software should behave, or raising design issues that go beyond just the one bug) before it converges, then take the discussion to a broader forum, usually the development mailing list.
When a discussion moves from one place to another, cross-link between the old and new place. For example, if discussion moves from the ticket tracker to the mailing list, link to the mailing list thread from the ticket, and mention the original ticket at the start of the new list thread. It's important for someone following the ticket to be able to reach the later discussion; it's also important for someone who encounters the ticket a year later to be able to follow to where the conversation went to in the mailing list archives. The person who does the move may find this cross-linking slightly laborious, but open source is fundamentally a writer-responsible culture. It's more important to make things easy for the tens or hundreds of people who may read the bug than for the three or five people writing about it.
It's also fine to take important conclusions or summaries from the list discussion and paste them into the ticket at the end, if that will make things convenient for readers. A common idiom is to move discussion to the mailing list, put a link to that thread in the ticket, and then when the discussion finishes, paste the final summary into the ticket (along with a link to the message containing that summary), so someone browsing the ticket later can easily see what conclusion was reached without having to click to somewhere else or do detective work. Note that the usual "two masters" data duplication problem does not exist here, because both archives and ticket comments are usually static, unchangeable data anyway.
[44] For example, on GitHub,
simply mentioning someone's GitHub account name with an @-sign (e.g.,
@kfogel) in a comment on a ticket will cause that person
to be added to the email thread associated with that
ticket.