DRAFT

With the availability of numerous forms of communications technology, and the distributed nature of open-source development, how can and should JA-SIG communicate? This document attempts to:

Denote various communication channels available for JA-SIG communications
Describe communications philosophy
Illustrate community consensus on the appropriateness of various communication methods to particular situations

Resources

Resource	Details
IRC	##uportal on freenode, logged into Confluence
Email	project & topical mailing lists
Videoconferencing	IU Bridge, point-to-point
Conference Calls	Various phone bridges
Newsletter	email newsletter@ja-sig.org
Wiki	JA-SIG hosts and uses Confluence, which has become the primary source for crystallizing conversations into documentation
Issue Tracker	JA-SIG hosts and tends to use JIRA, though Google Code is also used by some projects

Philosophy

1. Communicate Asynchronously whenever possible

While synchronous communication tends to have higher bandwidth, it also incurs significant organizational overhead. Heroics are required to announce and schedule the call, to agenda the call, to take minutes from the call. We can get more formal and timely about documenting calls, but that means extra work because the means of communication chosen requires it.

Because scheduled calls happens at a particular slot in time, busy people cannot make the call. This creates both scheduling challenges (which delay communications) and problems with not being able to involve the correct people due to scheduling constraints.

Additionally, most synchronous mediums require manual generation of minutes or summary communication. Which leads us to point 2.

2. Communicate electronically, in public whenever possible

Contrast what happens if we, Apache-style, embrace email lists for example. Because the
discussion is asynchronous, busy people can choose to make time to participate at any time slot they have. Jon and Jason are not blocked by the accident of scheduling of other commitments. Heroics are not required to announce, schedule, agenda, record, the conversation, since the act of conversing naturally does all these things.

Email lists tend to bias participation towards people who choose to make time to be involved (vs. those who can schedule particular slots). People with no time at all still can't participate. But volunteers with any time at all can participate. We get more participation of people who have busy days but still care. That seems like a better characteristic to select on for success.

3. Involve the broadest practical slice of the community

At times however decision making, collaboration, and creativity may require the higher bandwidth available through a synchronous communications medium. In this case or value for transparency, open-ness, and inclusiveness still recommends a medium like IRC which is automatically logged and published over approaches like conference or video calls.

In the event that a conference or video call is the most appropriate collaboration medium, public notice and notes should be available for later review.

4. Distill information communicated into documentation

Mailing lists and other conversation-focused forums can feel unapproachable, and are often poor formats for recurring questions, or information which is not-temporally sensitive, but has lasting value. If a record of information, or decisions has lasting value – it has become common practice to create a wiki page describing that information. From there it may also work it's way into other formats such as the web, manuals, etc.

5. Distill action items into tasks which can be tracked and commented

Any tasks which are revealed as part of a conversation which are non-trivial should be placed into an issue tracker so they can be monitored, assigned, and documented.

References

Apache has an excellent writeup on their thoughts on communications and community in a distributed environment which favors open-ness and transparency which also maps well to JA-SIG:

http://www.apache.org/foundation/how-it-works.html