The race calendar ended with one sentence: “Is an event missing? Write to us.” You wrote, we copied the e-mail by hand, and in between a race could wait for days. If you know a race that isn't there — because you organise it, or because you go every winter — you can now propose it yourself.
What changes
Six fields. The event's name (without the year: it comes from the date), the start and end dates, the starting place, the country, and the link to the organiser's site or entry page. That link is where an admin checks the dates before publishing. If the dates aren't certain, tick “Dates to be confirmed”. Optional: the terrain, the disciplines, and a line for the admin (140 characters, never published).
Duplicates, while you type. As soon as the name has three letters, or the start date and country are set, the form searches the calendar and the proposals already waiting. It relies on three clues: a name that looks alike, the same place within a few days, the same days in the same country. Two cases:
- “This looks like an event already on the calendar”, in amber, when the name looks alike, or when the place and dates match. You answer before sending: “It's the same one (propose a correction)”, or “No, it's a different one”.
- “To check”, calm, when only the days and the country match. It's information; nothing is blocked.
At most three candidates are shown, the most likely first.
Correct a race that is already there. From a race's page, or from “It's the same one”, the correction opens pre-filled. You can change the dates, “to be confirmed”, the place and the link, or tick “The event is cancelled”. A “What changes” box shows the difference as you go. While nothing has changed, the button stays inactive.
My proposals. A page where you follow what you proposed: waiting (you can withdraw it), published (with the link to its page), partly applied (what was taken, what wasn't), or refused, with the reason in full.
On the phone, it's at the bottom of Manage › Organization › Events: “Propose an event” and “My proposals”, with the same form and the same duplicate box. You need to be online; offline, both rows are greyed out and say so.
What others see
- Nothing, until an admin has decided. A proposal appears neither on the calendar, nor on the map, nor on the phone until the admin has published it or merged it into an existing race.
- Never your name. Not on the calendar, not on the race page, not in another musher's form. If your waiting proposal looks like what another musher is typing, they see the name, the dates, the place and “Already proposed, waiting for an admin” — never who proposed it.
- The admin sees your display name, and how many of your proposals were published before. They don't see your address.
What the form does not do
These are choices, not oversights.
- It creates no classes, fees or entry dates. Those need to be read at the source, class by class: the admin adds them afterwards. If you know them, write them in the line for the admin.
- It publishes nothing on its own. Every proposal goes through an admin, who publishes it, merges it or refuses it.
- It merges and refuses nothing by itself. The duplicate box is there to help you; it doesn't decide. A race that looks like another is never set aside without an admin having looked at it.
- There are no country correspondents yet — mushers who would propose their region's races with more confidence. When they come, their proposals will go through the same queue.
A proposal touches neither the name, nor the country, nor the terrain of an existing race: those fields stay with the admin. The line for the admin is how you point them out. At most ten proposals can be waiting per account, while an admin checks them.
Choices against the obvious
A likely duplicate blocks sending until you have answered. The obvious: let it through and let the admin sort it out. But that is exactly what made each proposal work for the admin. You know better than they do whether “Femund” is the Femundløpet: one click from you saves them a search, and the database refuses to send while the question is open. “No, it's a different one” is enough to go on, and the admin sees your answer. A weak clue (“To check”) never blocks: it shouldn't hold you back for nothing.
The admin gets an e-mail for each proposal. The obvious: a counter in the console is enough. But a race proposed in October that waits a week may have closed its entries in the meantime. The e-mail gives the name, the dates, the place, the possible duplicates and the link to the proposal — and never your name or address, even there.
You get an e-mail for each decision, with the reason word for word. The obvious: a “My proposals” page is enough, and a reason can be summed up. But nobody goes back to check a page for a race proposed ten days ago. The e-mail tells you when the race is published, partly applied or refused. A refusal repeats exactly the sentence you read in “My proposals”, for example “This is not a sled dog event open to the public.”. The message is the same everywhere: you never have to guess which one is right.
Several events? Propose a file
Since 29 October, a whole season can be proposed at once. If you keep your region's or your club's races in a spreadsheet, there's no need to copy them one by one into the form: under “Propose an event”, choose “or as a file” (the link is also at the top of the form, and in “My proposals”).
Four ways to bring the season in. A CSV, an Excel file (.xlsx — from Google Sheets: File › Download › .xlsx), the calendar's import JSON, or a pasted text or a PDF: a race programme, an organiser's e-mail. A template, in CSV or Excel, gives the form's columns; your own headers work too (“Race”, “From”, “Town”, “Link”…).
We read, tidy and compare, and you see all of it. Dates, countries and links are put into shape; a corrected cell says so (“corrected: read ‘13/3/27’”), a cell that is missing or can't be read is marked. Every row goes through the same duplicate search as the form, against the calendar — and also against the other rows of your file: two rows that look alike ask you to “Keep both” or to remove one.
You validate the table before sending. You correct in the table, remove a row, answer the “This looks like” questions. Nothing goes before “Send the n proposals”, and the button says what is still missing. One send carries 50 rows at most; the following ones are listed and download as a CSV for a second send.
The batch, in “My proposals”. Your file becomes a single entry there, with its tally (published, waiting, refused…), which unfolds into its rows. You can withdraw a waiting row, or the whole batch.
On the phone, “My proposals” shows the batch and its rows, and withdraws a waiting row. Dropping the file and the table happen on the website — the “Propose from a file” row opens it — because reviewing fifty rows takes a wide screen.
What others see
- Nothing, row by row, until an admin has decided. A row of your file appears on the calendar only once the admin has published it or merged it.
- Never your name. The e-mail the admin receives for your batch carries neither your name, nor your file's name, nor the rows set aside. In the console, the admin sees your display name, as for a single proposal.
- Only you see the file's name, in “My proposals”.
What the file does not do
These are choices, not oversights.
- It publishes nothing on its own. Every row goes through an admin.
- It doesn't read .xls or .ods files. Save them again as .xlsx or CSV: those older formats read badly, and a misread date is a race on the wrong weekend.
- It creates no classes, fees or entry dates, even if your file has them: as with the form, the admin reads them at the source.
- It reads a text or a PDF with AI only for full-access accounts (trial or subscription). CSV, Excel and JSON are open to everyone, and read in your browser, without AI. A text or a PDF is sent to Anthropic, our processor in the United States, at that moment only; the privacy policy says so.
- It doesn't keep your file. Only the rows you send are kept and, for those set aside, their number, their name and the reason — so you find them again in “My proposals”.
Choices against the obvious
A row set aside is shown, never swallowed. The obvious: hide what doesn't pass, for a cleaner table. But a row that disappears silently is a race missing without anyone knowing. Each row set aside — empty, already over, in a country not on the calendar, a duplicate — says why, and can be put back when that makes sense.
A batch counts as one proposal. The obvious: thirty rows, thirty proposals, and the limit of ten reached straight away. But that limit protects the admin from scattered sends; a batch is reviewed as a block, in a single view. Counting rows would have made the file useless beyond ten races.
The admin publishes the rows without duplicates in one gesture, but never “checked at the source”. The obvious: review everything row by row, or publish everything at once with the same seal. A row with no candidate in the calendar or in the batch, new, with no uncertain field, in a single-time-zone country, has nothing to decide: the admin publishes it with the others of its kind. But “checked at the source” means someone opened the organiser's page that day; a group gesture didn't, and the race page says so until it's done. All other rows are decided one by one.
The AI decides nothing. What it is unsure of is marked “to check”, for you in the table and for the admin in the console; a row carrying such a field never goes into the group gesture.
One e-mail for the whole batch. The obvious: one e-mail per decision, as for a single proposal. But thirty rows would make thirty e-mails. You get one, when the last row is decided, that goes over each row and its decision — a refusal with its reason word for word.