Editor campaigns/Technical design

This document presents the technical design of the Editor campaigns project. The most significant decision we've taken in this regard is to try to use domain-driven design. This approach is justified by the expectation that the domain will get more complex quickly. We've also created some general facilities to encapsulate persistence management.

Use cases and stories
Here's a use case diagram based on the user stories: Here are additional possible use cases and stories, most involving more advanced functionality:
 * Campaign organizers, participants and others want to study and compare campaigns using a variety of metrics. They might:
 * Create automatic text analysis of articles and link it to campaigns to compare their results. (Campaign results could be compared in terms of content persistence, for example, or the types of discourse on related Talk or Flow pages.)
 * Describe campaign participant networks. See, for example, this study of Twitter networks.
 * Link data about campaigns to data from other sources, including Wikidata.
 * Find campaigns by the Wikidata categories or Geotags of the articles they work on.
 * Place a campaign's activities on a timeline together with events described in Wikidata. (For example: visualize edits by a project about the Ukraine alongside major events in the recent protest movement there.)
 * Campaign organizers and participants want to organize their work in steps (i.e., as workflows) according to the requirements of a specific campaign or type of campaign, and link those workflows to UI elements.
 * Campaign organizers and participants want a variety UXs and data points for different types of campaign.
 * Users want flexible, productive, fun and easy-to-use tools for working and hanging out on Wikipedia in groups.

Persistence layer
(just mention briefly and refer to RFC)

UI (tentative)
(include here opt-in message as well as some ideas for future UI)