docs(CI Ops): CIops -> CI Ops

[lloydchang]

Spell this as CI Ops. Reason: CIops reads like Clops, which caused me to look up what Clops (CLOPS) means. After not finding the acronym CLOPS, I realized that I misread CIops as Clops. By changing the spelling from CIops to CI Ops, this mitigates the risks of other people misreading too.

For example, do you read the following as CIops or Clops?

https://user-images.githubusercontent.com/1329685/121631216-81843480-ca33-11eb-98a5-66eb9c7a75a4.png
is a screenshot of
https://github.com/open-gitops/documents/blob/main/PRINCIPLES.md#principle-3-notes

I misread the above as Clops instead of CIops.

[todaywasawesome]

Agreed.

[scottrigby]

Interesting. This seems like a simple formatting change for clarity, so I'm not opposed in theory. I don't think "CIOps" is an industry-standard term, so not sure there's a canonical way of spelling it.

However, do a search for "ciops" vs "ci ops" (or "ci-ops"):

• https://www.google.com/search?q=ciops Contains articles referring to what we mean (Operations driven by Continuous Integration)
• https://www.google.com/search?q=%22ci+ops%22 Contains mostly articles about "Cost Index Operations"

I'd like to hear @cdavisafc to weigh in on this one as well. Beyond the above I don't have a strong opinion.

[lloydchang]

Please advise.

1. What: @scottrigby Any feedback after your conversation with @cdavisafc?
2. How: Should I create a new pull request for "CI Ops" because "CIOps" moved from PRINCIPLES.md to GLOSSARY.md?
3. Why: I want to tie up the loose end here from "CIOps" -> "CI Ops" then focus our time on CO (Continuous Operations) agenda as @cdavisafc summarized:

Git plays a central role, effectively drawing Continuous Delivery (CD) into the CO agenda, and that whole thing is what we call GitOps.

in https://www.linkedin.com/pulse/gitops-fan-here-cornelia-davis/

Thank you @scottrigby @cdavisafc @todaywasawesome for your time and take care 🙂

[scottrigby]

@lloydchang replies to #8 (comment):

1. No, the spelling CIops – as opposed to CI Ops vs CI-Ops – hasn't been prioritized. So far no one else expressed a strong opinion on this one. I don't have a strong opinion, only tried to find some non-subjective data in docs(CI Ops): CIops -> CI Ops #8 (review) from quick internet searches, which seems to lean toward keeping this as-is. I honestly don't know how to contribute to a decision on the spelling here except by checking personal opinion with data, or getting more feedback from the working group. Would you want to add this as a topic to the agenda for the next Working Group meeting to get more perspectives? Could you possibly join that meeting to ask?
2. I think given the call to action on RC2 draft 🎈  #22, you are right to discuss this as you did there: RC2 draft 🎈  #22 (review). I just linked folks from your comment there to this discussion here for more context.
3. Would you please explain in what way you'd like to address the term "Continuous Operations (CO)" in the GitOps Principles? Can you also describe why the spelling of CIops would be a blocker to whatever that is? My pragmatic feedback on this one is we have a goal of an initial full 1.0.0 release of the principles by KubeCon NA (in a few weeks), which is scheduled unless there is consensus on any blockers to that goal. I'm thinking this would not be a blocker because AFAIK this term hasn't come up once in the principles committee discussions or any async github discussion over the past 6 months. Unless it's considered a blocker, this one seems to me to be something more likely to be addressed in a later version after 1.0.0. What do you think?

[lloydchang]

@scottrigby I don't view CIOps as a blocker at all. Since CIops is status quo, and it's never come up in the past 6 months, then let's just leave it as-is. This is such a trivial priority that I am closing this PR 🙂

Separately, regarding Continuous Operations (CO) — CO doesn't need to be in the PRINCIPLES.md, but I feel CO should be referenced in the BEST-PRACTICES.md at some point in the future, long after 1.0.0. While CO is less well known than either CI or CD, CO deserves one mention within open-gitops/documents.

Coincidentally, I just listed two examples of Git playing a central role in CO immediately below https://github.com/open-gitops/documents/pull/22/files#r718090778

A third example of Git playing central role in CO is semver range we discussed at https://github.com/open-gitops/documents/pull/22/files#r718101001 in use by Flux v2 Image Automation Controller and its predecessor in Flux v1.

I feel the real power of GitOps happens with CO 24/7/365 round-the-clock, converging declared state with actual state, and beyond.

Just thinking aloud: Maybe BEST-PRACTICES.md can reference vendor-neutral examples of CO in comparison to vendor-specific examples of CO described at https://www.weave.works/product/gitops-enterprise/