Page MenuHomePhabricator

Investigation: Changing cohorts into campaigns
Closed, ResolvedPublic3 Estimated Story Points


Right now, programs on the Dashboard can be split into "cohorts" -- at the moment, Art+feminism, Dc, Wmuk, Year of Science.

These cohorts are created and assigned by .... (I think Sage does it by hand).

All of the other programs are in "Miscellanea".

To make the Dashboard scaleable, we need campaign and program organizers to be able to create and assign their own groups.

That means:

  • Change the word Cohorts into Campaigns.
  • Change the word Miscellanea to Unaffiliated.
  • Each program will either be associated with a campaign, or unaffiliated.
  • Organizers can create, edit and delete campaigns. Each campaign will have a campaign overview page.
  • Organizers can create a new program in an existing campaign.
  • Organizers can attach an existing program to an existing campaign, or detach one (and make that program unaffiliated).

The investigation: What exists in the current structure that needs to change, in order to make this possible?

Explore page (to be renamed "Find Programs")
Campaign - Programs tab (when clicking on a campaign on Find Programs page)
Campaign - Overview tab
Program - Overview tab (existing)

Event Timeline

Any admin can create a new cohort by going to the cohorts view:

DannyH added subscribers: awight, Elitre, StudiesWorld.

@Ragesoss Who are the admins, besides you? We'll probably need at least Leon and me to be admins, so we can work on this.

You're both admins now.

The full set of admins currently:

Richard Nevell (WMUK)
DannyH (WMF)
Sage (Wiki Ed)
Ryan (Wiki Ed)
James Hare (NIOSH)
MusikAnimal (WMF)
DannyH set the point value for this task to 2.Sep 6 2016, 10:39 PM
DannyH moved this task from To Be Estimated/Discussed to Estimated on the Community-Tech board.
DannyH changed the point value for this task from 2 to 3.

Model layer:

  • Use the same model as cohorts, and adding start/end times along with description, organizers, etc. This involves adapting much of the existing logic and tests for programs
    • If enough things differ between campaigns and cohorts, we might go off of the same model structure we have for courses, where there is a parent Course model that other models inherit. So we'd have something like the existing Cohort model with WikiEdCohort and Campaign models that inherit Cohort, allowing us to add some specific logic for campaigns that we don't want for WikiEd cohorts
  • If campaign organizers are different than program organizers, we'll need a new model for this, along with tests and other underlying logic, again mimicking the existing relationship between program organizers and programs
  • Deleting campaigns should probably instead be "archiving" or "marking as deleted", rather than removing from the database altogether. This would require another column in the cohorts table

View layer (wireframe):

  • Essentially using the same Details component you see on a program landing page, but the data will for a campaign rather than a program
    • Current React components are somewhat hard-wired around courses (aka programs), so we'll need to somehow abstract it to do courses or campaigns (doable but will be tricky)
    • Validations and other date-specific functionality should work in the same way with little modification, again only the data will be from the campaign model instead of the program model
  • A "create campaign" option will be added to the "View other campaigns" dropdown, and perhaps also a button to do this (easy)
    • Abstract the same CourseCreator React component to work for courses or campaigns
  • Ability to attach existing programs to a campaign, or move them to "unaffiliated", would involve an entirely new view and controller logic

Controller layer:

  • Need to make all the cohort endpoints respond to JSON (should be easy)
  • New controllers for any new models we create, also with JSON endpoints

Overall I think most of this is very feasible and, at the simplest approach, theoretically not as much work as it sounds like since the new logic, relationships, views, etc, are essentially the same except adapted for the higher campaign model. However this at the very least involves significant busy work, and will require lots of tests. Finally doing this alongside normal development on WikiEd may cause regular code conflicts.

To move forward this, my gut instinct is to take it step by step to avoid conflicts, starting with migrations and model changes. We'll probably also want a feature flag of sorts to show/hide the "Details" module above the list of programs on the campaign landing page.

My assessment is of course based on my knowledge of the codebase, which is somewhat limited :) @Ragesoss what do you think? Hopefully this clears up exactly what we're trying to do

Awesome, I'm glad you're figuring this out.

Campaign organizers and program organizers will be different people. I could start the Wiki Loves Poets campaign and run one program in SF, but then Leon in NY would run another program.

In that example, I'm the campaign organizer setting up the campaign, and I'm the program organizer for the SF event. But Leon is just a program organizer for the NY event.

So there is overlap -- probably every campaign organizer will also run a program -- but there will be lots of people who are just a program organizer.

Okay, investigation take two (somewhat technical), and applies to an early version of these features, subject to more improvements with time:

  • On the backend and frontend, we're renaming Cohorts to Campaigns across the board (so for WikiEd, too)
    • Campaigns will have several new attributes: description, template_course_id (explained below), and will also have organizers that belong to a campaign (as a separate CampaignsUsers model, similar to CoursesUsers)
    • When a user creates a campaign, a campaigns_users record is created, associating them with that campaign
    • An active attribute (true or false) will be also added, along with start and end times. These will control what shows up under "Active Campaigns" on the explore page, and when programs can be created and assigned to a campaign
  • Explore becomes "Find Programs" (maybe not for WikiEd, but the interface will be the same)
  • Just like we have with programs, there will be a dedicated set of pages for Campaigns
  • Campaign - Overview tab
    • Wireframe:
    • Acts similar to the program overview page, except built in pure Rails forms
    • Organizers can associate a "templated" course in the details form. This will initially simply be an input field to enter the slug of the template course (so not full preview like in the wireframe). In a later version, a "Create course template" button might be shown, that will go to the course creator and automatically associate it to the campaign as the designated template
    • Organizers can also add/remove CampaignsUsers in the Details, similar to how facilitators and courses
  • Campaign - Programs tab

Again we'll do this in a step by step process. Starting with the model changes, then the views, followed by refinements.

This looks good to me. Any comments @DannyH ?

Yes, this is great.