Epic: carry forward 'designing season rollover'

[hellafitz]

from #2551

[stenington]

Just summarizing the main themes in this one as I see them:

There are a few aspects to season rollover that we may want to address. Firstly, what the program team would like returning users to do and what the platform will require them to do doesn't perfectly align. Also, what the program team would like returning users to do hasn't been consistent from year to year so we may consider building some controls into the platform so they can make that decision on their own at the start of a season.

Secondly, we talk about admins having the ability on the platform to control user registrations, and I think we conflate that with season registrations, which is false. User registration could also be called new user sign up, whereas season registration happens automatically the first time we see a user log in during the season. That means there are configuration scenarios where returning users get registered to seasons in slightly unexpected ways. We could probably improve upon that.

[hellafitz]

Mock up returning student user info confirmation flow #2583 Mockup returning mentor user info confirmation flow

2593

spike: what happens when a student account ages out [8,8,1]

2585

Make data terms agreement re-collectable

2582

[hellafitz]

DONE spike: what happens when a student account ages out [8,8,1]

2585

• next step: discuss findings w/ BAR

Make data terms agreement re-collectable

2582

Mock up returning student user info confirmation flow #2583 Mock up returning mentor user info confirmation flow

2593

Open Q: what does it mean for a user to be signed up but not registered for a season?

reference doc: Designing Season Rollover, https://docs.google.com/document/d/1oBVG_RMi6SVQ8KlznqmdRT_FuNCgRCkBy8maM4tXeWA/edit#heading=h.7wh191bk4ijs