Reading/Multimedia/Communication guidelines

These are guidelines the multimedia team hope to use in conducting their communications about projects, process, and any other team dealings. If you'd like to help us keep a sane system, please use these guidelines when in contact with the multimedia team via their several lists, IRC channels, and other media.


 * 1) If it doesn't happen on a mailing list, it didn't happen at all.
 * This rule has worked well for mobile, based on their reports, so it seems like a natural place to start.
 * 1) Use either multimedia-l or multimedia-team unless you have a great reason not to, with a preference to the former.
 * We use the -team list, and manual CC lists, way too extensively - as a community-oriented organization (and team!) I'd like to see us be a bit more transparent. How to enforce this is something I haven't really thought through.
 * If someone's not on the -team list, we can add them, and manual CC lists are hard to maintain and not archived anywhere. Moving to the list is a far superior method in my view, and CCing can still happen when Erik or Lila or other non-team people need to be brought in.
 * 1) Use #wikimedia-multimedia for quick clarification or higher bandwidth.
 * Having long discussions on IRC, especially ones we need to refer to later, will make it hard to keep up with conversations sometimes. A good bouncer setup, and proper stalkwords, are only part of the battle. See also guideline #1. :)
 * 1) Use private messaging on IRC only when necessary.
 * Good reasons for PMing someone are everywhere, but if you can use the public IRC, that should be preferred, it will keep everyone on the same page.
 * 1) Be familiar with etiquette on various communications media.
 * Obviously we don't want to derail conversations on list or IRC, so reminding ourselves of the best practices on those media is probably a good idea :)
 * 1) Share information on-wiki.
 * If there's not documentation on-wiki, much like rule #0, there's not any documentation. It's better to use this for collaborative document editing, UNLESS you need real-time collaboration. See below.
 * 1) Use Etherpad unless you have a good reason not to.
 * Having Google Docs might be a good way to collaborate at first, but especially with the call for transparency above, Etherpad strikes as preferable.
 * 1) Make Google Docs documents world-readable and world-commentable unless you have a good reason not to.
 * If you absolutely need the commenting feature, or some other feature, of Google Docs, that's probably sufficient for the above – but it's better to make the documents public, at least, so we can share them with everyone!