Any admin can create a new cohort by going to the cohorts view: https://outreachdashboard.wmflabs.org/cohorts

You're both admins now.

The full set of admins currently:

Pharos
Ragesoss
Rhododendrites
Jami430
Richard Nevell (WMUK)
TFlanagan-WMF
DannyH (WMF)
Sage (Wiki Ed)
Ryan (Wiki Ed)
James Hare (NIOSH)
MusikAnimal (WMF)

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)
  • Wireframe: https://meta.wikimedia.org/wiki/File:Explore_page.png
  • Use the existing Rails views to create the list of campaigns above the list of programs. Again, only active campaigns will be shown
• Just like we have with programs, there will be a dedicated set of pages for Campaigns
• Campaign - Overview tab
  • Wireframe: https://meta.wikimedia.org/wiki/File:Campaign_Overview_page.png
  • 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
  • Wireframe: https://meta.wikimedia.org/wiki/File:Campaign_Programs_tab.png
  • Works like the Programs list on the "Find Programs" page, except only shows programs for that campaign, with additional buttons to create a new program or remove specific programs

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 ?