Campaigns-Mini-Roadmap Q2 2020

[mrnugget]

Finish campaigns for a public non-beta release

• IMPORTANT: Fix all Bugs, Documentation and Needs mprovement in the the collected user feedback Run Campaigns user tests with Sourcegraph colleagues #9912
  • Highest priority is the flow for new users. We need to make that as smooth as possible.
• IMPORTANT: Make campaigns accessible to non-site-admins - RFC 157
  • Christina: "letting anyone on a sourcegraph instance create a draft campaign, but only admins can publish as PRs"
  • Allow non-site-admins to create campaigns and publish changesets
  • Allow non-site-admins to create campaigns, but only with draft changesets
• IMPORTANT: Incorporate repository permissions into campaigns - RFC 157
  • Users can only see the changesets for repositories they have access to
  • Users can only create patches ("draft changesets") for repositories they have access to
  • Users can only publish changesets for repositories they have access to
• Design spike to simplify campaigns creation flow (primary goal: reducing amount of text) update docs for new campaign flow #10921
• Investigate whether we can enable campaigns for all users by default on all instances (incl. existing ones) or if we need to require site admin opt-in per-instance - outcome: we can enable this for all users by default because actions will use the user's own token

Make it easier to get started with and show off Campaigns

• Allow users to see campaigns on sourcegraph.com.
• Allow drafting of changesets for unsupported code hosts Allow previewing of changesets for unsupported code hosts #11193
• Integrate into the search workflow so that users can create campaigns directly from the search results page.

Find, document and market use cases of campaigns

What we want is to be able to publicly communicate a list of possible use cases (see this tweet that Quinn shared for an example).

• We need more examples in the documentation and ready-to-run campaign actions whose value is immediately visible.
• We need to incorporate those examples into the web UI and the CLI.

[christinaforney]

This is alluded to in the above, but I think we should make it more clear: Adding campaign creation permissions. This way a user could create campaigns, but does not have to be an admin. There should be options:

• Allow all users to create campaigns
• Grant create campaign permissions to users or orgs (groups of users)

This bundles nicely with the above "Let anyone on a sourcegraph instance create a draft campaign", but only someone with create campaign permissions can publish the PRs.

[mrnugget]

@christinaforney I moved your comment-suggestion up, but, just to be clear, we need to differentiate between "Create campaigns (as drafts)" and "Publish changesets" as permissions. I think what you mean with "Allow all users to create campaigns" is "Allow users to create campaigns (as drafts) AND publish changesets", right?

[sqs]

I removed 2 things that I think are unneeded:

Allow deleting of single patch in PatchSet (before creating campaign, or in draft mode).

I don't think this is needed (if I'm missing something, please speak up). There are also 2 problems with it:

• It can create confusion and complexity with updates. Support I delete a patch for repo ABC from the patchset and then create the campaign. Then I update the campaign by running the same action that produced the original patchset. It's very likely that I'd either (a) expect my deletion to "persist" for the life of the campaign even when I update it with a new patchset; or (b) even if I don't expect that, it's very likely I'd forget to re-delete the patch from the new patchset.
• Making patchsets mutable in the UI is likely to cause confusion because it introduces another thing that users need to know about and change. "What am I editing, the campaign or the patchset?" It would be as though you could push a Git branch to GitHub, but then you could make a PR with only a portion of the diff.

Keep changesets up to date when the base branch changes.

I don't think we can do this well until we support server-side execution. There are 2 cases:

1. Case 1: The campaign changeset has no merge conflicts with the new base branch. Then in this case, there's little benefit to us doing work to keep the changeset up to date, since it wouldn't actually affect the merged result. GitHub and other code hosts will let you merge it as-is (or, if strict branch protection is applied, will let you "Update branch" manually on their web UIs, and since there's no conflict, this would be simple).
2. Case 2: There are merge conflicts. In this case, we'd need to re-execute the action to compute the new patch. But we can't do this automatically since we don't support server-side execution yet.

[sqs]

I reviewed the mini-roadmap and made a few changes. It looks good to me now.

• I have not prioritized Run Campaigns user tests with Sourcegraph colleagues #9912. Would this be helpful? My sense is that it's a lot of small things, and we'll fix them all soon anyway, so prioritization would not be helpful.
• Even after campaigns graduates from public beta, we should still plan for a short (~1month?) period of time during which usage is free (but we make it clear it will be charged for). This lets us postpone the work of tracking campaign usage, enforcing licensing/payment, etc.
• I've started RFC 157: Campaigns authorization model and will have a complete draft by Monday morning CEST.

[mrnugget]

Allow deleting of single patch in PatchSet (before creating campaign, or in draft mode).

I don't think this is needed (if I'm missing something, please speak up).

Agree with the problems you mentioned and I agree that we should probably defer on this until now. The reason why I think it could be valuable is that it's often easier to have a "large" scopeQuery and produce a patchset and then delete the ones you don't want vs. rerunning the action with a modified scopeQuery to ignore a repository.

Keep changesets up to date when the base branch changes.

I don't think we can do this well until we support server-side execution. There are 2 cases:

Agree. I was hesitant about leaving it on (I think I de-prioritized it for exactly that reason).

* I have not prioritized #9912. Would this be helpful? My sense is that it's a lot of small things, and we'll fix them all soon anyway, so prioritization would not be helpful.

I don't think we need to explicitly prioritize them on a roadmap, but we should fix the reported bugs and high-value-low-effort problems with a high priority.

I reviewed the mini-roadmap and made a few changes. It looks good to me now.

Looks good to me, thanks!

I've started RFC 157: Campaigns authorization model and will have a complete draft by Monday morning CEST.

Thank you! 🙏

[mrnugget]

Closing this because RFC157 and the new workflow in #10921 make a lot of this here invalid or fix it.