Best practices in scheduling a meeting/br

This page is a translated version of the page Best practices in scheduling a meeting and the translation is 5% complete.

We schedule a lot of meetings in Wikimedia: often online, across multiple timezones. Here are some best practices and tools.

Emvodoù enlinenn

Picking a day and time: in general

  • Find out what time zone(s) or cities your participants will likely come from. Meeting during the standard workday and commuting hours may work for some people but definitely not all; many (perhaps most) volunteers can only participate in the evening or on weekends.
  • This UTC-converting meeting planner will help you find a good range of times.
  • If you have people in all areas of the globe: eg. Australia, California, Europe -- you will probably have to schedule (at least) two meetings to make the times work. Otherwise someone has to stay up till 1:00am.
  • Announce all times in 24-hour UTC time. Providing a few standard conversions (e.g. to PST, IST) and a link to the worldclock site is helpful. Saying "the meeting is at 1:00" is useless without context.
  • Seasonality: Be aware of summer/winter time (aka daylight savings) pitfalls! Countries change in different weeks; sticking to discussing times in UTC (which does not change) is always the safest bet. The meeting planner tool (and these two links 2012 calendar, upcoming changes) will alert you if a certain country is in summer time. Note that referring to the seasons in communications about meetings is unhelpful, as we have participants in both hemispheres.
  • Be sure to give enough notice: at least a full week, and preferably longer. Many people have work and travel schedules that are set several weeks in advance. Announce the meeting on the appropriate mailing list and wiki talk pages. Make sure you send it the appropriate public lists if it's a public meeting.
  • Send a reminder to the same places the day before the meeting.
  • Be aware of other meetings that may happen at the same time, and try to avoid conflicting with them. (Is there somewhere that other meetings are likely to be recorded?)

Picking a day and time: small group

  • For a small group where everyone has to participate, the poll tool Doodle is extremely helpful. Anyone can create a Doodle poll and anyone can fill it out. Here are some best practices in using Doodle (corresponding to the steps of setting up a poll):
    • Step 1: (general) -- provide a descriptive poll name and definitely provide your email address.
    • Step 2: (time proposals – days) -- provide multiple day options, being sure to give enough notice.
    • Step 2: (time proposals – times) -- provide multiple time options, following the guidelines above; you might want to use the worldclock tool first to get a range of acceptable times. Important: click the "enable time-zone support" and make sure that you are entering times in the proper time zone (PST, UTC, etc). Clicking this link will enable all participants to select their own timezone when they see the poll.
    • Step 3: (settings) -- choosing the "settings" link then selecting "yes-no-ifneedbe" is helpful, as this enables people to show they times when they may be available.
    • Step 4: (invitations) -- select "you send the invitation" as this will give you a link that can be posted in email, on the wiki, etc.
    • Doodle will also send you an administration link; you can use this to edit the poll.
  • Alternately: posting a range of days and times on a wiki page and letting each person sign underneath the times they are available also works well, especially when the meeting is public but small, and every participant is likely to be on the wiki.
  • It is easy to get carried away with providing participants with a large number of date and time options, which can make it difficult for participants to fill out the form, and for the coordinator to pick an optimal date. Try to keep to around ten options that are already likely to be suitable to the majority of participants (this varies a bit depending on the group -- some groups of busy people need more options, some need less).

Venue

Try using the Event_Center/Registration tool to schedule your event.

  • IRC: see Best practices in hosting an IRC open meeting and related documentation. If using IRC, be sure to announce the channel in your communications, and also make sure that someone has ops.
  • Google Hangouts: can be used for up to 10 participants, or 25 if organised by someone with a @wikimedia.org email address.
    • Note that hangouts under the Wikimedia account will be restricted by default and not allow external people to connect.
    • You need to click the invitation icon in the top right and change the hangout from "Wikimedia Foundation only meeting" to "Anyone with the link". This has to be done every time you open the hangout (it doesn't remember what you used last time).
    • Even with "Anyone with the link" selected, every joining participant will have to be manually approved by the meeting organiser as they join.
  • Other online venues (webcasts, Skype, etc): do you have everything set up? What do people need to join the meeting? Be sure to include this information. See video meeting recommendations for tips on running a meeting in Skype.
  • Have you considered how many people will be joining the meeting, and whether the venue supports that number of people? (e.g. Skype voice chat runs into problems beyond 5 participants.) Also consider the types of participation needed (e.g. full participant, real-time 'lurker', post-meeting listener) and design the venue as appropriate.

Notes on UTC

  • here is a quite technical article about UTC
  • here is a less technical article
  • Things to know: UTC provides the standard for world timekeeping; every other time zone in the world is measured in hours off of UTC (i.e. -8, +5, etc.) It does not change with the seasons. It may or may not be the same thing as UK time, depending on the season (UTC is the same as GMT/Greenwich Mean Time, but is not the same as BST/British Summer Time). It's useful because everyone can convert to/from UTC from their location without worrying about getting it wrong by an hour (which is not good for meetings) for everyone else.

In-person meetings

All of the above applies, but you also have to worry about:

  • travel times -- how long will it take for your participants to get there?
  • travel scheduling -- if people need to fly in, they need 2 weeks+ notice. Who is coordinating the travel?
  • work schedules -- it is difficult for many volunteers to take time off in the workweek. This needs to be accounted for; how much notice do your participants need to take time off from work?
  • jet lag -- be aware of who will be jetlagged and at what times (depends on travel direction).
  • remote participation -- will there be participants who are unable to come in person who need to participate?
  • travel costs -- which participants need to have travel costs reimbursed, and the means of reimbursing them.
  • need more tips for actually RUNNING the meetings in a separate best practices!