Forms

Forms and Questions

The Forms are implemented as a collection of Questions. This allows flexibility in changing form questions.

Questions can be of different types (InputType), for some types, there will also be optionGroups.

Example: “What Role will you be participating as in this Voyage?”
inputType: radio
OptionGroup: role
OptionChoice

id	text
1	Developer
2	UI/UX
3	Product Owner
4	Data Scientist
5	Voyage Guide

Example: "Before you go is there anything else you'd like to share with us?"
input type: text
no optionGroups or options

Option Groups can be reused for different questions with the same choices.

Responses / Answers

In general, responses will be recorded individually, and what saved in the database depends on the question type. There are 4 types of response input, text, numeric, boolean and optionId. Responses are required to have at least one of the above.

Theses responses are grouped into ResponseGroup, and the responseGroupId is linked to different tables.

For example, each solo project record would include both solo project info, status, evaluation, etc, which are not collected by the solo project form. There would also be form collected responses linked to them, using ResponseGroupId

Solo Project Table

Table "SoloProject" [headercolor: #EB801B] {
  "id" integer [pk, not null]
  "userId" uuid [Note: 'uuid']
  "evaluator" string [Note: 'uuid, evaluator is also a user, they may have an "evaluatorId" based on future role implementation']
  "evaluationFeedback" string [Note: 'this is currently not shown to the user by (UI) design, but it can be if needed, evaluator will DM this to the user on discord']
  "adminComments" string [Note: 'admin comments (for admins and evaluators, not visible to users, might need to extend to another table for multiple comments like how it is now on airtable']
  "soloProjectStatusId" integer [not null, default: 'waiting eval']
  "formId" integer [not null]
  "responseGroupId" integer [Note: 'group of responses']
  "createdAt" timestamp [not null, default: `CURRENT_TIMESTAMP`]
  "updatedAt" timestamp [not null, default: `CURRENT_TIMESTAMP`]
  Note: 'Solo project info - one to one relationship with responseGroup, which includes responses to solo project form'
}

Sprints meeting forms, Voyage Application, and pair programming are also implemented in a similar way.

Todo

• add a trigger/prisma middleware to delete responseGroup when (child - solo project, voyage application, meetingform, etc) are deleted, they are 1 to 1 relationship