What is important for the name of our event standard?

[erkist]

We said in a recent meeting that we should do some thinking on the name of our event standard during the summer, and to focus the thinking a bit we could start stating some desired attributes of the name we want.

First, here is some input from the meeting June 7th, where we said that the name should:

1. Be related to our topic, e.g. continuous delivery (or supply chain)
2. Provide a nice "brand name"
3. Should represent the disruption we want to bring

And that he name shouldn't:

1. Bind us to any organization or group (e.g. Events SIG)
2. Bind us to any underlying transport or protocol (e.g. CloudEvents)

See https://hackmd.io/xjK5ujQbTHSaEZjoY28b8g#Meeting-June-7th for examples of proposed names.

What are your criteria for a good name?

[erkist]

I have some wishes for the chosen name:

1. It is pronounceable (either as a word or as an abbreviation of at most three letters) (e.g. Signal or CDF is fine, SPDX and Sgehgre is a but much)
2. It is available (i.e. it doesn't already mean something else in our domain, or something negative in any other domain)
3. It is spelt as it sounds (not super important when most communication is written, so it is not a strong wish)

[TracyRagan]

My thoughts -
We should think about 2 names, one that defines the Event "movement" and another that names a standard 'listener." For the "movement" we should be super specific about what we are doing. Events in CI/CD does that but it is not an attractive name -sort of boring.

When deciding on a name for the "movement," we might want to align it to something that people already know, making it easier for them to understand what we are doing. For example:

• GitOps > EventOps, StateOps,
• event-driven architecture > event-driven delivery
• cloudevents > CDEvents, DeliveryEvents

Or we address the problem in the name:
Decoupled CD

For the name of the 'listener' that we might eventually deliver, we can get more creative (Argo, Jenkins, Ortelius, Flux, Keptn).

We should be thinking about creating a new paradigm and that paradigm's name should reflect what it is and does. Then we have fun with the listener name that the CDF is creating.

[m-linner-ericsson]

Looking at the suggestion for names in the protocol https://docs.google.com/spreadsheets/d/14Q9X_330YNGK1Naq22TN0iA2q1mVSSXIusGysCGmcVU/edit there are some directions which we might want to take a stand on:

• Should the name reflect what the protocol does? E.g. CICD Cloudevents (Continuous Integration Continuous Delivery Cloudevents)
• Do we want to include Lifecycle in the event name? E.g. OLP (Open Lifecycle Orchestration), LEAP (Lifecycle Events and Analytics Protocol), SPELL (Standardized Protocol for Event Lifecycle)

[TracyRagan]

So here are my suggestions for naming -

CDEvents - For the 'general' protocol, I still like CDEvents. Super easy to understand. I worked on the concept of adding 'lifecycle' into the name, but since we are part of the CD Foundation, it seems we should continue with CD vs. Lifecycle.

Evie - I spent a good part of the day thinking about our 'listener' project. While I realize that the listener may go beyond just 'listening' it is its main function. I thought about other projects like Argo, Jenkins for example and their brand. I came up with a suggestion to our Project name for our listener by thinking about 'robots.' This led me to name it 'Evie' or 'EV.' Giving this a female name also aligns with the diversity efforts the CD Foundation is committed to. Evie's image could be a female image, listening to headphones. Here is a prototype:

I particularly like the simplicity in the name Evie - we have a fairly complex project, so giving it a simple name is important, and fits into other requirements that have been defined about the name.