@Ragesoss: So for this task our plan is to go with a very simple initial implementation of a "program template". A program template will consist of nothing but a block of text (stored with the campaign info) that gets prefilled in the Program creation interface. Does this sound good to you?

In T148804#2743175, @kaldari wrote:

@Ragesoss: So for this task our plan is to go with a very simple initial implementation of a "program template". A program template will consist of nothing but a block of text (stored with the campaign info) that gets prefilled in the Program creation interface. Does this sound good to you?

So this would mean instead of having a template_course_id pointing to a course (aka program), we'd have a text(65535) description field on Campaign that gets copied over when they click "Create program" from the Campaign overview page.

@kaldari @MusikAnimal I think we'll be better off going the route Leon and I sketched out earlier with linking the Campaign to a specific template course. I think it will not be any more difficult to implement, and will mean less rework later. Having just a 'program template' field that we copy to the CourseCreator is a much less flexible approach than using the course cloning tools that we have, and it would make Campaigns useless for Wiki Ed as a jumping off point for users to create specific kinds of courses/programs.

@Ragesoss How would that work, from the campaign organizer's point of view?

This is how I understand the use case:

The campaign organizer creates a new campaign, with a description of the campaign and the dates. Then the campaign organizer writes a description that will be used for programs created under that campaign. When the program organizer creates a program, that description goes into the field.

Why would the campaign organizer create an extra "template program"? What other fields would need to be filled in? How would we mark the "template program" as different from an actual program?

@DannyH It depends on what kind of campaign you are talking about, but for things besides edit-a-thons where there is a program timeline that stretches over a longer period of time, and/or assigned trainings, then you will want more flexibility than just copying over a single text field. You also want to copy over the program type, and the rest of the appropriate data. Right now there's not much differentiation between a BasicCourse (the P&E default) and an Editathon, but there will be at some point in the not-too-distant future. And when you add education program courses into the mix, you absolutely need to have a whole program to clone, not just a description field. One easily-within-reach use case would be a Wiki-Loves-X event. These happen over a modest time period and have distinct stages, and we'd want to include Timeline functionality for that.

The campaign organizer would create a template program, first of all, so anyone could easily see what a program in that campaign is supposed to look like (including the organizer themself).

It may also be the case that a campaign is organized on the basis of a single successful event. So in that case, the template program could be an actual program that happened.

We could mark template programs with their own campaign.

Hmm, it sounds like we'll need to circle back with Amanda and talk about use cases. If you've got more use cases in mind and a different workflow, then we need to have it written down, and make new wireframes based on that. We shouldn't make backend decisions based on a workflow that we haven't planned for. Does that work for you?

Oh, I just realized we're actually meeting with Amanda and some program organizers tomorrow morning anyway. :) We can figure it out then.

@Danny_B I don't think the way I described will be harder to implement, and again, I think it takes us down a road that we'll almost certainly need to backtrack on. We should not expect users to organize a campaign without going through the process of setting up and using a program page... especially since they will be the first point of contact for users running programs in their campaign.

Happy to circle back with @Abit to talk about use cases more, but I think even if the only use case that matters at this point for P&E Dashboard is a stripped down one that is basically for Edit-a-thons only, we can still find ways to accommodate that workflow with a data model built on associating campaigns with template programs... and doing it that way will mean we can avoid starting down a big new configuration fork between the two versions.

@DannyH: on the wireframe front, I think the wireframes you made previously will work for this. We can still pull the description field from the template program, so for a person trying to create a program in a campaign, the flow and design is the same (except we probably want to add a link to the page of the template program).

It's the campaign set process where this would be slightly different than what you initially sketched out, but that's going to be a little different UI-wise anyway because of the Rails vs. React issues we talked through recently.

@Ragesoss: Most of what you said sounds reasonable. Our main concern is that it won't be intuitive for campaign facilitators (especially ones that are setting up new and relatively simple campaigns), or worse, that it will actually cause confusion.

In order to understand the other use cases better, could you or Leon list the metadata that can be associated with a program that would potentially be useful for templating? So far you've mentioned description, program type, and Timeline functionality (although I'm not sure what that is). What other metadata do you foresee wanting to clone?

@kaldari: Timeline is a pretty rich bunch of functionality that lets users specify which activities (and which assigned trainings) take place at which point in time. See https://dashboard.wikiedu.org/courses/Florida_International_University/Basic_Ideas_of_Sociology_%28Fall_2016%29/timeline

The course cloning workflow is designing to duplicate all this stuff for a new course (for example, when the same instructor teaches it again in a different term) and makes sense also as the basis for creating new arbitrary programs within an arbitrary campaign.

Whether or not the timeline tab shows up on a program depends on the Type. Currently on ClassroomProgramType has it enabled, but we'll almost certainly want to create a new type — possibly more than one — for the use cases of the global education programs.

I understand the concern about making things complicated for campaign facilitators, but I think that can be solved with documentation aimed at those users— which we'll need anyway, even with simplest campaign creation workflow possible. I also think we shouldn't make too many assumptions about the needs of such campaign facilitators before we have a few actually actively coordinating campaigns.

Whether or not the timeline tab shows up on a program depends on the Type. Currently on ClassroomProgramType has it enabled, but we'll almost certainly want to create a new type — possibly more than one — for the use cases of the global education programs.

@Ragesoss: Perhaps whether a "program template" is a simple text field or an actual program should depend on whether it is a course (wikiedu) campaign or a program campaign. Thoughts?

but I think that can be solved with documentation aimed at those users

I have to disagree on this. No one reads documentation, especially if they are just a volunteer and don't have a lot of time to invest in learning the software. (This might be different for course instructors though.)

In T148804#2743570, @kaldari wrote:

Whether or not the timeline tab shows up on a program depends on the Type. Currently on ClassroomProgramType has it enabled, but we'll almost certainly want to create a new type — possibly more than one — for the use cases of the global education programs.

@Ragesoss: Perhaps whether a "program template" is a simple text field or an actual program should depend on whether it is a course (wikiedu) campaign or a program campaign. Thoughts?

That would work technically, but I think that introducing forked behavior here is not necessary, which is why I'm keen to avoid adding that bit of complexity. I think beyond the very very near term, the use cases of Wiki Ed and P&E align very closely for Campaigns-related functionality. I don't think we'll want to shortchange the flexibility of this tool for the kinds of power users that many of the likely campaign organizers are, in exchange for a very minor streamlining of the simplest use case.

but I think that can be solved with documentation aimed at those users

I have to disagree on this. No one reads documentation, especially if they are just a volunteer and don't have a lot of time to invest in learning the software. (This might be different for course instructors though.)

No one reads wiki documentation, but what I had in mind is documentation built into the flow. In particular, a training module (a la https://dashboard.wikiedu.org/training/instructors/new-instructor-orientation) linked from the campaign creating/editing view would definitely get used. The kinds of folks who run campaigns are also more inclined to look for documentation than others — which is why we've seen both explicit requests and people creating their own, for P&E Dashboard.