event-date-selection

{
  "skill_name": "event-date-selection",
  "evals": [
    {
      "id": 1,
      "prompt": "I'm organizing ShipFast Conf, a two-day platform engineering conference in Rotterdam for working SREs and platform engineers, about 400 attendees, roughly a third each travelling from the Netherlands, Germany, and Poland. Second edition - last year ran in May and sold out slowly. I'm thinking we run it on a Saturday-Sunday this time so attendees don't have to take days off work, and I want to lock in the second weekend of May and get it announced on our site next week so people can book travel early. Can you sanity-check the plan and finalize the date?",
      "expected_output": "A date recommendation that moves the event to a weekday slot with the rule's source named, promotes the multi-geography calendar check for the three-country audience without inventing holiday dates, treats May as a hypothesis, produces three to five candidate windows for the venue conversation, and blocks the announcement until money handling is confirmed.",
      "files": [],
      "expectations": [
        "Recommends a weekday slot and rejects the proposed Saturday-Sunday for this working-professional audience",
        "Justifies the weekday choice by whose time attendance spends: work topics belong to work life, and a weekend slot competes with family time rather than with the office",
        "Attributes the weekday rule for professional audiences to the DevOpsDays organizing guide",
        "Does not offer a Friday-based or Friday-plus-Saturday compromise slot",
        "Promotes the multi-geography observance pass because attendees travel from three countries",
        "Does not assert any specific Dutch, German, or Polish holiday date from memory as verified; requires each country's official calendar for the specific year, or the user's own input",
        "Reports every calendar category as either checked with a source or explicitly outstanding, with none silently assumed clear",
        "Treats the May window as a hypothesis to test against the event's own prior edition, not as a seasonal fact",
        "Produces three to five candidate windows to carry into the venue conversation instead of fixing the single second-weekend-of-May date",
        "Treats date and venue as one joint decision, letting venue availability rank the surviving windows",
        "Refuses to schedule the announcement until a working way to handle money (ticketing, payment processing, or an entity that can receive it) is confirmed",
        "Extends the competing-event scan to adjacent topics and different organizers rather than only same-brand platform-engineering events",
        "Includes employer quarter-end and the school holidays of attendees' children among the professional audience's calendar checks"
      ]
    },
    {
      "id": 2,
      "prompt": "We run HackHarbour, a student hackathon at a university in Toronto, usually about 250 students. Two problems with this year's plan: the weekend we wanted in October is right after a huge developer conference downtown that half the local tech scene attends, so we figure we need to move at least a month away from it. And the backup weekend falls during the university's fall reading week, which obviously kills it since students will be gone. A third option would be running it Wednesday-Thursday so we're not fighting anyone for a weekend. Which of the three do we pick?",
      "expected_output": "A day-type verdict that keeps the hackathon on a weekend per the student-audience rule, weighs the downtown conference as a dodge-or-piggyback decision instead of fleeing it, investigates the reading week instead of auto-rejecting it, and carries multiple surviving windows with rejected ones recorded.",
      "files": [],
      "expectations": [
        "Rejects the Wednesday-Thursday option because a student audience attends on personal time and weekdays collide with class, exams, and part-time work",
        "Cites the MLH hackathon organizer guide as the source of the weekend rule for student events",
        "States the recommended weekend shape: start no earlier than Friday evening and end by Sunday",
        "Does not endorse reflexively moving a month away from the downtown conference; treats proximity to it as a two-sided decision",
        "Applies the dodge-or-piggyback criteria explicitly (who the other event draws, whether the audience travels or commutes, overlap in sponsors, speakers, or venues) and makes a per-event call",
        "Describes piggybacking - scheduling immediately before or after a nearby major event so one trip covers both - as a documented deliberate tactic, not a consolation",
        "Does not apply a blanket avoid-all-breaks rule to the fall reading week: notes a short university break can raise turnout for a single weekend event even though breaks generally reduce participation",
        "Recommends checking the specific reading week (prior editions, asking students) rather than rejecting the category outright",
        "Checks the university's own institutional calendar - exams, breaks, major campus events - as the floor of the constraint check",
        "Widens the competing-event scan beyond hackathon listings to adjacent topics, different organizers, and call-for-papers listings",
        "Includes asking two or three students what else they plan to attend that season as part of the scan",
        "Records every rejected window together with the constraint it failed",
        "Carries more than one surviving candidate window forward rather than crowning a single date immediately"
      ]
    },
    {
      "id": 3,
      "prompt": "First edition of DataForge Summit, a 300-person data-engineering conference in Austin. We've settled internally on the third week of September, and our venue said yes verbally last Friday - contract should be signed in three or four weeks. Here's the urgency: we heard a well-funded competitor is planning a data conference in Austin that same month, and we want to publish our date Monday to claim the slot before they do. We haven't picked a ticketing platform yet and our LLC paperwork is still being filed, but that's a couple of weeks out too. Draft the announcement plan - blog post Monday, socials through the week?",
      "expected_output": "A refusal to announce on Monday because the money-handling gate is unpassed, with the date held internally, the gate's clearing conditions spelled out, and the trigger choice (money-ready for the contested slot, program-teased for a first edition) deferred until the gate clears.",
      "files": [],
      "expectations": [
        "Refuses to endorse publishing the date on Monday because no working way to handle money exists yet",
        "Treats money handling as a hard prerequisite gate on announcing, not one factor to weigh against the competitor threat",
        "Cites the documented consequence of skipping the gate: teams have rescheduled or cancelled events",
        "Advises keeping the date decided internally and publishing nothing until the gate clears",
        "States that an unannounced date is still a variable while a published one is a promise",
        "Does not present the announcement-trigger options as currently selectable; brings that menu back only after money handling exists",
        "Specifies what clears the gate: a ticketing arrangement, a payment processor, or an entity able to receive money, whichever the event's model needs",
        "Requires a named person accountable for the money",
        "Distinguishes the verbal venue agreement from a signed contract, so the venue-locked trigger's precondition is not yet met",
        "Acknowledges the contested slot maps to the money-ready trigger (publishing before the venue signs) once, and only once, the money gate clears",
        "Raises the program-teased option for this first edition: waiting for an anchor speaker or an openable CFP so the announcement carries more than a bare date from an unknown event",
        "Does not invent an attendance or registration figure to justify the announcement timing"
      ]
    },
    {
      "id": 4,
      "prompt": "Our open-source project Meshwork runs its annual contributor summit alongside a large cloud-native conference - the foundation gives satellite events exactly one co-location slot, and ours is confirmed: the two days right before the main conference in Amsterdam. That can't move. My co-organizer wants us to now do the full due-diligence pass we did last year: map every holiday across our contributors' 12 countries, build a spreadsheet of every conference that quarter, and score alternative weeks. She figures three or four days of work. Before we burn the time - what date research does this situation actually need?",
      "expected_output": "A verdict that the externally forced window deletes the competing-event scan and multi-geography pass as decision inputs, keeps the audience-calendar floor, redirects the hours into mitigation, routes known conflicts to risk planning, and replaces the candidate-window gate with a written record of the constraint.",
      "files": [],
      "expectations": [
        "Identifies the window as externally forced and states that no scan result could change the date",
        "Advises deleting, not merely deprioritizing, the competing-event scan and the multi-geography observance pass as date-selection inputs",
        "Gives the rationale: a check whose result cannot change the decision has no decision attached",
        "Rejects the three-to-four-day research plan, including scoring alternative weeks, rather than trimming it",
        "Redirects the available hours toward mitigating the conflicts the forced window already carries",
        "Routes known conflicts and observance collisions into risk planning as hazards, not back into the date decision",
        "Does not require generating three candidate windows; the gate becomes writing down the constraint, what fixes it, and who could move it",
        "Retains the audience-calendar floor - knowing which contributor calendars the fixed window collides with - for mitigation purposes",
        "Confirms the announcement remains gated on money handling regardless of the forced window",
        "Asks or confirms who could actually move the constraint before accepting it as immovable"
      ]
    },
    {
      "id": 5,
      "prompt": "We're planning CompilerCamp, a two-day systems programming conference in Manchester. We deliberately want both audiences: professional compiler engineers from the big employers in town, and CS students from the two universities. Our committee landed on Friday plus Saturday as the obvious compromise - Friday is a workday so the professionals can come on company time, Saturday works for the students. One committee member wants data: roughly what percentage of attendance do we lose if we get the day choice wrong? Help us settle both the dates and that estimate.",
      "expected_output": "A rejection of the Friday-plus-Saturday compromise with the worst-half-of-each-rule reasoning, the pick-a-pole and programme-split routes laid out with boundary days marked weakest, the pole named in the deliverable, and a refusal to attach a percentage to the day-type mistake.",
      "files": [],
      "expectations": [
        "Rejects the Friday-plus-Saturday compromise rather than endorsing it",
        "Explains the specific failure: the compromise takes the worst half of each rule - an employer day students cannot take off and a personal day professionals will not give",
        "Presents picking one audience pole and accepting lower attendance from the other as the primary route",
        "Presents the programme-split alternative - a weekday main programme plus a weekend-adjacent satellite day - with its stated cost of a second day of logistics and a second volunteer roster",
        "Labels boundary days (Friday and Monday) the weakest option: the day both audiences are most easily pulled away from, endorsed by neither guide",
        "Requires the deliverable to name which pole was picked and why",
        "Frames the pole choice as a positioning decision to make explicitly, not a scheduling detail",
        "Grounds the two opposing day-type defaults in their sources: the DevOpsDays guide for the weekday rule and the MLH guide for the weekend rule",
        "Declines to give a percentage attendance penalty for a wrong day type, stating the guides say which day but not how much a mistake costs",
        "Does not fabricate any substitute attendance statistic for the committee member",
        "Establishes whose time the attendee spends as the first and deciding question before any other constraint"
      ]
    },
    {
      "id": 6,
      "prompt": "Fourth edition of RustAtlantic, our annual Rust conference in Halifax - the date has been public for two months, about 900 tickets usually, maybe 180 sold so far. We're behind: our keynote speaker pulled out last week, the CFP opened three weeks late, and the workshop track has no leads yet. The team wants to push the whole event back six weeks to buy breathing room - we'd email ticket holders, and most would probably be fine with it. Good idea, or how would you play it?",
      "expected_output": "A recommendation to hold the announced date and cut scope instead, with the promise framing, the extra retraction cost a recurring event pays, and the work-back schedule identified as the variable that moves.",
      "files": [],
      "expectations": [
        "Advises against moving the announced date",
        "States the published date is a promise, and moving it burns speaker, sponsor, and attendee trust",
        "Notes the retraction cost is higher for a recurring annual event than for a one-off",
        "Recommends cutting scope instead - shrinking or dropping the unready parts such as the workshop track - to rescue the plan",
        "Does not accept the keynote loss or late CFP as sufficient grounds to reschedule",
        "Treats the internal work-back schedule as what adjusts, not the public date",
        "Does not propose a retract-and-reannounce or tentative-new-date maneuver",
        "Does not treat the low ticket count or expected ticket-holder tolerance as making the move cheap"
      ]
    },
    {
      "id": 7,
      "prompt": "We've done our homework for GreenStack Days, a sustainability-in-tech conference in Copenhagen: three date windows in March-April all cleared our conflict checks, and we ranked them - window A is clearly best for us, and C is honestly a stretch we'd rather not use. Tomorrow I meet our top venue choice. My plan: present the ranked list, push hard for window A, and keep C as a bargaining chip. Also, heads up - the venue emailed that they might counter with a week in late February they're trying to fill. How do I run this negotiation?",
      "expected_output": "Negotiation guidance that presents the windows as equivalents rather than a ranked list, removes or genuinely accepts the bluff window, asks after the venue's quiet periods, and routes the February counter-offer back through the constraint checks before acceptance.",
      "files": [],
      "expectations": [
        "Advises presenting the windows as equivalent options rather than a ranked list",
        "Gives the reason: a ranked list invites the venue to offer only the top window and decline the rest",
        "Flags window C: a window the team would refuse is not an option but a bluff that collapses if the venue picks it - drop it or genuinely accept it",
        "Recommends asking the venue about its own quiet periods, where rate flexibility lives",
        "Treats the late-February counter-offer as a new candidate window rather than accepting or rejecting it on availability alone",
        "Requires the counter-offer to go back through the constraint checks (calendars, competing events) before acceptance",
        "States that an availability or rate win landing on an unchecked observance is not a win",
        "Names the several-windows-into-the-venue-conversation practice as \"Get Options\" or attributes it to the DevOpsDays guide",
        "Suggests restoring the option count so three to five genuinely acceptable windows enter the conversation"
      ]
    }
  ],
  "trigger_queries": [
    { "query": "Help me pick a date for our Kubernetes conference next year.", "should_trigger": true },
    { "query": "Should our developer conference run on a weekday or a weekend?", "should_trigger": true },
    { "query": "Our student hackathon clashes with another one in the same city - move it or keep the date?", "should_trigger": true },
    { "query": "When should we announce the date for our tech conference?", "should_trigger": true },
    { "query": "Is scheduling our conference the same week as a giant industry conference suicide, or can we use it?", "should_trigger": true },
    { "query": "What's the best month to run a developer conference in northern Europe?", "should_trigger": true },
    { "query": "We can't decide between two weekends in June for the hackathon - how do we choose?", "should_trigger": true },
    { "query": "The venue gave us three possible weeks - which one do we take and when do we go public?", "should_trigger": true },
    { "query": "How far in advance should a conference date be announced?", "should_trigger": true },
    { "query": "Check whether mid-October works for our security summit or if something big collides with it.", "should_trigger": true },
    { "query": "Our conference date keeps landing on school holidays somewhere - how do I pick a week that works across Europe?", "should_trigger": true },
    { "query": "Pick a weekend for a 48-hour student hackathon in the fall semester.", "should_trigger": true },
    { "query": "There's a huge gaming expo in our city the week we wanted - should we move our indie dev conference?", "should_trigger": true },
    { "query": "Everything else about the event is planned, we just don't have a date yet. Where do we start?", "should_trigger": true },
    { "query": "Would running our event right after a major conference in the same city help or hurt attendance?", "should_trigger": true },
    { "query": "We want to announce our conference date but ticketing isn't set up yet - go anyway?", "should_trigger": true },
    { "query": "How do I check if another tech event conflicts with the week we picked?", "should_trigger": true },
    { "query": "Weekday vs Saturday for a 200-person API meetup for professionals - settle this argument.", "should_trigger": true },
    { "query": "What do organizers usually check before locking a conference date?", "should_trigger": true },
    { "query": "Ramadan might overlap the window we like for our Berlin developer festival - how should we handle it?", "should_trigger": true },
    { "query": "Our CFO says don't announce until the venue contract is signed, marketing wants to announce now - who's right?", "should_trigger": true },
    { "query": "Find us a date for the third edition of our data engineering summit.", "should_trigger": true },
    { "query": "Two conferences in our niche already picked June - where does that leave us?", "should_trigger": true },
    { "query": "Does it matter which day of the week a community tech event lands on?", "should_trigger": true },
    { "query": "We're thinking last weekend of September for the hackathon - poke holes in that.", "should_trigger": true },
    { "query": "How do conference organizers avoid double-booking against other events?", "should_trigger": true },
    { "query": "The university's exam period moved and now our event date looks risky - rethink it with me.", "should_trigger": true },
    { "query": "When do we tell the public the date - after the venue signs, or sooner to beat a competitor?", "should_trigger": true },
    { "query": "Sanity-check March 12-13 for our platform engineering conference.", "should_trigger": true },
    { "query": "Our audience is half students, half professionals - what day do we run the conference?", "should_trigger": true },
    { "query": "Is August really a dead month for tech events or is that a myth we should test?", "should_trigger": true },
    { "query": "A rival meetup group announced an event two days before ours - what now?", "should_trigger": true },
    { "query": "Help me shortlist candidate weeks for a two-day fintech developer conference.", "should_trigger": true },
    { "query": "What holidays should I check before fixing the date of an international conference?", "should_trigger": true },
    { "query": "Our sponsor wants the event inside their fiscal Q2 - how does that constrain the date?", "should_trigger": true },
    { "query": "Should we anchor our community day to the big annual conference or keep our distance?", "should_trigger": true },
    { "query": "We've outgrown our usual slot - walk me through re-picking the annual conference date.", "should_trigger": true },
    { "query": "Our conference date is locked for June 10 - build the work-back plan of everything due before it.", "should_trigger": false },
    { "query": "The date's set; what should the 12-week countdown of milestones look like?", "should_trigger": false },
    { "query": "Help me find and shortlist venues for a 500-person developer conference.", "should_trigger": false },
    { "query": "Is there even room for another DevOps conference in our region, or is the market saturated?", "should_trigger": false },
    { "query": "There are already four AI meetups in town - does a fifth have an audience?", "should_trigger": false },
    { "query": "When should our CFP open and close, and how long should the review window be?", "should_trigger": false },
    { "query": "Design the CFP form and review process for our conference.", "should_trigger": false },
    { "query": "Build the two-day session schedule - how many tracks and how long should talks be?", "should_trigger": false },
    { "query": "Draft the minute-by-minute run of show for the keynote morning.", "should_trigger": false },
    { "query": "Should our company run a roadshow or a single user conference this year?", "should_trigger": false },
    { "query": "What should we charge for tickets to our two-day conference?", "should_trigger": false },
    { "query": "Put together the budget for a 300-person conference.", "should_trigger": false },
    { "query": "Which audience should our conference be built for - students or senior engineers?", "should_trigger": false },
    { "query": "What launch gates should a first-edition conference clear before we commit to running it?", "should_trigger": false },
    { "query": "How do we promote our conference and when should the marketing pushes go out?", "should_trigger": false },
    { "query": "Write the announcement blog post for our conference.", "should_trigger": false },
    { "query": "How do we cut our hackathon's no-show rate?", "should_trigger": false },
    { "query": "Plan the after-party and evening social program for our summit.", "should_trigger": false },
    { "query": "Coordinate the community-run side events happening around our conference week.", "should_trigger": false },
    { "query": "What risks should be on the risk register for our outdoor tech festival?", "should_trigger": false },
    { "query": "Help me pick which talks to accept from 200 CFP submissions.", "should_trigger": false },
    { "query": "How should we structure sponsorship tiers and pricing?", "should_trigger": false },
    { "query": "Our two annual events cannibalize each other's audience - how should we promote them together?", "should_trigger": false },
    { "query": "Set up a recurring calendar event for our weekly team standup.", "should_trigger": false },
    { "query": "Find a meeting slot next week that works for eight people across three time zones.", "should_trigger": false },
    { "query": "Reschedule my Thursday meetings and update the invites.", "should_trigger": false },
    { "query": "Sync our conference schedule into attendees' Google Calendars.", "should_trigger": false },
    { "query": "What's the best day of the week to send our product newsletter?", "should_trigger": false },
    { "query": "Pick a launch date for our SaaS product's v2 release.", "should_trigger": false },
    { "query": "When should we schedule the maintenance window for the database migration?", "should_trigger": false },
    { "query": "Design the event store and event sourcing schema for our order service.", "should_trigger": false },
    { "query": "Subscribe our webhook to calendar change events in the workspace API.", "should_trigger": false },
    { "query": "Plan my week - block time for deep work around my existing meetings.", "should_trigger": false },
    { "query": "How far in advance should wedding invitations go out?", "should_trigger": false },
    { "query": "Build the production schedule for our factory's Q3 output.", "should_trigger": false },
    { "query": "Which conference should our team attend this year given our travel budget?", "should_trigger": false },
    { "query": "How do I add speaker session times to the event mobile app agenda?", "should_trigger": false }
  ]
}

# Audience calendars

Contents:

1. The two audience rules, and what each one actually claims
2. Calendar categories to check
3. How to verify a category without inventing dates
4. Reading a mixed audience

## 1. The two audience rules, and what each one actually claims

Each rule below comes from exactly one organizer guide. Neither guide claims to generalize beyond its own audience, and the pair only becomes a rule because they disagree for a reason.

| Audience                                             | Day type                          | Source                        | The reason given                                                                                             |
| ---------------------------------------------------- | --------------------------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------ |
| Working professionals attending as part of their job | Weekday                           | DevOpsDays organizing guide   | Work topics belong to work life; weekends are "used for refreshing energy with family"                       |
| Students, hobbyists, personal-project builders       | Weekend, Friday evening to Sunday | MLH hackathon organizer guide | Weekdays collide with class, exams, and part-time work; a Sunday-afternoon finish gives "a sense of closure" |

Two limits worth stating to the user:

- The MLH rule is a _membership requirement_ for its member events, not merely a recommendation - strong evidence of what the audience needs, though part of its force is organizational rather than behavioural.
- Both guides are community-run; neither speaks for company-run or vendor-run events, whose attendees may be sent on employer time regardless of the day.

What neither guide gives: the size of the penalty for getting the day type wrong. They say which day, not how much a mistake costs. Do not attach a percentage to it.

## 2. Calendar categories to check

This is the method that replaces the date list this skill refuses to invent. Work outward: the categories at the top constrain nearly every event, the ones at the bottom only matter for audiences that actually reach that far.

1. **The audience's own institutional calendar.** For students, the MLH guide names exams, university and school breaks, and major events at the university or organizing body. For working professionals, the equivalents are employer quarter-end and fiscal-year-end freezes, and - because they are the family time the DevOpsDays rule protects - the school holidays of the region their children attend school in.
2. **National public holidays**, in every country a meaningful share of attendees travels from, plus the host country. Bridge days and regionally variable holidays matter as much as the fixed ones; several countries observe holidays that apply in some regions only.
3. **Religious and cultural observance calendars** for the communities present in the audience. Many are lunar or lunisolar and fall on different Gregorian dates every year, so a date that was clear last year says nothing about this year. Observance also varies within a community - some periods restrict travel or eating rather than work.
4. **Ecosystem anchor dates**: the flagship event, organizer conference, or release cycle the rest of your sub-field already schedules around. The MLH guide treats its own organizer conference this way, and it works as a template for finding the equivalent in any ecosystem.
5. **Local civic and cultural events** in the host city - marathons, festivals, trade fairs, elections. They compete for venues, hotel inventory, transit capacity, and local press regardless of topic.
6. **Employer budget and travel-approval cycles**, for events where attendance is expensed. This category is a judgment call rather than a documented rule; treat it as a hypothesis to test with two or three prospective attendees rather than a constraint to assume.

What the guides actually say about holidays is a warning against the obvious heuristic, not a heuristic of its own: the MLH guide records that holidays are "a great way to attract more crowd" in some cultural contexts, and that a short university break can _raise_ turnout for a single weekend event even though breaks generally reduce participation. So a holiday hit is a flag to investigate, never an automatic rejection.

## 3. How to verify a category without inventing dates

The failure this section exists to prevent is a confident wrong list. A reader who is told the dates are clear stops looking; a reader who is told a category is outstanding goes and checks.

- Name the specific year and the specific country or institution before looking anything up. "European holidays" is not a checkable object.
- Prefer the authority that publishes the calendar: a government's official public-holiday page, a university's published academic calendar, a religious community's own published observance dates for that year.
- If you can browse the web, verify each category against such a source and cite where each date came from. If you cannot, ask the user for the calendars that apply to their audience - they usually know their own community's better than any general source.
- Record the result per category as **checked** (with the source) or **outstanding**. There is no third state; "probably fine" is outstanding.
- Never carry a date forward from a previous year for any lunar or lunisolar observance, and never infer one country's holidays from a neighbour's.
- Report outstanding categories to the user alongside the candidate windows, so the date is chosen with the gap visible rather than after it has been papered over.

## 4. Reading a mixed audience

A genuine mix - say, a conference that wants both employed engineers and students - has no day type that satisfies both rules, and the compromise slot takes the worst half of each. Three honest ways out, in the order they are usually worth trying:

- **Pick the pole the event is actually built for** and accept lower attendance from the other. Cheapest, and it keeps the event legible to the audience it is positioned for.
- **Split the day types across the programme**: the main weekday programme for the employer-time audience, with a weekend-adjacent satellite (workshop day, hack day, community day) for the personal-time one. Costs a second day of logistics and a second volunteer roster.
- **Use the boundary days.** Friday and Monday sit on the seam between employer and personal time, which is why they attract compromise proposals. Treat this as the weakest option, not the obvious one: a boundary day is the day _both_ audiences can most easily be pulled away from, and neither guide endorses it.

Whichever route is chosen, say which pole was picked and why in the deliverable - a mixed-audience date that does not name its pole reads as an oversight to everyone it disappoints.

# Competing events, venue windows, and announcement

Contents:

1. The competing-event scan, step by step
2. Dodge or piggyback: deciding per event
3. "Get Options": carrying windows into the venue conversation
4. The announcement gate checklist
5. Worked example (illustrative) and its negative counterpart

## 1. The competing-event scan, step by step

The DevOpsDays organizing guide frames this check as **"load balancing"** across the field, not turf protection: the field is better off when its events are spread out. An organizer who only asks "does this hurt me" misses the events that hurt the audience by stacking.

1. **List your own event family first.** Any event network with a shared homepage lists its scheduled editions; this is the cheapest hit and the one the DevOpsDays guide names directly. It is also the narrowest - it surfaces only events branded like yours.
2. **Widen to adjacent topics and different organizers.** This is the gap step 1 cannot close, and where most real conflicts live: your attendees choose between your event and _any_ event they would spend the same travel budget on, not only ones in your category.
3. **Consult a cross-topic public conference calendar.** A crowdsourced dataset such as confs.tech is one example of the kind of tool that does this - named as an example of the category, not as a dependency. Its coverage is contributed by organizers who already know about it, so absence from it proves nothing.
4. **Add a call-for-papers listing scan.** CFP aggregators surface events that have not yet announced dates publicly but have already claimed a window, which a calendar of confirmed events misses.
5. **Check local, non-topical events** in the host city across each candidate window: marathons, festivals, trade fairs, major sporting fixtures. They take venues, hotel inventory, transit, and local attention regardless of subject.
6. **Ask two or three people in the audience** what else they are planning to attend that season. This catches the events no aggregator lists - regional meetup series, company user conferences, internal engineering weeks - and it is usually the highest-yield ten minutes in the whole scan.
7. **Record every hit with the decision made on it**, not just the hits you avoided. The rejected-window reasoning is the part that cannot be reconstructed next year.

## 2. Dodge or piggyback: deciding per event

The DevOpsDays guide names **piggybacking** as a deliberate tactic, not a consolation: scheduling immediately before or after another major event in the same city so travelling attendees justify one trip for both. That makes proximity a two-sided variable, and the decision has to be made per event rather than by reflex.

Lean toward **piggybacking** when:

- The other event draws the same people to the same city.
- A meaningful share of your audience travels rather than commutes.
- Your event is small enough that being the second stop is an advantage rather than a comparison.

Lean toward **dodging** when:

- The two events compete for the same finite resource: the same sponsors' budgets in the same quarter, the same speakers, the same venue.
- The other event is close enough in subject that attending both feels redundant rather than complementary.

Two adjacency risks the tactic carries, both judgment calls rather than documented rules:

- Attendee fatigue after a large multi-day event.
- Sponsor budget already spent at the bigger show.

Ask a sponsor directly rather than assuming either way.

## 3. "Get Options": carrying windows into the venue conversation

The DevOpsDays guide advises lining up several candidate windows rather than fixing one date before approaching venues, because availability is uneven across a week and a month - "you might find that they can accommodate you better during some parts of the week than others."

Practical shape:

- Carry three to five surviving windows, each already cleared by the constraint checks, so any of them is genuinely acceptable. A window you would refuse is not an option; it is a bluff that collapses when the venue picks it.
- Present them as equivalent rather than ranked. A ranked list invites the venue to offer only the top one and decline.
- Ask what the venue's own quiet periods are. Off-peak windows are where rate flexibility lives, and the venue knows them better than any guess from outside.
- Treat a venue's counter-offer as a new candidate window and put it back through the constraint checks before accepting - an availability win that lands on an unchecked observance is not a win.

## 4. The announcement gate checklist

The hard prerequisite, from the DevOpsDays guide: **a date cannot be announced until there is a known way to handle money.** Discovering the gap late has caused rescheduled and cancelled events. Check all of these before publishing:

- A way to receive money exists: a ticketing arrangement, a payment processor, or an entity that can invoice sponsors - whichever the event's model actually needs.
- Someone is accountable for the money, by name.
- The date itself is decided internally and no longer under discussion.
- Every calendar category is checked or explicitly recorded as outstanding, and the user has seen the outstanding list.
- The dodge-or-piggyback call has been made on every competing event found.
- The trigger chosen from the announcement menu has its own precondition met - a signed venue contract for the venue-locked trigger, a confirmed anchor speaker or an openable CFP for the program-teased one.

Below any of these, the date can be decided but not published. An internal date is still a variable; a published one is a promise, and retracting it costs a recurring event far more than the wait would have.

## 5. Worked example (illustrative) and its negative counterpart

Both examples below use invented events and invented dates. They illustrate the shape of the reasoning only - every date, attendance figure and outcome in them is illustrative, and none should be reused as evidence.

### Positive: a professional-audience conference

A two-day platform-engineering conference for working engineers, audience mostly from three neighbouring countries, second edition.

- **Day type:** weekday, from the employer-time rule (DevOpsDays guide). Tuesday-Wednesday chosen over Thursday-Friday so that neither day is a boundary day.
- **Season:** last edition ran in late spring and sold out slowly; the team proposes the same season as a hypothesis, explicitly labelled as such rather than as a seasonal fact.
- **Constraint depth:** the multi-geography observance rung, promoted because the audience spans three countries. Public holidays verified from each country's official calendar for the specific year; one candidate window dropped because it straddled a public holiday in the country supplying the largest share of attendees.
- **Competing-event scan:** two adjacent-topic conferences found in the same season. One is in the same city two days earlier - the team schedules to abut it deliberately, so travelling attendees make one trip. The other is dodged: same sponsor pool, same quarter.
- **Windows carried to venues:** four, presented as equivalent. The venue offers a fifth in an off-peak week; it goes back through the constraint checks, clears, and is accepted.
- **Announcement:** venue-locked trigger. Money handling confirmed, contract signed, date published.

The deliverable records every rejected window with the constraint it failed - which is what makes next year's selection start ahead rather than from scratch.

### Negative: the same event, done by reflex

- **Day type:** Friday chosen "so people can travel home" - a boundary day serving neither pole, and endorsed by neither guide.
- **Season:** "August is dead, everyone's on holiday" asserted as fact, never tested against the event's own prior editions.
- **Holidays:** last year's observance dates reused. They were lunar and moved; the event lands mid-observance for a substantial part of the audience.
- **Competing-event scan:** only the event family's own homepage checked. The conflict that actually costs attendance comes from an adjacent-topic conference nobody looked for.
- **Piggybacking:** a large event in the same city the week before is treated as a threat and fled, discarding a documented tactic without considering it.
- **Venue:** one date fixed first, then venues called. Every venue is booked; the search stalls with no fallback.
- **Announcement:** date published to claim the slot before ticketing exists. Payment setup takes longer than expected, the on-sale slips twice, and the published date becomes a promise the team cannot yet keep.

Each line in the negative example maps to one failure mode in the skill body; read together they are the same event losing its audience one unchecked assumption at a time.

---
name: event-date-selection
description: Pick the date a technical event runs on - the decision every other plan hangs off. Covers weekday versus weekend from whose calendar the audience lives on (working professionals versus students), seasonality and the calendars constraining the real audience, competing and anchor events scanned for both conflict and deliberate piggybacking, candidate windows negotiated against venue availability instead of one date fixed first, and the announcement gate on payment handling existing. Use whenever asked to choose an event date, pick a conference weekend, check date conflicts with other events, decide how far ahead to announce, or resolve a clash with a competing event. Do NOT use for the work-back schedule from that date - use samber/dev-event-organizer-skills@event-planning-timeline.
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.1.0"
---

# Event Date Selection

You are a scheduling advisor for technical events. Pick the date: the day type the audience can actually attend, the window the season and the calendars leave open, the competing events to dodge or deliberately attach to, the candidate windows the venue can serve, and the moment the date becomes public.

This skill ends the moment the date is announced. Three sibling skills border it:

- `samber/dev-event-organizer-skills@event-planning-timeline` owns the work-back schedule that starts from the date this skill produces.
- `samber/dev-event-organizer-skills@event-market-fit` reads competing events as a _demand_ signal, whether the event should exist at all; here the same calendar is a _scheduling constraint_.
- `samber/dev-event-organizer-skills@event-venue-sourcing` owns venue selection; this skill only borrows the availability negotiation that makes date and venue one joint decision.

## Holiday and seasonality guidance

Never invent a holiday calendar from memory or generic rules. The MLH and DevOpsDays guides show that holidays affect different audiences differently: MLH records that short university breaks can _raise_ turnout for a single weekend event even though breaks generally reduce participation, and that holidays are "a great way to attract more crowd" in some cultural contexts. Treat seasonality as a hypothesis to test against the user's own prior editions, never as a fact.

See [references/audience-calendars.md](references/audience-calendars.md) for the calendar-category checklist and how to verify each category for a specific year without inventing dates. If you cannot browse or the user cannot supply the calendars, say the check is outstanding rather than declaring the date clear.

## Whose calendar the attendee lives on

The split that decides this skill's first and largest question is **who owns the hours the attendee would spend at your event**:

- **Employer-time audiences** (working professionals attending as part of their job) - the DevOpsDays organizing guide recommends weekdays explicitly: "DevOps is part of people's work life, and the weekends are typically used for refreshing energy with family." A weekend slot asks this audience to spend personal time on work, and competes with family rather than with the office.
- **Personal-time audiences** (students, hobbyists, side-project builders) - the MLH hackathon organizer guide _requires_ a weekend for member events: earliest start Friday evening, latest end Sunday, with the recommended shape ending Sunday afternoon so winners are announced with "a sense of closure." Weekdays here collide with class, exams, and part-time work.

Same decision, opposite defaults, because the constraint is opposite. Never average the two: a Friday-plus-Saturday compromise built for a mixed audience takes the worst half of each rule - an employer day the students cannot take off, and a personal day the professionals will not give. When the audience genuinely splits, pick the pole you are actually building for and say so; `samber/dev-event-organizer-skills@event-positioning` owns that call.

## Time of day: who an evening slot excludes

Day type is not the whole slot. A weekday evening looks free for an employer-time audience, and it is where caregivers drop out.

- Organizers report that evening events lose women mostly through childcare, and that experienced practitioners skip evenings for family reasons too.
- The same reports describe women's share rising when the slot moved to daytime or lunch, and when the topic broadened (a product-themed conference, a workshop co-run with an HR meetup).
- Treat both as reports, not measured effects. Check them against your own registration data where you collect gender or caregiver status with consent.

Record which slot the event runs in (morning, lunch, afternoon, evening) beside the day type, and name who it excludes. Route the provisions that soften an unavoidable evening slot (childcare, caregiver tickets) to `samber/dev-event-organizer-skills@event-accessibility-inclusion`.

## Recurring series: rotate the slot, not only the date

A one-off picks one slot. A monthly or quarterly series picks a _pattern_, and a fixed pattern excludes the same people every time.

- A fixed Tuesday evening permanently excludes anyone with a standing Tuesday conflict: a sports club, a custody arrangement, a weekly class. No single edition looks short; the loss is invisible because those people never appear in any edition's data.
- One monthly series never reused the same weekday and hour twice in a row, and rotated formats too (dinner, lunch, after-work, talk, open session). It reported stable attendance over several years.
- Rotation trades away habit: a regular who learned "first Tuesday" now has to read each announcement. Pay for that in the announcement, not by freezing the slot.

Rotation pattern options, this skill's own construction rather than a ranked menu:

- **Fixed slot** - one weekday and hour. Easiest habit, permanent exclusion of that slot's conflicts. Defensible when a venue offers only one slot.
- **Rotating weekday, fixed hour** - spreads weekday conflicts, keeps the evening or lunch exclusion.
- **Rotating weekday and hour** - spreads both. Pairs naturally with rotating format; settle formats with `samber/dev-event-organizer-skills@event-format-selection`.

## Interview

Ask one question at a time, multiple-choice where possible. Question 1 comes first because it decides the day-type before any other constraint is worth checking. Questions 4-6 exist because the menus below diverge sharply on time-to-effect, durability, and effort; their default rankings cannot be picked for the user.

1. Who is the audience, in terms of whose time they spend attending - working professionals on employer time, students and hobbyists on personal time, or a genuine mix? (Decides weekday vs. weekend before anything else.)
2. Where do they travel from - one city, one country, or several countries and cultures? (Sets how far the calendar check has to reach, and whether the starved rung of the depth menu is promoted.)
3. What is already fixed and cannot move - a co-located anchor event, a venue with one open window, a sponsor fiscal year, an academic term? (A fixed constraint deletes candidate windows before you generate any.)
4. Is there a date the event must land by, or before? (A hard deadline promotes the fast-acting rungs and can force the earliest announcement trigger.)
5. Is this a one-off, or one edition of a compounding annual asset? (A recurring event pays more for a slot the field learns to expect, and pays far more for retracting a published date.)
6. What is the effort ceiling for the date work itself - hours available, and how many people can be consulted before deciding?
7. Is there a working way to handle money - ticketing, payment processing, an entity that can receive it? (This is a gate on announcing, not a preference; see below.)
8. What assets should re-rank the menus - prior editions' dates and attendance, a standing venue relationship, an ecosystem anchor date already routed around, a community whose calendars the team already knows?
9. Is the window you want contested - is another event or booking likely to claim it first?
10. Is this one edition of a recurring series (monthly, quarterly), and does it hold a fixed weekday and hour today? (Decides whether § Recurring series applies.)
11. What time of day is planned - morning, lunch, afternoon, evening - and who among the intended audience has caregiving duties at that hour? (See § Time of day.)

## Date-constraint checking depth

Cumulative rungs: each includes the ones below it. Ranking (a default, not a law - re-rank against Q2 above all, and against Q6 and Q8).

- effort (hours before a date can be picked, plus how many people must be consulted): `multi-geography observance pass > competing-event scan > audience-calendar pass`
- value (attendance protected, weighted by how irreversible the error is after announcement): `audience-calendar pass > competing-event scan > multi-geography observance pass`
- efficiency: `audience-calendar pass > competing-event scan > multi-geography observance pass`

- **Audience-calendar pass** - the floor: day type from the section above, plus the calendars of the audience's own institutions. Highest value per hour on the table, because the day-type error is the largest single attendance mistake available and costs nothing to avoid.
  - Student audience: the MLH guide names exams, university breaks, and major institutional events.
  - Professional audience: the equivalents are employer quarter-end and the school holidays of the attendees' children.
- **Competing-event scan** - the recommended default, despite the audience-calendar pass ranking higher on efficiency alone. The pass is blind by construction to the one failure that originates outside your audience: another event holding your people on your date. The scan costs an afternoon, is the only rung that can see that failure, and stays skippable only when Q3 has already externally forced the date and no scan result could change it.
- **Multi-geography observance pass** - the starved option: national, religious, and school calendars for every geography a meaningful share of attendees travels from, verified for the specific year. It loses every efficiency round because the value line above quietly assumes a single-geography audience, an assumption this rung exists to test; promote it the moment Q2 says otherwise, or whenever the audience spans communities observing different calendars in the same city. The category checklist is in [references/audience-calendars.md](references/audience-calendars.md); the dates themselves are not in this skill.

**Delete, do not demote: every rung above the audience-calendar pass, when Q3 says a single window is externally forced and nothing within your control could move it - delete them from this menu and from the axis lines above.** A scan whose result cannot change the decision is not a cheaper check - it is a check with no decision attached, and left on the menu it consumes the hours the forced window most needs spent on mitigation. Carry the conflicts you already know into `samber/dev-event-organizer-skills@event-risk-management` as a hazard, not back into this menu as a rung.

## Competing events: a constraint and an opportunity

A competing event is not automatically fatal, and treating it that way throws away the field's most useful scheduling move.

- **Conflict avoidance** - the DevOpsDays organizing guide frames checking the field's own calendar as "load balancing" across the field, not merely protecting one organizer's turnout. Extend the check to large local events unrelated to your topic: they take venues, hotel rooms, transit, and local attention regardless of subject.
- **Piggybacking** - the same guide names it as a deliberate positive tactic: schedule immediately before or after another major event in the same city so travelling attendees justify one trip for both. This inverts the default; a nearby big event can be a reason to move _toward_ a window, not away from it.
- **Ecosystem anchor dates** - the MLH guide treats its own organizer conference as a fixed date the whole sub-field routes around. Find the equivalent anchor in your ecosystem and decide deliberately whether to dodge it or attach to it.

Cross-topic, cross-organizer coverage is the gap a single event family's own homepage cannot fill. A crowdsourced public conference calendar such as confs.tech is one example of the kind of tool that closes it - an example, not a dependency, and its coverage skews to organizers who already use it. The scan procedure and its fallbacks are in [references/competing-events-and-announcement.md](references/competing-events-and-announcement.md).

## Candidate windows, not one date

Do not fix a single date and then ask the venue. The DevOpsDays guide names the practice **"Get Options"**: carry several candidate windows into the venue conversation, because availability is uneven across a week and a month - "you might find that they can accommodate you better during some parts of the week than others."

Date and venue are one joint decision, and arriving with three viable windows converts a refusal into a negotiation. Carry three to five surviving windows out of the constraint checks; hand them to `samber/dev-event-organizer-skills@event-venue-sourcing` and let availability rank them.

## Announcement trigger

The hard gate under every rung, from the DevOpsDays guide: **you cannot announce a date until you know you have a way to handle money.** Teams that discovered late that payment handling was not in place have rescheduled or cancelled. This is a prerequisite, not a preference; an unannounced date is still a variable, and an announced one is a promise.

Ranking (a default, not a law - re-rank against Q4, Q5, and the standing venue relationship in Q8):

- effort (what must be finished before you can publish, plus the lead time forfeited waiting): `program-teased > venue-locked > money-ready`
- value (lead time secured that you never have to retract): `venue-locked > money-ready > program-teased`
- efficiency: `venue-locked > money-ready > program-teased`

- **Venue-locked announcement** - the default: publish once the venue contract is signed and the money gate has cleared. Buys nearly all the available lead time while making retraction close to impossible, which is what puts it top on both value and efficiency.
- **Money-ready announcement** - publish the moment the money gate clears, before the venue is signed. Maximum lead time and minimum waiting, at the cost of a real retraction risk. Choose it when a slot is contested and claiming it early is worth that risk (Q9), or when a standing venue relationship (Q8) makes the eventual signature near-certain.
- **Program-teased announcement** - the starved option: wait until an anchor speaker is confirmed or the CFP can open, so the announcement carries a reason beyond a bare date - highest effort, most lead time forfeited, so it loses every efficiency round. Promote it for a first edition with no track record, where a bare date from an unknown event persuades nobody; this promotion is a judgment call rather than a documented rule. `samber/dev-event-organizer-skills@event-first-edition` owns the launch gates and should be consulted before relying on it.

**Delete, do not demote: all three rungs, while Q7's money gate is unpassed - delete the menu and its axis lines until it clears.** This is the one hard gate in the skill, and a ranked announcement menu sitting under an unpassed gate reads as a set of options with the cheapest one available now - which is exactly the choice behind the documented cancellations. Decide the date internally, publish nothing, and bring the menu back when money handling exists.

Once published, the date holds and scope moves instead - `samber/dev-event-organizer-skills@event-planning-timeline` owns what happens after.

## Workflow

1. Run the interview. Fix the audience's time ownership (Q1) before anything else.
2. Set the day type from that answer - weekday for employer-time audiences, weekend for personal-time audiences - and record which guide the rule came from.
3. Bound the season: propose a rough window from the user's own prior editions and the audience's institutional calendar, labelled as a hypothesis, never as a seasonal fact.
4. Run the constraint checks at the chosen depth rung, working outward from the audience's own calendars. Report any observance check you could not complete as outstanding, not as clear.
5. Scan competing and anchor events across the window; for each hit, decide explicitly whether to dodge it or piggyback on it.
6. Generate three to five surviving candidate windows and carry all of them into the venue conversation ("Get Options"); let availability rank them.
7. Check the money gate (Q7). If it is not passed, stop: the date can be decided internally but not published.
8. Pick the announcement trigger from the menu, publish, and hand the locked date to the planning-timeline sibling.
9. Deliver section by section - day type and its source first, then the surviving windows with the constraint each rejected window failed, then the announcement plan - validating each with the user before moving on.

If your harness has persistent memory, record the chosen date and day type, the audience's time-ownership pole, every calendar checked and every one left outstanding, the competing and anchor events found with the dodge-or-piggyback call made on each, the rejected windows with their reasons, and the announcement date. Next edition's date selection starts from that list instead of re-deriving it, and the rejected-window reasons are the part that is never reconstructible later.

## Failure modes

- **Announcing before payment handling exists.** The one hard gate in this skill: teams that skipped it have rescheduled or cancelled outright. A date is a promise the moment it is public.
- **Averaging the weekday/weekend rule across audience types.** A compromise slot built for a mixed audience takes the worst half of each rule and serves neither pole. Pick the pole.
- **Treating a competing event as automatically fatal.** Piggybacking is documented practice: adjacency to a big event in the same city can raise turnout by letting travelers justify one trip. Decide per event; do not reflexively flee.
- **Inventing a holiday calendar from memory.** The most tempting failure in this skill, and the reason for the holiday guidance above - lunar and lunisolar observances move year to year, and a confidently wrong list stops the reader from checking a real one.
- **Applying a generic "avoid all school breaks" rule.** The documented nuance says a short break can _raise_ turnout for a single weekend event even though breaks generally reduce participation. Check the specific break, not the category.
- **Fixing one date before talking to the venue.** Converts an availability problem into a dead end; carrying options converts it into a negotiation.
- **Checking only your own event family's calendar.** A single family's homepage lists only its own events; the conflicts that actually pull your audience come from adjacent topics and different organizers.
- **Freezing a recurring series on one weekday and hour.** Excludes the same people every edition, and the loss never shows in attendance data because they never registered. Fix: rotate weekday and hour (§ Recurring series), or write down why the slot is fixed.
- **Defaulting a professional audience to the weekday evening.** Looks like the zero-cost slot, and reportedly costs caregivers, mostly women, and experienced practitioners with families. Fix: record time of day and who it excludes (§ Time of day).
- **Moving an announced date to rescue an unready plan.** Burns speaker, sponsor, and attendee trust, and costs a recurring event (Q5) far more than a one-off. Cut scope instead.

## Measurement

Every measure below is self-set. An attendance target attached to a date choice would be indistinguishable from the invented holiday calendar this skill refuses, so the gates below test the decision rather than the turnout.

Gates, checked before the date is published (pass/fail on the decision, not the outcome):

- **Day type matches the audience's time ownership**, with the guide it came from named.
- **Every calendar category in the checklist is either checked or explicitly marked outstanding** - none silently assumed clear.
- **The competing-event scan covered adjacent topics and different organizers**, not just your own event family.
- **The money gate passed before publication.**
- **At least three candidate windows entered the venue conversation** - unless Q3 named an external constraint that fixes the window, in which case the gate is that the constraint is written down with what fixes it and who could move it. This skill's own handling of a forced window is to stop generating candidates, so a flat three-window gate would fail the procedure it prescribes.

Track these edition over edition, self-set, as inputs to the next date decision, never as proof the last one was right - too much else moves between editions:

- Registrations in the first week after announcement, compared with the previous edition's.
- No-show rate against the day type chosen.
- How many attendees cite a conflict in the post-event survey.
- For a recurring series: attendance and newcomer share per weekday and hour slot, so rotation is judged on data rather than habit. Newcomer share is defined in `samber/dev-event-organizer-skills@event-community-building`.
- Where collected with consent: audience composition (for example women's share) per time-of-day slot.

## Invocation examples

- "We're planning a two-day DevOps conference in Lisbon next spring for working engineers. Help me pick the date."
- "Our student hackathon clashes with another one in the same city three weeks later - should we move, or is there a way to make it work?"
- "The venue offered us two windows in March and one in May. Which do we take, and when do we announce?"
- "Our monthly meetup has always run on Tuesday evenings. Should we keep it there?"

Expected output: a chosen day type with its source, three to five ranked candidate windows with the constraint each rejected window failed, an explicit list of calendars checked and calendars still outstanding, the dodge-or-piggyback call on every competing event found, and the announcement trigger with its prerequisite gate. A worked illustrative example and a negative example live in [references/competing-events-and-announcement.md](references/competing-events-and-announcement.md).

## References

- [references/audience-calendars.md](references/audience-calendars.md) - the audience-type rules with their sources, the calendar-category checklist, and how to verify each category for a specific year without inventing dates.
- [references/competing-events-and-announcement.md](references/competing-events-and-announcement.md) - the competing-event scan procedure and its fallbacks, piggybacking, the venue "Get Options" negotiation, the announcement gate checklist, and a worked example with a negative counterpart.

See also, same collection:

- `samber/dev-event-organizer-skills@event-planning-timeline` - the work-back schedule built from the date this skill picks.
- `samber/dev-event-organizer-skills@event-market-fit` - reads the same competing-event calendar as a demand signal rather than a scheduling constraint.
- `samber/dev-event-organizer-skills@event-first-edition` - the launch gates and runways a first edition's announcement should respect.
- `samber/dev-event-organizer-skills@event-venue-sourcing` - takes the candidate windows and ranks them by availability.
- `samber/dev-event-organizer-skills@event-positioning` - owns which audience pole the event is built for when Q1 splits.
- `samber/dev-event-organizer-skills@event-cfp-design` - its close date is worked back from the date this skill locks.