Blog: OpenGitOps 1.0

[scottrigby]

Hey @todaywasawesome thanks for starting this. We already talked about collaborating on this, since I wrote up the recap for App Delivery TAG. Here's a PR to make this process more transparent, and so others can comment/collab too ❤️

[todaywasawesome]

@scottrigby @lloydchang @murillodigital Updated this PR with a blog post. I'll work on getting the image together in the meantime. I'd love to post this ASAP. Take a look at let me know what you think.

[lloydchang]

Suggested change

	There’s so much more on the horizon and we need your help! [Get involved](https://opengitops.dev/get-involved)! We’d love more participation to build GitOps Blueprints, GitOps Whitepapers, plan GitOps events, and help with the direction of the Open GitOps projects.
	There’s so much more on the horizon and we need your help! [Get involved](https://opengitops.dev/get-involved)! We’d love more participation to build GitOps Blueprints, GitOps Green Papers, plan GitOps events, and help with the direction of the Open GitOps project.

See line 65 re: green papers.

Coincidentally, blue-green deployments is a terminology in software engineering. If we need a colorful mnemonic, then GitOps Blueprints, GitOps Green Papers, and blue-green deployments can be combined toward meaningful outcomes.

[lloydchang]

Suggested change

	Second, “GitOps Whitepapers” is a place to explore ideas around implementing the GitOps principles. For example, what if your SCM system becomes unavailable? When is it ok to “break glass” and start making manual changes? GitOps Whitepapers are meant to be a space where the community can share these ideas and document them.
	Second, “GitOps Green papers” is a place to explore ideas around implementing the GitOps principles. For example, what if your SCM system becomes unavailable? When is it ok to “break glass” and start making manual changes? GitOps Green papers are meant to be a space where the community can share these ideas and document them.

The description sounds more like green papers than whitepapers.

According to https://en.wikipedia.org/wiki/White_paper

By contrast, green papers, which are issued much more frequently, are more open-ended. Also known as consultation documents, green papers may merely propose a strategy to implement in the details of other legislation, or they may set out proposals on which the government wishes to obtain public views and opinion.

If App Delivery TAG GWG is a vendor in business-to-business marketing, then whitepaper would make more sense. However, App Delivery TAG GWG behaves more like a regulatory government body in the context of conformance. Hence the suggestion to use green papers.

[todaywasawesome]

Oh interesting, I've never heard of green papers before!

White papers are a way the government can present policy preferences before it introduces legislation. Publishing a white paper tests public opinion on controversial policy issues and helps the government gauge its probable impact.

This sounds pretty close to what we're going for with these. Places people can bring policy preferences. I don't know though, what do you think @scottrigby @murillodigital ?

[lloydchang]

@todaywasawesome @scottrigby @murillodigital One reason I suggest green papers is because @todaywasawesome wrote "to explore ideas" which aligns with how green papers are more open-ended for public consultation.

For example:

• Know your green paper on marriages in South Africa at http://www.dha.gov.za/index.php/notices/1449-know-your-green-paper-on-marriages-in-south-africa

• May 2021: Green paper on marriages in South Africa at https://www.gov.za/sites/default/files/gcis_document/202105/44529gon398.pdf

• Green Papers are documents published by the European Commission to stimulate discussion on given topics at European level at https://eur-lex.europa.eu/summary/glossary/green_paper.html

• January 2021: Green Paper on Ageing: Fostering solidarity and responsibility between generations at https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52021DC0050

WDYT? Thank you!

[scottrigby]

I personally think this is super interesting. Let's just discuss as a larger group. Can move this idea to a GitHub discussion, and also add to the next meeting agenda, with a goal of getting more feedback into that discussion. that way this blog won't be held up on those details. Does that sound good?

[lloydchang]

I requested changes. Thank you @todaywasawesome @murillodigital @scottrigby

[scottrigby]

@todaywasawesome I'm on this today – reviewing/contributing, etc.

First of all, I love this 🔥 We've been discussing this in-depth leading up to the 1.0 release, and said we want this info somewhere, and a blog post is a great place for it IMO. One note is that I think we should clarify that the GitOps documents are at 1.0, which currently includes both the principles and glossary items they link to, which are versioned together (on that note this post should link to the v1.0.0 tag, or equally good to the release-v1.0.0 branch, instead of main when we do).

I like the direction of this focused just on the 1.0 release. I wonder if it might not be good to also recap GitOpsCon, and highlight the release of the principles as a major but not only focus of this blog? Alternatively, we could do GitOpsCon/KubeCon recap as a separate post, and link the two.

A quick note on the convo above about blueprints, white papers, green papers, etc… my gut feeling is I kind of like this terminology, personally. It's catchy. But we haven't really settled on this as a group, right? As a group, we know we have planned to build upon these principles with best practices, case studies, specific integrations, a GitOps landscape, and other things. The principles release will also now allow agreeing on certification criteria, conformance requirements (and possibly levels, etc).

I agree it's good to end this blog post on a call to action, or at least something to look forward to after the 1.0 release of GitOps documents (the "why you should care" of this). But perhaps the call to action should be letting folks know more generally what the WG has already been planning on working on next, and how to get involved. We could then take a little more time deciding on naming and announcing these initiatives in a separate blog post?

[scottrigby]

Hey @todaywasawesome I had done a rebase against upstream/main and --force-with-lease push to remove the extraneous commits from this PR that are already in main. I was then about to make some formatting fixes after that without force pushing. Do you want me to do that again? Did you add anything different in your last force push?

[todaywasawesome]

@lloydchang @scottrigby I've removed the announcement parts and just encourage people to get involved.
@scottrigby sure, feel free to rebase, I don't think it's needed because it seems like it'll merge just fine but don't let me stop you.

With those things removed, shall we publish?

[scottrigby]

OK awesome merging!