Running a seminar or reading group

If you teach a seminar or convene a reading group, the site hands you a small set of tools: your event’s public page, the roster of who has registered, and the ability to set a different price for one person. This guide covers all three. (If you’re looking to register for something rather than run it, see Seminars & registration.)

What’s yours to decide

Yours: the event page’s description, readings, schedule note, contact line, CE credits, and guests-welcome note; the roster; whether registrations are reviewed before they’re confirmed, and the approvals themselves; and what any individual pays, and when.

The Program Committee’s: the listed fee and its price tiers (built from the proposal they approved), publishing the page, opening and closing registration, the access details, and who is listed as faculty.

The treasurer’s: refunds, payments made by check or cash, and anything already paid.

That boundary answers most questions before they’re asked. If what you want is in the second or third list, ask rather than work around it.

Where your tools are

Seminars and reading groups keep them on the group’s Workspace, under the Roster tab. Open your groups, choose the seminar or reading group, then Roster.

One-off events—a special event, a Day of Assembly—keep them on the event page itself, behind the Faculty view button.

Either way it’s the same panel: pending approvals (when the event uses them), the roster, the form that mints pricing codes, and the codes you’ve minted so far.

Your event page

Edit event opens the page’s content. Some fields take effect immediately: the schedule note, contact, CE credits, who can register, and whether sessions may be recorded.

Who can register is a real restriction, not a note. Members and guests, the default, lets anyone with a free account register and says so on the page. Members only turns non-members away at the registration page, and you can still admit one of them by hand with a pricing code addressed to them (see below).

Changing the title, description, readings, or fee note of an event that came from an approved proposal is different. The School approved a particular offering, so those edits go through a short dialog: mark the change minor and it’s adopted at once, or send it as substantial and the Program Committee sees it in their review queue. Your live page stays as it was while a substantial change waits.

Who has registered

The Roster tab lists every registration with the person’s name, email, tier, amount, and status—awaiting payment, paid, comped, or cancelled. Download CSV gives you the same list for your own records.

Reviewing registrations before they’re confirmed

Edit event carries a tick box, Review each registration before it’s confirmed. With it on, registrations arrive in a Pending approvals strip at the top of the Roster tab, and nobody is charged until you approve. You’re emailed as each one comes in.

You can turn it on or off at any point, including partway through a run. Turning it on only affects registrations made from then on, so anyone already registered keeps their place. Turning it off approves everyone still waiting, so the queue never outlives the decision that created it. The event page tells members that registrations are reviewed, so nobody is surprised by the wait.

Fees, discounts, and scholarships

Where the listed price comes from

The prices on your event page are its price tiers, built when the Program Committee approved the proposal. A tier can be a flat amount for everyone, an amount per audience, a sliding scale (the payer chooses any amount at or above a floor, sometimes zero), or covered by tuition (free for members currently paying tuition). Tiers themselves are the Committee’s to set (based on your proposal). The fee note is yours, and it’s the right place to say in words what the fee means.

A pricing code changes the price for one person

To give someone a reduced fee, mint a pricing code on the Roster tab, under Generate a pricing code. You choose:

• Percent off—a percentage off the listed price.
• Fixed amount—the person pays exactly this.
• Sliding-scale floor—the person chooses their own amount, at or above the floor you set.
• Full price—no discount at all. Pick this when what you’re offering is a payment plan rather than a lower price.

Then Number of payments, which spreads the fee over time rather than reducing it (see Spreading the fee over several payments, below), and optionally an expiry date, a maximum number of uses (leave it blank for unlimited), and Only this person may use it.

The code appears under Existing codes with its uses remaining and its number of payments, so you can see at a glance what you offered and whether it has been taken up. The person you gave it to enters it in the Pricing code box on the registration form.

If you pinned it to one person, they don’t have to do anything. A code addressed to a named member applies itself the moment they open their registration page, or the moment they register. They see the new price without entering anything, and a $0 code confirms their place on the spot. Sending them the code does no harm, but it isn’t needed.

Two kinds wait for them rather than applying themselves, because both ask for a decision: a payment plan (they should see the schedule before taking it) and a sliding-scale floor (they choose the amount). Those appear on their registration page as a code set aside for them, ready to accept.

If they registered before you minted the code, that all still works. Their registration page has a Have a code from your convener? box, and a pinned code applies on sight anyway.

For a specific LSP member

Mint the code, pick them under Only this person may use it, set the maximum uses to one, and send them the code. Pinned to their account, it can’t travel.

For someone outside the School

Anyone may attend a public event, but everyone registering needs an account. A free account takes a minute to make and carries no membership or obligation, so it’s a small thing to ask of a guest.

• If they already have an account, pick them by name and set one use, as above.
• If they don’t yet, leave Only this person may use it blank and set the maximum uses to one, then send them the code along with a link to the event. The single use makes it effectively theirs: whoever redeems it first spends it.

An unrestricted code with no use limit is a public discount. That’s fine when you mean it, and worth avoiding when you mean to help one person.

If your event is set to Members only, the code has to be pinned to them, so they need an account first. Ask them to create one, then pick them under Only this person may use it. An unrestricted code won’t get a guest in, however few uses it has left.

Spreading the fee over several payments

Sometimes the fee isn’t wrong, the timing is. Set Number of payments to 2 or more and the fee is divided evenly. The total doesn’t change, so this isn’t a discount, it’s a schedule.

The payments are spread across the run of your event. On a seminar running September to May, two payments land roughly in fall and spring, four land two in each term, and nine come about monthly. On a four-week workshop they simply fall a month apart, and on a group running January to June they spread over those months instead. You choose only how many; the dates follow from your own dates, so the last payment always arrives before the group finishes.

The two settings are independent. Leave the mode at Full price for a plain plan at the listed fee, or combine them, 20% off payable in three, if that’s what the person needs.

What they see. Redeeming the code doesn’t charge them anything. It takes them to their registration page, which lists every payment and the date it falls due, and they pay the first one from there. Their place is confirmed as soon as that payment clears, so they attend from the first session like anyone else. The remaining payments stay on that page, each with its own Pay button, and the site emails a reminder as each one comes due. They can also pay ahead if they’d rather.

What you see. Your roster marks them On a plan, with no amounts and no sign of whether they’re behind. You extended the terms, so you know the plan exists; how it’s going is between them and the treasurer.

If the payments stop. Nothing happens automatically. They keep their place and the site keeps reminding them. If it needs resolving, it’s the treasurer’s, and they can suspend access if it comes to that. The same goes in the other direction: a member on a plan can’t cancel and refund themselves, the button sends them to the treasurer, because part-way through a term what’s owed back is a judgment.

A full scholarship

Fixed amount, $0. The registration confirms on the spot with no checkout step, and the access details reach them exactly as they would a paying registrant.

What a code can’t do

• Change the listed fee for everyone. That’s the Program Committee, and it’s the honest fix when the whole price is wrong.
• Refund or reduce something already paid. Once money has moved, it’s the treasurer’s to reverse.
• Work on another event. Codes belong to the event they were minted on.

If you convene a reading group

Everything above is yours too. Reading groups are convener-led rather than faculty-led, so you appear as an organizer on your group’s roster rather than as faculty, and the tools sit in the same place: your group’s Workspace, Roster tab.

Access details, the room, and recordings

Access details—the room, the address, or a meeting link—are set with the event and shown to anyone registered. You and your co-faculty see them without registering, since you’re the ones running the meeting. If they’re wrong or missing, ask the Program Committee.

If the event meets in the site’s own video room (recommended), there’s nothing to send: the join button on the event page and on your Workspace’s Meet tab is the way in, and it appears for registrants when the meeting is live.

Recording is opt-in. Nothing records itself. A host starts the recording from inside the room, and only when recording is enabled for your group.

Who to ask

• Program Committee—fees and tiers, dates, publishing, opening or closing registration, access details, faculty listings.
• Treasurer—refunds, checks and cash, anything already paid.
• Anything else, or something that looks broken: website@lacanschool.org.