Update the main README

[jeff-mccoy]

Need to cleanup the README and asciinema to use the latest version of zarf.

[jeff-mccoy]

Any update on this @btlghrants?

[btlghrants]

Almost. I've got a bunch of notes lined up & sanity-checked with @RothAndrew yesterday, so you can expect to see some movement on this today. That commit on #85 yesterday was a (small) step toward making some of the introductory docs less annoying to write. :)

I'll post a general layout of what I plan on doing to this issue here first though, so let me know if anything looks dumb / lacking. Happy to roll in anything you think should be supplemented.

[jeff-mccoy]

Copy thanks, along with docs would really like to see updated asciicinema for everything.

[btlghrants]

K. So, based upon my last couple of days getting comfortable with this project, I want to reorganize the docs around user roles: User or Zarf vs. Developer of Zarf.

I'd like to cover (at a minimum), in the "User" section:

• A "Getting Started" Doom-in-a-box game example - to show how "quick & easy" it is to get a minimal install going (and cuz Doom has lots of gee-whiz appeal).

• A "Secure Registry" page that intros/links to Registry1 & covers all the stuff someone would need to know to log into Harbor (in order to build non-trivial zarf packages).

• A "Disconnected GitOps" example - to give evaluators an easy way to play with our "killer case" (which is air-gapped, gitops clusters).

And, in the "Developer" section:

• Project setup/environment details - so we can, 1) be clear about all the prereqs (for build vs. just to run), vagrant, virtualbox, go versions, etc., but 2) not have to show it to the general "I just want to use zarf" kinda person.

• A "How to contribute" page - to cover the nuts & bolts of getting code into Zarf (e.g. signed commits, PRs w/ at least 1 reviewer, etc.).

I'm imagining most of this stuff as being linked-to from an introductory, "This is the point of Zarf"-style main README. I'm sure that more topics'll present themselves as I work through the updates but... that all sound useful?

I'm open to suggestions on other breakouts but I think this should (minimally) cover our 2 main user types and allow us to make some less-lengthy / page-jumpy usage instructions.

I expect I'll start with a buncha README updates but I'd love to make it a static site + GitHub Pages kinda thing either if you guys think the readability'd be a win & it'd be worth the add'l overhead.

[btlghrants]

Put all the main README update stuff out into #98 so we can merge it--I'll get the subREADME stuff in another PR.

[RothAndrew]

@btlghrants to close this issue and create several small issues that continue the work to flesh out the docs, loosely based on having one issue per "Coming Soon!" entry