Organising a diaspora event across several time zones

The time of day is not a logistical detail

In a local association, organising a gathering means choosing a day, a place and a duration. The time zone is never discussed, because everyone shares it and nobody thinks about it. In a diaspora, that assumption disappears. The same slot lands in the middle of a working day for some, just before the children wake up for others, in the dead of night for the rest. The chosen hour does not merely suit or inconvenience people: it designates a centre of gravity.

That centre of gravity is almost always the country where the board lives. It is logical, nobody really decides it, and that is precisely the problem. Members living outside that zone eventually understand, without ever being told, that they are invited to the margins. They do not object. They simply stop replying. Disengagement in a scattered community rarely starts with a conflict, it starts with a run of impossible slots nobody paid attention to.

This is one of the quietest traps in remote community work, and one of the most expensive to undo once it has settled in, on a par with the other mistakes that sink a diaspora platform. The good news is that it is solved with simple organisational decisions, provided they are taken on purpose rather than by default.

Three clocks not to confuse

The subject looks intractable as long as it is treated as one question. It becomes manageable as soon as it is split into three independent decisions, which are neither taken at the same moment nor on the same grounds.

• The time of the session. This is the visible decision, the one everyone debates. It determines who can attend live, and it is the only one of the three for which no setting will satisfy the whole community.
• The time the announcement and reminders go out. This is the invisible decision, and it is often the one that does the most damage. A message leaves at a precise moment and arrives at a different point in each member's day.
• What stays available after the session. This is the forgotten decision, even though it is the one that redeems the other two. Part of the community will never attend live, whatever the slot: what they find the next day decides their relationship to the event.

A board that has not separated these three questions settles all of them at once, when it fixes the date, and the last two end up decided by default. That is how a reminder scheduled one hour before the session, in the board's own time, arrives in the middle of the night for part of the membership. By morning it is buried under other notifications, and the person discovers the event once it is over. This is not a content problem or a channel problem, it is a sending-time problem, and it is fixed without changing a word of the message.

Choosing a slot is arbitration, not optimisation

It has to be said plainly: there is no hour that suits everyone once a community stretches across several continents. Hunting for the perfect slot burns weeks and always ends the same way, on the one that suits the board. The honest question is not "what is the best time", but "who are we accepting to disadvantage this time, and how do we make up for it next time".

The first step is factual: find out where members actually live. Many associations answer from memory, naming the three cities where the board happens to have contacts, and get it wrong. Even a partial census of the diaspora changes the discussion: impressions give way to a distribution. The choice of slot becomes a legible calculation, and above all one that can be explained.

The second step is to state the arbitration out loud. Announcing that the session is set on a given region because that is where most members live, and that the next one will be set differently, completely changes how the decision reads. An arbitration that is owned can be lived with. An arbitration that is merely endured gets interpreted, and it is always interpreted against the board.

The third step is rotation. Moving the slot from one edition to the next is the only mechanism that spreads the effort instead of concentrating it on the same people. That requires keeping a record, if only one line per event naming the region that was favoured, without which rotation is lost at the first handover of the board.

Single session, relayed series or asynchronous format

Three formats answer the constraint, and they carry neither the same cost nor the same effects. Confusing them is behind a good share of the disappointments.

• The single session. One moment, everyone in the same place, with the intensity that produces. It is the format that creates belonging, and it is also the one that mechanically excludes a region. It is worth it when being together matters more than being complete.
• The relayed series. Two sessions on the same agenda, at times designed for two different regions. Coverage improves, but the cost is real: the board runs the meeting twice, and the risk is manufacturing two communities that never meet. The remedy takes little, a shared write-up, the same decisions announced to both, and an opening line reminding each that the other session exists.
• The asynchronous format. A recording, a document, a discussion thread left open for several days. It is the most inclusive and the least unifying format. It suits a report perfectly, a founding moment poorly, and a decision that needs debate not at all.

The choice depends less on the board's taste than on the nature of the event. A gathering meant to introduce members to one another needs to be live. An activity update copes very well with asynchronous. A community that structures itself by territory, as it does when it decides to bring its regional chapters together online, often gains from alternating: a rare, carefully prepared shared meeting, and more frequent local ones set on each region's own hours.

When a single slot is still the right answer

It is worth resisting the reflex that treats every event as a global problem. In at least three situations, multiplying sessions serves the community less than it burdens it.

When the community sits in two neighbouring regions. If nearly all members live in countries an hour or two apart, the constraint does not really exist. Building a multi-zone setup consumes board time that will be missing elsewhere, and complicates a meeting that was working perfectly well.

When the event is statutory. A general assembly implies a single moment, with a quorum, votes and formal minutes. Splitting it in two raises governance questions that go well beyond scheduling comfort. Better to keep one slot, announced clearly and far in advance, along with a proxy arrangement for those who cannot attend and a written diaspora activity report that lets people follow without being present.

When it is the first event. A first gathering needs to succeed, not to be exhaustive. One well-prepared session with a handful of people present and pleased establishes a habit. Two split, half-empty sessions establish doubt, about the event and about the people running it.

The multi-zone setup answers a real problem. When the problem is not there, the answer is expensive and returns nothing.

Writing an announcement that assumes no time zone

Most event announcements are written from a single point on the globe, by someone who does not notice it. A few writing rules are enough to make them readable everywhere.

• Drop implicit references. "Tonight", "tomorrow morning", "late afternoon" mean nothing to a reader somewhere else. Those phrasings feel warm; mostly they exclude.
• Always write the time with its zone. A bare hour is a wrong hour for most readers. Adding at least one conversion into the second most represented region costs one line and removes half the questions.
• Attach the calendar file. This is the decisive point. An .ics file and a Google Calendar link put the event into the member's own calendar, at the time shown by their own device. The text announces, the calendar converts, and conversion stops depending on the reader's alertness.
• Beware of clock-change weeks. If summer and winter time shifts do not fall on the same dates in the countries involved, an event placed inside that window moves by an hour for part of the membership. One more reason to let the calendar do the work rather than a conversion typed by hand.

That last rule pays the most for the least effort. A perfectly worded announcement with no attached file forces every member to perform, alone and unassisted, a calculation their phone already gets right.

Target by country of residence rather than writing to everyone

A single announcement addressed to the whole community is, by construction, an announcement written for the board's time zone. It leaves at a moment that suits whoever wrote it, with wording calibrated on their own day. Everyone else receives it out of step.

Targeting announcements by country of residence changes the nature of the exercise. The same event can be relayed several times, with wording and a sending schedule specific to each region: the local time put first, the reminder scheduled to land during waking hours, and where relevant a mention of the catch-up session. It is no longer a broadcast, it is a series of invitations each speaking to the real day of its recipient.

This is also what separates a platform from a shared discussion thread. In a messaging group, one message leaves at the same instant for everyone, and the only adjustable variable is the moment you press send. It is one of the concrete differences between a WhatsApp group and a diaspora platform: not the richness of the features, but the ability to address part of the community without writing to all the rest.

Running a session where nobody shares the same day

On the day itself, a few facilitation habits stop the organisational effort from evaporating in the first twenty minutes.

• Name the time zones at the opening. Explicitly greeting those who got up early and those staying up late takes ten seconds and makes visible an effort nobody would otherwise see.
• Put the essentials first. The most time-shifted participants drop off first, for reasons that have nothing to do with their interest in the topic. What matters has to be covered while everyone is still there.
• Keep to the announced duration. Running thirty minutes over is an inconvenience for some and a shortened night for others. Ending on time is a form of respect, not rigidity.
• Keep a written channel open alongside. It lets latecomers catch up without interrupting, and lets those who will not attend ask their questions in advance.
• Commit to nothing in the closing minutes. A decision taken in the last quarter of an hour, while an entire region is asleep, will be contested, and rightly so. Binding items are handled early, or postponed.

Organising a multi-zone event in seven steps

1. Establish where members are. Start from membership data rather than the board's impressions, and look at the real distribution by country.
2. Choose the format and own it. Single session, relayed series or asynchronous: decide on the nature of the event, not on the organiser's convenience.
3. Fix the slot and say who it favours. Announce the arbitration alongside the date, and state what is planned for next time.
4. Publish the event with its calendar file. Time and zone in the text, .ics and Google Calendar on the event page, so each member sees the hour inside their own day.
5. Target the announcement and reminders by country of residence. One send per region, scheduled to land during waking hours, rather than a single broadcast.
6. Run it short, essentials first. Name the zones, keep to time, leave a written channel open.
7. Publish afterwards. Write-up, slides, a recording where relevant, and a thread left open for a few days for those who were asleep.

What the platform has to take care of

None of the above requires sophisticated tooling, but all of it becomes painful with no tooling at all. Three functions make the difference, and they are exactly the ones missing when you organise from a spreadsheet and an inbox.

The first is the event page with registrations, which gives an up-to-date list instead of a headcount reconstructed by hand. The second is calendar integration, an .ics file and Google Calendar, which settles the conversion question once and for all. The third is targeting announcements by country of residence, which lets you write to one region without writing to everybody.

At Terrilink, the events module is available from the Pro plan onwards, at 149 € per month. It is not part of the Starter plan, at 69 € per month, which stays centred on the directory, posts and messaging. That is a limit worth knowing before committing rather than at the moment of creating a first event.

In short

Method and sources. This is a method article: it describes a way of organising, drawn from observing diaspora associations, and relies on no external source. We deliberately put forward no attendance rate and no hour presented as optimal, having measured none ourselves and having no verified public study on the point. The only factual claims made concern the product: the events module, calendar integration through an .ics file and Google Calendar, targeting announcements by country of residence, and the availability of that module from the Pro plan onwards together with its absence from the Starter plan.