automation -> code change management, campaigns (rename, refresh content)
Created by: sqs
Since we first published documentation about the private beta "automation" (aka "a8n") feature, we've learned a ton from customers about their requirements for this feature and how to describe it. The problem remains the same (it is painful to make large-scale code changes for refactors, fixes, migrations, and updates), but:
Name change
- Do not use the term "automation" (or "a8n") anymore (unless telling someone about the name change :).
- The use case will now be "code change management".
- The feature name will now be "[code change] campaigns". The product UI and API will just use the term
campaigns
(except in prose that is essentially marketing material, such as a hypothetical onboarding flow).
There are several overlapping reasons for this rename:
- "Campaigns" has precedent and sounds natural. Most customers that have (or planned to build) a similar internal tool independently chose to use the term "campaign". Of all people I've spoken with (including people to whom this whole idea is new), none have found the term "campaign" confusing.
- "Code change management" is, likewise, an intuitive description of the use case. "Change management" is an existing thing inside big companies.
- Why not just call the use case "code change campaigns"? Because that conflates the solution with the problem. Customers don't think of themselves having a "code change campaign problem", but they do think of themselves as having a "code change management" problem. This is analogous to the distinction between "code review" (the use case) and "pull request" (the solution).
- The term "automation" has negative and misleading connotations. When people hear the word "automation", it can imply negative things that are not relevant, such as "this feature will automate away our work and we will lose our jobs" or "robots will start changing our code in bad ways" or "setting up the right automation will be a huge up-front investment".
- Calling it "automation" makes it sound more complicated than needed (and than what customers find valuable). Just giving devs a way to script the creation of many changesets (or even just to track a set of related changesets) is valuable, but that does not really involve "automation" in the way most people would interpret it.
- Remove unnecessary nouns/concepts in the product. If we call the feature "automation", we still need to choose a noun for the unit/record in the product (UI and API). I.e.,
createAutomation
would be weird, because "automation" just sounds awkward in English when used in that way, and it's not really descriptive/accurate. The most natural noun is "campaigns". So we need to introduce the term/concept "campaign" anyway. - Chance of ubiquity. "Code change management" and "campaign" have much better chances to become well-defined, commonly known, unambiguous terms among developers. "Automation" is more general and already means things in the context of software engineering.
Refresh content: Also, the content describing campaigns has been refreshed so that it reflects our current understanding of customer requirements/priorities and what has worked well to explain the feature and the value it provides.