diff --git a/content/blog/2022-10-17-future-of-teaching.md b/content/blog/2022-10-17-future-of-teaching.md
index d876dcb1..b51891ea 100644
--- a/content/blog/2022-10-17-future-of-teaching.md
+++ b/content/blog/2022-10-17-future-of-teaching.md
@@ -69,7 +69,7 @@ is the "start page" of the series):
 * Teams
 * [Hybrid courses vs reverse-hybrid courses](@/blog/2022-11-07-reverse-hybrid.md)
 * Open source courses
-* Registration and learner management
+* [Registration and learner management](@/blog/2022-12-05-registration.md)
 * [Livestream courses](@/blog/2022-11-14-livestreaming-courses.md)
 * Collaboration in organizing
 * [Publishing videos supports more learning styles](@/blog/2022-11-08-video-publishing.md)
diff --git a/content/blog/2022-12-05-registration.md b/content/blog/2022-12-05-registration.md
new file mode 100644
index 00000000..2b35a0f6
--- /dev/null
+++ b/content/blog/2022-12-05-registration.md
@@ -0,0 +1,89 @@
++++
+title = 'Registration and learner management'
+slug = "2022/12/05/registration"
+description = "Large courses are more demanding on registration than you'd expect, but we have some ideas."
+
+[extra]
+authors = "Richard Darst"
++++
+
+*Part of a series on the [Future of
+Teaching](@/blog/2022-10-17-future-of-teaching.md)*
+
+Registration and managing learners can be hard when there are hundreds
+of them, but if you plan out a course well, it's manageable.
+
+In a small course, you register and people come, and everything else
+gets figured out from there.  When you have more than a hundred people
+coming, there are pre-made [teams](TODO:LINK), and you don't have "sit
+an empty table", registration can be much, much harder.  Luckily, if
+you plan the course considering that registration will be a major
+task, it can work out OK.
+
+## Basic registration strategies
+
+**Basic registration** would be easy: you let people sign up, they can
+get emails.  Since we
+[livestream](@/blog/2022-11-14-livestreaming-courses.md), people can
+even attend without registering, which we think is important (providing
+personal data is not necessary to attend - this is by design).
+Registering allows someone to receive emails, and it's relatively easy
+to send different emails to different groups if desired (for example,
+those from our university get information on our local
+online/in-person exercise sessions).
+
+At Aalto University, this is what we have done for most online
+courses, and it works well.
+
+## Registration including teams
+
+If we want to provide [teams](TODO:LINK) as a service, things get more
+involved.  The man idea of registering including teams is that we want
+to make them pre-arranged and the same day-after-day.  We want to
+provide an exercise leader for each team (the same one each day).
+The in-person equivalent is "sit at a table with at group, that group
+is yoru team".  Our online version is much harder than this, since we
+pre-plan a lot more.  We *could* emulate this by randomly assigning
+Zoom breakout rooms on day 1, and then ask people to join the same one
+each day.  But, we think that part of the benefit is assigning similar
+teams (if you know someone, you are with them) and having it clear
+that rooms *will* stay the same day-after-day.
+
+
+So, to do this teams online, our registration system needs to:
+* Accept the normal registration
+* Know a little bit about people to assign them to suitable teams (if
+  desired).
+* Provide a way for people to indicate pre-made teams.
+* Provide a way for us to see the information above easily and assign
+  the teams ...
+* ... and then send everyone a customized email with their team's room
+  number
+* And be able to quickly update this information based on last-minute
+  changes, send people new info, and not get overwhelmed with this
+  job.
+
+This, especially the last one, turns out to be exceptionally hard.  We
+are working on ways to make this better:
+- point1
+- point2
+- point3
+
+## Distributed registration
+
+The livestream and [reverse
+hybrid](@/blog/2022-11-07-reverse-hybrid.md) approaches allow another
+option: **distributed registration**.  With this idea, we don't need a
+central registration (or if we do, it can be only for general
+information), and we let each local partner run a registration that
+includes the teams - and let them deal with that locally in a smaller
+and more manageable form.
+
+
+## Summary
+
+We did a lot of great things with [teams](TODO:LINK), but it was a lot
+of work back then, and is still a lot of work now.  Anyone running a
+large course (that goes beyond "infodump to an audience") should
+carefully consider how to make this manageable.
+