Discussion on New Instructor Training Workflow (and Schema)

The workflow for instructor training requires a lot of manual, unnecessary work. This is going to change. Today, I’d like to invite you to discussion on the proposal of the new workflow. At the end of this post, I consider how do we need to alter Amy database schema.

The current workflow

Let me quickly remind what the current workflow looks like. To become certified SWC or DC Instructor, you need to fulfill three requirements:

  1. Do your homework – that is, modify core lessons.

  2. Pass Discussion Session leaded by Mentors. You need to prove that you are familiar with the core lessons.

  3. Pass Demonstration Session, that is teaching for five minutes on one topic chosen by the Examiner.

There are two etherpads where you can register for Discussion and Demonstration Sessions. Admins and Mentors maintain data about progress of each Trainee in a bunch of Google Spreadsheets. The another source of truth is Amy database – we keep there list of all certified instructors. In the case of SWC, homework is sent as github pull requests. In the case of DC, Trainees put their homework in Google Doc.

The main disadvantage of the current situation is that data is stored in a lot of places: spreadsheets, etherpads, Amy database and github pull requests. This requires Admins and Mentors to manually copy data from one place to another to keep it in sync. Also, we cannot aggregate data living in different places. For example, we don’t know how many trainees did homework, but are still in progress?

The new workflow proposal

First of all, I propose that Amy database will become the main storage of data. I’d like to eliminate spreadsheets with progress of each Trainee and store that data in Amy database.

However, I don’t want to have everything in Amy database. Github pull requests are fine. We won’t track Discussion and Demonstration Sessions in Amy - we will store only the results of those sessions, that is who passed what type of session. Therefore, Trainees will register for sessions in etherpads, as they do now. This is a compromise that keeps Amy relatively simple and move to Amy the most important data that we want to analyze.

Amy will be exposed to Trainees, so they can register and login (using github account or “standard” registration), update their profile and download certificate. Trainees are infrequent users and we cannot expect much, so I want them to use Amy only when it’s unavoidable and there is no better option. For example, Trainees are familiar with etherpads, therefore we will use them for Session registration.

When a Trainee logs in with github account, but he had never logged in before, a new Amy account is automatically created. That is, there is no distinction between logging in and registration (at least when you use github account). To simplify the process, there is no account verification (like email verification).

I don’t want to change how Trainees register for Sessions. However, when a Discussion or Demonstration Session starts, the Mentor or Examiner shares a link with Trainees. This link is unique for each session. Trainees log in using this link. That way, the Mentor/Examiner can see only Trainees who participate in their Session. The Mentor/Examiner won’t have to pick people manually. That way we avoid issues with picking wrong person.

Schema changes

The challenges that we need to respond to are:

  • At this point, you need to fulfill a set of three requirements to become SWC/DC Instructor. This set has changed twice in the past year, and may change again in future. We need to track which set is associated to whom. What’s more, the set for SWC should be independent from DC set.

  • We also want to track progress of Trainees in Amy database instead of spreadsheets.

I propose to introduce new models:

  • Requirement – an enum, similar to Role, Badge or Tag. There are some preset records, like “SWC Homework” or “DC Discussion Session”. Those records can be modified in django-admin, but not in Amy interface.

  • RequirementSet represents set of requirements that must be fulfilled to become SWC/DC instructor. That is, there is many-to-many relation with Requirement. At the beginning, there will be only two records (one for SWC and one for DC), each one consisting of three requirements. When the rules of becoming certified instructor changes, we will create more records. Can you think of better name for that model?

  • Progress represents an attempt of a Trainee to fulfill one requirement (the Trainee did homework or participated in Discussion Session). This model have the following fields:

    • trainee
    • awarded_by – person who created that record; i.e. Mentor, who leaded Discussion Session
    • passed – whether the trainee passed the Discussion Session, or whether the homework was accepted
    • notes – text field for any additional data in unstructured form, for example date of Discussion Session or link to homework (pull request).
  • PersonGroup – represents a group of people (many-to-many relationship). Mentors and Examiners create a new group for each session and they can view all Trainees associated with that group.

The Person model needs additional fields: swc_requirement_set and dc_requirement_set.

Let’s discuss!

What do you think about the workflow and/or schema? Feel free to comment and criticize! If you don’t want to discuss in public below, you can always email me (chris at medrela.com).

About Krzysztof Chris Mędrela

I'm a Python Trainer. I deliver risk-free customized workshops on testing, Python, Django and Data Analysis in Europe.

Comments