Overview

This is the last step of the contributor journey, and it merges what used to be three separate pages, planning, hosting, and delivering, into one: how to run a live XRPL workshop. You have already learned the platform, authored content, and seen how to assess and give feedback to learners. This is where you put a cohort in a room, physical or virtual, and run the session.

Two things decide most of whether a workshop works: the tools you give people and how you pace the room. So most of this module is there. We use the XRPL Commons two-day training as a concrete shape to reason from, and we stay at the facilitation altitude. Nothing here re-teaches what an account or a transaction is.

Plan a paced agenda

The biggest difference between a workshop that works and one that drifts is whether time is budgeted or merely hoped for. A topic list ("we will cover accounts, payments, and an AMM") tells you nothing about whether it fits in the hours you have. An agenda with the clock attached does.

The Commons training runs on a fixed rhythm each day: a welcome window, a keynote to frame the concepts, a break, a hands-on coding session, lunch, an afternoon keynote, another break, a longer build activity, and a Q&A close. Three things are worth copying at any scale:

Concept first, then hands-on. A short framing block earns you the right to the keyboard. Keep the keynote short and get people typing while attention is fresh.
Breaks are part of the plan. Hands-on attention decays fast. A scheduled break every 60 to 90 minutes resets the room and gives stragglers time to catch up.
One anchor activity per block. A single named deliverable, make a payment, spin up an AMM, beats a block that tries to cover four features and finishes none.

Attach a wall-clock time to every line and add up the minutes. If the total overflows the slot, and it always does on the first pass, cut scope now, in planning. If you built the workshop as a journey, its ordered steps are already a skeleton agenda; you attach the clock on top.

Set up a ready-to-go environment

The fastest way to lose a hands-on session is to spend the first half hour on setup. XRPL Commons now provides a ready-to-go training repository that opens in GitHub Codespaces. Attendees click one button and get a full environment in the browser, with the XRPL SDK installed and configured for several languages (JavaScript, TypeScript, and more). There is no local install, no version drift between machines, and nothing a corporate laptop's permissions can block.

Point everyone at Testnet, where funded accounts are free and nobody risks real value. Send a short pre-flight checklist a few days ahead (open the Codespace, create an account, run one self-check), and make the first hands-on checkpoint trivially small, fund an account and read its balance, so everyone clears setup together before anything hard arrives.

Choose delivery tools we can help you set up

For a remote or hybrid session, a meeting platform is your room. Zoom and Google Meet both cover the essentials: screen share for live coding, breakout rooms for pair work, and recording for anyone who cannot attend. The practical difference with other tools is that XRPL Commons can help you set these up for a session, so ask rather than configuring it alone.

For engagement, Wooclap keeps a keynote or framing block active and gives you a read on understanding: live polls, quizzes, word clouds, and an ask-questions wall. It is widely used in universities, which suits an academic cohort. Use one poll early to check your framing landed before you send everyone to the keyboard.

For continuity, a community space such as Discord, where the XRPL Commons community already lives, carries side questions during the session and keeps the group talking afterwards.

Have a fallback for each tool, and test it against the venue's real network before the room fills. Assume the WiFi will be worse than promised.

Watch the room on the Console

When your workshop runs as a journey, you get a live view of the whole cohort. Open the journey's Console before the session and keep it up. It shows each participant's progress, a matrix across the group, and quiz outcomes, and it flags who needs a nudge: the learners who have not started, have stalled, are behind the pace, or have a submission with changes requested. It catches the quiet person who is stuck but has not raised a hand. The Roster shows who is actually active.

When the Console shows someone stalled, nudge them, individually or in bulk (there is a cooldown so you do not spam), and use announcements and kudos to speak to the whole cohort. Submissions that need your eyes land in the Reviews queue; reviewing them and giving feedback is covered in Assessment & Feedback Methods.

Pace a hands-on session for a mixed-speed room

Your cohort is never moving at one speed. Pace to a rolling middle, with explicit handling for both tails:

Work in checkpoints, not a monologue. Break the activity into small steps that each end in something observable: a transaction that validates, a balance that changes, an object in the explorer. After each, pause and measure: "drop a green check when your payment validates." On the Academy you watch these land on the Console.
Code live, slowly, and narrate. Type in front of them rather than pasting finished code, and say what you are doing and why. Mistakes you fix on the spot are some of the best teaching moments.
Give the fast finishers a stretch. Keep an optional "if you are done early, try..." extension ready.
Do not wait for 100%. Move when a clear majority hits the checkpoint, and route the stragglers to help.
Get a second pair of hands. One person teaches from the front while another unblocks individuals. Solo, lean on pairing attendees and on the Console to spot who is falling behind.

Handle the learner who gets stuck

Someone will get stuck. The skill is unblocking them without stopping the session or making them feel exposed. First, decide whether it is a one-person problem or a whole-room problem. If three people hit the same error, address it from the front; it is now a teaching moment. If it is one person, take it to the side: a breakout room, a direct message, a "let us look right after this step."

When you help, resist typing the fix yourself. Ask what they expected versus what they saw, and get them to read the actual error out loud. Most blocks are mundane: a typo, the wrong network, an un-funded account, a missing await. The diagnostic habit you model is worth more than the fix.

Protect the emotional climate. People learn nothing while embarrassed. Normalise errors out loud ("great, that error is one everyone hits"), never sigh at a question, and make it obviously safe to say "I am lost."

Close, and keep the door open

Do not let a workshop dribble out at "okay, we are at time." Reserve a real Q&A and close to surface the questions people did not want to ask mid-flow, restate what they built, and point at what comes next. Then keep a door open: schedule office hours, and keep the conversation going in your community space. The Academy carries the async side of this for you, and reading how your cohort felt and following up one to one is covered in Assessment & Feedback Methods.

Finally, run a dry run before any real workshop. Deliver it to a few colleagues, watch where they stumble and where your timing breaks, and fix the run-sheet before a public cohort meets it.

Check

You are ready when you can turn a topic into a facilitator run-sheet for a two-hour hands-on XRPL workshop: a timed agenda with a framing block and at least one hands-on segment; the ready-to-go Codespaces environment and pre-flight checklist; the delivery tools you have chosen and why; the checkpoints where you pause to watch the Console; and a written stuck-learner and backup plan. Hand it to a peer who has taught before and have them pressure-test it: does the time add up, is it obvious what happens when a tool fails, and will you notice when a learner falls behind?

Running Workshops & Live Sessions