Custom User Registration Form

[sabinem]

As an organiser I want to compose my own registration questions, so that I
collect exactly what this event needs — when the standard fields are not
what I have to ask.

As a participant I want to answer them once, so that my answers are on
file — when I register.

Done when

• Organiser can create a form with questions with label, type (short text, single-choice,
  tags, long text, consent) and a required flag.
• When a user registers for a hackathon, he is redirected to the form to fill it in
• The user can also edit the profile later
• The organizer can see the users answers when he makes his decision to accept the registration and also when he makes the teams
• The registration form is no longer reachable when registration is closed

[caviri]

Hi @sabinem, this looks good to me. I'd add:

• the organizer can download the answers in csv, json including two extra columns: username and email

[sabinem]

@caviri Can we freeze certain operation on the form, once the registration started:

Organizers will need to change something, and refusing a typo fix is user-hostile. The useful move is to freeze only the edits that can damage existing answers:

Safe after registration starts — allow always

• Editing a label, help text, or placeholder (cosmetic; answers aren't keyed by prose)
• Appending a new optional question
• Making a required question optional (a relaxation — nothing already stored becomes invalid)
• Adding a new choice to a select

Unsafe — refuse once anyone has answered

• Deleting a question (destroys answers)
• Renaming its key (orphans them, silently — the failure mode I flagged earlier)
• Changing its type (text → number invalidates what's already stored)
• Making an optional question required (retroactively makes every existing submission incomplete)
• Removing a choice from a select (existing answers now point at a dead option)
• Adding a required question or a required consent (everyone already registered is retroactively non-compliant, and worse, they never saw the consent)

[caviri]

Hi @sabinem, yep, you are right I think we should freeze only the operations that could break or invalidate existing registrations once submissions have started.

Always allow: fixing labels/help text/placeholders, adding optional questions, making required questions optional, and adding choices to a select.

Freeze once answers exist: deleting questions, changing their key or type, making optional questions required, removing existing choices, or adding new required questions/consents.

In particular, consent fields should never be added retroactively, since already-registered users never saw or agreed to them. Itherwise we should send then an updated policy (which could happen but not in short term)