Enable contributions by separating data from backend code
Problem Statement
What is the problem?
Currently, both data and backend code for Zendesk (and other areas) maintained by Support Operations is in one place.
Why is this a problem?
Contributions from outside of the Support Operations team become difficult to manage, as there is a high risk of damage to the system itself. It also means that Support Operations need to intervene in changes that don't necessarily require Ops input (for example, changes to wording in a Trigger, or Macro).
Proposal
Move the data to new repos that can be maintained by Support (and others if desired). Initially speaking, Support Managers, but the maintainers could then decide process/workflows/etc. to determine how changes and the like to said repos would work.
Those repos would become submodules on the backend code projects.
Proof of Concept examples
- ZD Global Automations
- data is at https://gitlab.com/gitlab-com/support/zendesk-global/automations
- edits there are synced to the backend code via a git submodule
- ZD Global Triggers
- data is at https://gitlab.com/gitlab-com/support/zendesk-global/triggers
- edits there are synced to the backend code via a git submodule
NOTE These are proof of concept projects, they are not "live".
DRI
@dtragjasi will act as the DRI for this issue.
Required Resources
We'll need contributions from the wider Support Operations team to design, develop, test, implement and document the solution.
Specifically, we'll need @jcolyer for the development side of things.
Potential Roadblocks/Things to consider
Desired Outcome
What does success look like?
Success results in a world where Support Ops do not need to be involved in surface-level changes to Zendesk (i.e. changes to wording/phrasing in responses we send out), and also a world where the actual underlying configuration of our Zendesk instance is not impacted by changes made by other teams once the solution has been rolled out.
We should be in a position where all content-based changes can be managed by external teams if and when they need to make those changes, and all backend configuration changes to Zendesk that impact the way the system works are still managed by Support Ops.
We want to continue to drive and support our everyone can contribute mission statement and maintain a secure, flexible and efficiently running system.
How do we measure success?
Success can be measured by the amount of Issues and MR's that Support Ops need to be directly involved in once the solution has been rolled out. For example, we can make comparisons between the amount of macro MR's requiring Ops approval/involvement for a given period prior to the solution being rolled out versus how many required Ops aprroval/involvement after the solution has been rolled out. We can do these for each area that we separate data/content from backend configuration.
Where would future feedback go?
Feedback can be provided within the specific projects for each area we separate, for example - if there is feedback regarding making changes to Automations, that can be done here: https://gitlab.com/gitlab-com/support/zendesk-global/automations
Related Issues/MRs/Epics/Tickets
Original STM: #5693 (closed)