Automation Tracking Issue 3.9: Going from RFC 28 to RFC 20

[mrnugget]

RFCs for context

• RFC 28: https://docs.google.com/document/d/1J9uGV4v6Y2SHC2iPWDMCzppSLqZtNTEWQLV8qxzNgzs/edit#
• RFC 20: https://docs.google.com/document/d/1UY9B_kLlwRtYj-fuv7XZS1-Mu99Czx9Ojm7sgEmoQIA/edit
• RFC 20 Appendix: https://docs.google.com/document/d/1fbO0SdqL50aotmVCkUvOmtsgn2aUV-RphINwLcT9vuY/edit#
• RFC 20 API: https://docs.google.com/document/d/1bf4jfFczn7Vi2m0ecy-8P8Mzv2UX5AAA4OAvg6wNMQU/edit

Deferred to 3.10

Note: These items are not prioritized yet

• Only "update" a changeset when it actually changed.
• Support Bitbucket Server changeset events
  • Add ChangesetEvents for Bitbucket Server (requires fetching /activities for Bitbucket Server changesets)
  • Incorporate Bitbucket Server ChangesetEvents into burndown chart API
  • Bitbucket Server webhooks (RFC)
• Show the combined diff of all changesets in a campaign (nice to have: with diff/commit comments shown inline)
  • See schema defined in Add GraphQL schema for campaign combined diff #5850
• Making "adding changesets" work if changesets have been created before. See comment and this issue
• Rename campaign.{name,description} to campaign.{title,body}
• Shows status of all changesets in the campaign and allow querying/filtering by the following fields
  • Show "open/merged/closed"
  • Show "review status"
  • Show "commit statuses"
  • Show "labels"
  • Filtering fields via GraphQL API
    • Filter by "open/merged/closed"
    • Filter by "commit statuses"
    • Filter by "review status"
    • Filter by "labels"
• Show the combined event timeline from all changesets
  • Show comments
  • Show approvals
• Show the set of participants involved in the campaign

Planned Work

Improve syncing after RFC 20 implementation

• Create an enterprise version of repo-updater where changesets are synced. (https://github.com/sourcegraph/sourcegraph/pull/5755)
• "Solve" rate limiting/polling/multiple resources (not just single pull request) etc. for syncing
  • GitHub webhooks a8n: Upsert changeset events from GitHub webhooks #5913

Support another codehost

The idea is to "go wide" to validate the assumptions we made while adding support for GitHub and GitHub pull requests. See this Slack message for context.

• Add Bitbucket Server Support (PR: https://github.com/sourcegraph/sourcegraph/pull/5768)

Extend Campaign/Changeset management

• Allow editing of the campaign title and description (https://github.com/sourcegraph/sourcegraph/pull/5698
  • API: https://github.com/sourcegraph/sourcegraph/pull/5698
• A campaign can be deleted from the UI
  • API: https://github.com/sourcegraph/sourcegraph/pull/5701
• Frontend: Pagination campaigns (Use FilteredConnection for campaigns list #5925) / changesets (@felixfbecker)
• Show a burndown chart over time of the count of changesets in the campaign that are closed, merged, open, open+unmerged+ready
  • Think of GraphQL schema @felixfbecker Add GraphQL schema for burndown schema #5847
  • Add ChangesetEvents for GitHub a8n: Persist GitHub ChangesetEvents to database #5834
  • Add burndown chart GraphQL API a8n: Implement GraphQL API for Burndown Chart #5895
  • Add frontend component to make use of burndown chart API

Questions

• Question for Quinn: what problem does the event timeline solve?
• What things can already be worked on in the frontend, while backend implements APIs? For example: extension API
• Deletion of external services:
  • Do we need to care about thisyet?
  • What should happen to changesets when an external service is deleted?
  • Changeset deletion: when do we delete changesets that are not connected a campaign?

[sqs]

Question for Quinn: what problem does the event timeline solve?

• The primary purpose of the event timeline is to inform the campaign author how they can help push the campaign along. The timeline accomplishes this by showing reviews (approve/comment/request-changes) and comments on all threads in the campaign. The campaign author will scan the timeline for comments that they can help answer.
• The secondary purpose of the event timeline is to give campaign authors confidence that Sourcegraph is tracking the statuses of all of the threads (and is up-to-date). This directly addresses the customer feedback from https://app.hubspot.com/contacts/2762526/company/608245740 that confidence in our syncing is crucial.

Deletion of external services:

Do we need to care about this yet? What should happen to threads when an external service is deleted?

It is OK if (deleting an external services) causes (all changesets associated with that external service's repositories) to be removed from campaigns. (Parentheses to group noun phrases added for clarity.) To be clear for anyone external reading this, this does NOT mean Sourcegraph will delete the changesets on your code host, only their record in the Sourcegraph DB.

Changeset deletion: when do we delete changesets that are not connected a campaign?

(I think this is an impl question not for me.)

[tsenart]

Dear all,

This is your release captain speaking. 🚂🚂🚂

Branch cut for the 3.9 release is scheduled for tomorrow at 10:00 CEST.

Is this issue / PR going to make it in time? Please change the milestone accordingly.
When in doubt, reach out!

Thank you