event-side-event-coordination

Event Side Event Coordination

You decide what happens when somebody who is not you runs an event inside your event's dates or venue orbit: whether you approve it, whether you list it, what they may call it, when it may run, and what you say you are not responsible for.

The default answer is often nothing at all. Most community events never formalise this and are right not to. Decide deliberately once, rather than at T-2 weeks when a poster carrying your logo turns up in a bar.

What you own, and what is already decided

You own the relationship with an event you do not run. Four questions, and only these four: approval, calendar, name, liability.

• The evening you run yourself is not yours. samber/dev-event-organizer-skills@event-hospitality decides whether the event has a mixer, a dinner or no organised programme, and it already deletes the do-nothing rung it calls "everyone will end up at a bar somewhere" for having nobody responsible. Your subject starts one step out: an event somebody else is responsible for. That skill's evening is what you provide; yours is what you permit.
• The policy's reach is not yours. samber/dev-event-organizer-skills@event-code-of-conduct decides whether its scope clause covers a satellite event, a jurisdiction question, and never the approval process. Its own interview asks who is bound "beyond ticket-holders", naming satellite and attendee-run fringe events among them. Hand it the confirmed list of approved satellites so its scope clause can name them; take from it the adoption requirement your criteria set enforces.
• The peer swap is not yours. samber/dev-event-organizer-skills@cross-event-promotion brokers reciprocal visibility between two independently-run events. Nobody hosts anybody and nobody approves anybody. A counterparty asking you to promote their event, rather than to run something inside your dates, belongs to that skill.
• The grid is not yours. samber/dev-event-organizer-skills@event-schedule-design owns the published session grid you deconflict against. Never move a session to make room for somebody else's party.
• The main venue is not yours. samber/dev-event-organizer-skills@event-venue-sourcing secures it. Note the name collision: that skill's "satellite sites" means extra venues for your own event, never a third party's separate one.
• Selling a side-event slot is not yours. samber/dev-event-organizer-skills@event-format-selection already lists side events among the inventory a sponsor may buy, and samber/dev-event-organizer-skills@event-sponsor-fulfillment delivers what was sold. You decide the terms a bought slot runs under, exactly as you decide them for any other satellite.

Interview

Ask one question at a time, multiple-choice where possible. Questions 5-8 exist because the menus turn on them and no other question surfaces what they carry.

1. Has anyone actually asked to run something around your event - a party, a user-group meetup, a company dinner, a workshop - or are you designing for a possibility nobody has raised yet?
2. Is any third party already using your event's name, logo, or dates in materials they have published? Answer for materials you have seen, not for what you assume.
3. Does the organizing team hold a legal entity that could be a counterparty to anything, and who actually holds the event's name and marks - the team, a parent body, or nobody in particular?
4. Whose events are these: a sponsor who bought a side-event slot, a local user group, an attendee organising a dinner, or another organizer running a full second event?
5. Which hours of your own published grid must not lose their audience - keynotes, the evening programme, an awards moment - and is that grid published yet?
6. Who on the team would actually say no to a request, and would saying no be personal for them? A volunteer team whose decider drinks with the applicant is a different machine from a staffed one.
7. What is the effort ceiling: hours before the event, whether anybody will maintain a list live through the week, and how reversible a mistake can afford to be?
8. By what date must any of this exist - an application window, a published list, a printed guide - and is this a one-off edition or a recurring event whose rules should still hold next year?
9. What already exists that the default ordering assumes away: last edition's fringe list, a sponsorship agreement that already sold a side-event slot, a code of conduct whose scope clause already names unofficial events, or a parent body that owns the marks?

Q7 and Q8 move specific rungs. Name which answer moved which rung as you re-rank.

• Nobody to maintain a list through the week deletes the two rungs on the third menu whose entire value is being current.
• A recurring mandate promotes what is written once and reused - a criteria set, a disclaimer sentence, a protected-window statement - over anything re-run live each edition.

Workflow

1. Run the interview. Q1 first: if nobody has asked and nobody is using your name, the honest recommendation is the first menu's default; say so before proposing machinery.
2. Answer the approval posture from the first menu. This decides everything after it - you cannot set naming rules for a population you have not decided to talk to.
3. If the posture is anything above doing nothing, write the criteria set before the first application arrives. Load references/application-and-criteria.md. Criteria invented after a request has landed are a judgment about that requester.
4. Set the naming rule from the second menu and write the exact sentence a satellite organizer must carry. One sentence, reusable, in the approval response.
5. Set the deconfliction depth from the third menu, against the published grid's own protected hours (Q5).
6. Write the liability position. It is not ranked, and it routes rather than resolves. Load references/naming-and-liability-wording.md.
7. Run the two cross-checks the collection already owns before approving anything: the sponsor-exclusivity check and the code-of-conduct adoption requirement, both in the criteria reference.
8. Publish the answer either way. An unpublished posture is read as permission by everyone who wanted permission.
9. After the edition, record what ran, what collided, what used your name without asking, and what you would refuse next time.

Present each decision for validation before publishing it: posture, criteria, naming rule, calendar depth, disclaimer. Publication is the point of no return, because a satellite organizer prints materials against your answer.

If your harness has persistent memory, record the posture and why, the criteria set, the naming sentence, every approval and refusal with its reason, and any unapproved use of the name you found. Next edition starts from a decided rule instead of an argument.

Approval posture

Four rungs: no posture (approve nothing, list nothing, say nothing), self-registration listing (an open form, everything submitted gets published, no gate), vetted application (published criteria, a named decider, a recorded yes or no), partnership agreement (a signed document with a named counterparty and stated terms).

Two value axes, and they genuinely disagree - which is the whole reason this menu is worth running rather than defaulting to the cheapest rung.

• value, calendar coverage - the share of satellite events you actually learn about in time to do anything: self-registration listing > vetted application > partnership agreement > no posture
• value, misattribution and liability contained - how much you can refuse, and how defensible the line between you and them is: partnership agreement > vetted application > no posture > self-registration listing
• effort (drafting, a decision round per request, chasing organizers, negotiating): partnership agreement > vetted application > self-registration listing > no posture
• compliance cost, as the review each rung triggers and the reversibility it costs: partnership agreement > vetted application > self-registration listing > no posture
• efficiency: no posture > vetted application > self-registration listing > partnership agreement

Dominance check, re-derived: 4 rungs, 6 pairs, zero strict-dominance relations. Two mechanisms block all six, and both need naming.

• Opposed value axes, four pairs: no posture against the listing, the listing against the vetted application, the listing against the agreement, and the vetted application against the agreement. In each, the rung ahead on coverage is behind on containment.
• Cost alone, two pairs: no posture against the vetted application, and no posture against the agreement. Each of those two leads on both value axes and still costs strictly more on effort and on compliance.

That accounts for every pair. The check catches no misordering, but unlike a menu whose axes are one list, the opposed-value mechanism here is a real disagreement rather than an artefact of construction.

The efficiency order is not cheapest-first, and the inversion is the point: the vetted application sits above the cheaper self-registration listing. A published list with no gate buys the worse of the two value axes, because it hands you an endorsement you never examined.

samber/dev-event-organizer-skills@event-attendee-email-sequences records the honest version of such a list, a night-by-night set of unofficial gatherings framed as "please support them" rather than as programming (devopsdays Chicago 2023 pre-event email, recorded in that skill's reference file). That framing is what keeps an unvetted list from reading as a vetted one. A list published without it is worse than no list.

• No posture - the default, and often the right final answer. Near-zero on every axis. It wins the ratio outright whenever Q1 says nobody has asked, and it is what most community events do. Publish the absence rather than leaving it silent: samber/dev-event-organizer-skills@event-hospitality makes the same argument about an unannounced evening, that silence is not neutrality but a decision to let something happen where nobody is responsible. Delete it, from this menu and from the axis lines above, when Q2 says a third party is already using your event's name in published materials. At that point doing nothing is not a posture, it is an unexamined licence.
• Vetted application - the promotion, one step up. Promotion conditions, keyed to Q2 and Q4: a third party is already using the name, or a sponsor bought a side-event slot whose terms somebody has to set. It costs a criteria set written once plus a decision round per request, and it is the only rung that buys coverage and containment together. A real version runs at conference scale: the UN Ocean Conference vets side-event proposals against how closely each relates to its own theme and gives priority to partnership submissions over single-organizer ones (full shape in references/application-and-criteria.md).
• Self-registration listing. Below the vetted rung on efficiency despite costing less, for the containment reason above. Promote it above the vetted rung when Q6 says nobody on the team can refuse a request without it being personal. An open list carrying a non-endorsement line is more honest than a gate that never says no, and it at least surfaces the calendar.
• Partnership agreement - the starved rung. Tops containment and tops both cost axes, and loses on coverage: only a committed few will sign anything, so most satellites never reach you. Efficiency never picks it. Promotion condition, keyed to Q3 and Q4: a legal entity exists on both sides and the counterparty is running a full second event whose association with yours is material to both. Delete it, from this menu and from the axis lines above, when Q3 says no entity could be a counterparty - an agreement nobody can sign is a document that reappears as scope while the vetted rung goes unbuilt.

Naming and branding rule

Four rungs: no use of the event's name (factual dates and city only), factual reference only (the name may appear in a plain factual sentence, no marks, no lockup), mandatory unofficial-disclaimer wording (the name may appear and a stated non-affiliation line must appear with it), licensed co-branding (a named, limited, purpose-bound licence to use the name and logo).

• value, attendee discoverability - a satellite event your audience can find and connect to your dates: licensed co-branding == mandatory unofficial-disclaimer wording > factual reference only > no use of the event's name
• value, misattribution avoided - a reader, a sponsor or a journalist reaches the correct conclusion about who is responsible: no use of the event's name > mandatory unofficial-disclaimer wording > licensed co-branding > factual reference only
• effort (drafting, per-request review, noticing when somebody ignores it): licensed co-branding > mandatory unofficial-disclaimer wording > factual reference only > no use of the event's name
• compliance cost, as the review each rung triggers and the reversibility it costs: licensed co-branding > mandatory unofficial-disclaimer wording > no use of the event's name == factual reference only
• efficiency: mandatory unofficial-disclaimer wording > factual reference only > no use of the event's name > licensed co-branding

The discoverability tie is argued, not a dodge: both rungs put your event's name in the satellite's own materials, which is the entire mechanism by which anyone finds it. The tie assumes a disclaimer line changes what a reader concludes about who runs the thing without changing whether they encounter it, and that assumption is weaker than it looks.

Trademark-specific disclaimer research finds disclaimers unreliable at curing the confusion they are meant to cure. A broader review of advertising disclaimers found them ineffective or actively harmful to the reader's judgment across most of the controlled studies it covers (both in references/naming-and-liability-wording.md). Treat the misattribution axis, and the one dominance relation it produces below, as resting on a contested premise rather than a settled one.

Factual-reference-only sits last on misattribution, below even co-branding, and the reason is worth stating because it is counter-intuitive. Misattribution is a reader reaching a wrong conclusion. Under a licence the reader concludes the event is connected to yours and is right. Under a bare factual reference the reader concludes the same thing and is wrong, with nothing on the page to correct them. Cheapness is what makes that rung dangerous rather than safe.

The compliance == is real: neither of the bottom two rungs grants any

...