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.

2. 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.

3. 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. :)

4. 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.

5. 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 :)

6. 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.

7. 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.

8. 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!