Day 3 typos

.vscode/ltex.dictionary.en-US.txt

@@ -82,3 +82,14 @@ traefik
 Vercel
 Isovalent
 CNIs
+Ivanti
+envs
+CoreDNS
+Istio
+buildpacks
+Buildpack
+SBOM
+Tekton
+KPack
+Multiarch
+Tanzu

content/day3/01_stop_leaing_dns.md

@@ -11,8 +11,8 @@ A talk by Google and Ivanti.
 
 ## Background
 
-* RBAC is ther to limit information access and control
+* RBAC is there to limit information access and control
-* RBAC can be used to avoid interfearance in shared envs
+* RBAC can be used to avoid interference in shared envs
 * DNS is not really applicable when it comes to RBAC
 
 ### DNS in Kubernetes
@@ -26,11 +26,11 @@ A talk by Google and Ivanti.
 
 * Specially for smaller, high growth companies with infinite VC money
 * Just give everyone their own cluster -> Problem solved
-* Smaller (<1000) typicly use many small clusters
+* Smaller (<1000) typically use many small clusters
 
 ### Shared Clusters
 
-* Becomes imporetant when cost is a question and engineers don't have any platform knowledge
+* Becomes important when cost is a question and engineers don't have any platform knowledge
 * A dedicated kube team can optimize both hardware and deliver updates fast -> Increased productivity by utilizing specialists
 * Problem: Noisy neighbors by leaky DNS
 
@@ -45,14 +45,14 @@ A talk by Google and Ivanti.
 ### Leak mechanics
 
 * Leaks are based on the `<service>.<nemspace>.<svc>.cluster.local` pattern
-* You can also just reverse looku the entire service CIDR
+* You can also just reverse lookup the entire service CIDR
 * SRV records get created for each service including the service ports
 
 ## Fix the leak
 
 ### CoreDNS Firewall Plugin
 
-* External plugin provided by the coredns team
+* External plugin provided by the CoreDNS team
 * Expression engine built-in with support for external policy engines
 
 ```mermaid
@@ -67,19 +67,19 @@ flowchart LR
 
 ### Demo
 
-* Firwall rule that only allows queries from the same namespace, kube-system or default
+* Firewall rule that only allows queries from the same namespace, `kube-system` or `default`
 * Every other cross-namespace request gets blocked
-* Same SVC requests from before now return NXDOMAIN
+* Same SVC requests from before now return `NXDOMAIN`
 
 ### Why is this a plugin and not default?
 
 * Requires `pods verified` mode -> Puts the watch on pods and only returns a query result if the pod actually exists
-* Puts a watch on all pods -> higher API load and coredns mem usage
+* Puts a watch on all pods -> higher API load and CoreDNS memory usage
 * Potential race conditions with initial lookups in larger clusters -> Alternative is to fail open (not really secure)
 
 ### Per tenant DNS
 
-* Just run a cporedns instance for each tenant
+* Just run a CoreDNS instance for each tenant
-* Use a mutating webhook to inject the right dns into each pod
+* Use a mutating webhook to inject the right DNS into each pod
 * Pro: No more pods verified -> Aka no more constant watch
-* Limitation: Platform services still need a central coredns
+* Limitation: Platform services still need a central CoreDNS

content/day3/02_poduct_market_misfit

@@ -6,7 +6,7 @@ tags:
   - dx
 ---
 
-Mitch from aviatrix -a former software engineer who has now switched over to product managment.
+Mitch from aviatrix -a former software engineer who has now switched over to product management.
 
 ## Opening Thesis
 
@@ -14,19 +14,19 @@ Opening with the Atari 2600 E.T. game as very bad fit sample.
 Thesis: Missing user empathy
 
 * A very hard game aimed at children without the will to trail and error
-* Other aspect: Some of the devalopers were pulled together from throughout the company -> No passion needed
+* Other aspect: Some devalopers were pulled together from throughout the company -> No passion needed
 
 ### Another sample
 
-* Idea: SCADA system with sensors that can be moved and the current location get's tracked via iPad.
+* Idea: SCADA system with sensors that can be moved, and the current location gets tracked via iPad.
-* Result: Nobody used the iPad app - only the desktop webapp
+* Result: Nobody used the iPad app - only the desktop Web-app
-* Problem: Sensor get's moved, location not updated, the measurements for the wrong location get reported until update
+* Problem: Sensor gets moved, location not updated, the measurements for the wrong location get reported until update
 * Source: Moving a sensor is a pretty involved process including high pressure aka no priority for iPad
-* Empathy loss: Different working endvironments result in drastic work experience missmatch
+* Empathy loss: Different working environments result in drastic work experience mismatch
 
 ## The source
 
-* Idea: A software engineer writes software, that someone else has to use, not themselfes
+* Idea: A software engineer writes software, that someone else has to use, not themselves
 * Problem: Distance between user and dev is high and their perspectives differ heavily
 
 ## User empathy
@@ -37,43 +37,43 @@ Thesis: Missing user empathy
 ## Stories from Istio
 
 * Classic implementation: Sidecar Proxy
-* Question: Can the same value be provided without a sidecar anywhers
+* Question: Can the same value be provided without a sidecar anywhere
 * Answer: Ambient mode -> split into l4 (proxy per node) and l7 (no sharing)
-* Problem: After alpha release ther was a lack of exitement and feedback
+* Problem: After alpha release there was a lack of excitement and feedback
 * Result: Twitter Space event for feedback
 
 ### Ideas and feedback
 
 * Idea: Sidecar is somewhat magical
-* Feedback: Sidecars are a pain, but after integrating istio can be automated -> a problem gets solved, that already had a solution
+* Feedback: Sidecars are a pain, but after integrating Istio can be automated -> a problem gets solved, that already had a solution
 * Result: Highly overvalued the pain of sidecars
-* Idea: Building istio into a platform sounds easy
+* Idea: Building Istio into a platform sounds easy
 * Feedback: The platform has to be changed for the new ambient mode -> High time investment while engineers are hard
 * Result: The cost of platform changes was highly undervalued
 * Idea: Sidecar compute sound expensive and networking itself pretty cheap
-* Feedback: Many users have multi-region clusters -> Egress is whery expoenive
+* Feedback: Many users have multi-region clusters -> Egress is very expensive
 * Result: The relation between compute and egress cost was pretty much swapped
 
 ### What now?
 
-* Ambient is the right solution for new users (fresh service mesehes)
+* Ambient is the right solution for new users (fresh service meshes)
-* Existing users probaly won't upgrade
+* Existing users probably won't upgrade
-* Result: They will move forward with ambient mdoe
+* Result: They will move forward with ambient mode
 
-## So what did we lern
+## So what did we learn
 
 ### Basic questions
 
 * Who are my intended users?
-* What exites/worries them?
+* What excites/worries them?
 * What do they find easy/hard?
-* What is ther biggest expense and what is inexpensive?
+* What is the biggest expense and what is inexpensive?
 
 ### How to get better empathy
 
 1. Shared perspective comes from proximity
    1. Where they are
-   2. What they do -> Dogfood everything related to the platform (not just your own products)
+   2. What they do -> Dog food everything related to the platform (not just your own products)
 2. Never stop listening
    1. Even if you love your product
    2. Especially if you love your product
@@ -81,4 +81,4 @@ Thesis: Missing user empathy
 
 ### Takeaways
 
-* Don't ship a puzzlebox (landscape) but a picture (this integrates with this and that)
+* Don't ship a puzzle box (landscape) but a picture (this integrates with this and that)

content/day3/03_oss_business_value.md

@@ -6,25 +6,25 @@ tags:
   - business
 ---
 
-Bob a Program Manager at Google and Kubernetes steering commitee member with a bunch of contributor and maintainer experience.
+Bob a Program Manager at Google and Kubernetes steering committee member with a bunch of contributor and maintainer experience.
 The value should be rated even higher than the pure business value.
 
 ## Baseline
 
-* A öarge chunk of CNCF contrinbutors and maintainers (95%) are company affiliated
+* A large chunk of CNCF contributors and maintainers (95%) are company affiliated
-* Most (50%) of the people contributed in professional an personal time )(and 30 only on work time)
+* Most (50%) of the people contributed in professional personal time (and 30 only on work time)
 * Explaining business value can be very complex
 * Base question: What does this contribute to the business
 
 ## Data enablement
 
 * Problem: Insufficient data (data collection is often an afterthought)
-* Example used: Random CNCF slection
+* Example used: Random CNCF selection
-  * 50% of issues are labed consistentöy
+  * 50% of issues are labeled consistently
   * 17% of projects label PRs
   * 58% of projects use milestones
 * Labels provide: Context, Prioritization, Scope, State
-* Milestones enable: Filtering outside of daterange
+* Milestones enable: Filtering outside date range
 * Sample queries:
   * How many features have been in milestone XY?
   * How many bugs have been fixed in this version?
@@ -37,36 +37,36 @@ The value should be rated even higher than the pure business value.
   * Thought of as overhead
   * Project is too small
 * Tools:
-  * Actions/Pipelines for autolabel, copy label sync labels
+  * Actions/Pipelines for auto-label, copy label sync labels
-  * Prow: The label system for kubernetes projects
+  * Prow: The label system for Kubernetes projects
-* People with high project but low code knowlege can triage -> Make them feel recognized
+* People with high project, but low code knowledge can triage -> Make them feel recognized
 
 ### Conclusions
 
 * Consistent labels & milestones are critical for state analysis
-* Data is the evidence needed in messaging for leadershiü
+* Data is the evidence needed in messaging for leadership
-* Recruting triage-specific people and using automations streamlines the process
+* Recruiting triage-specific people and using automations streamlines the process
 
 ## Communication
 
 ### Personas
 
 * OSS enthusiast: Knows the ecosystem and project with a knack for discussions and deep dives
-* Maintainer;: A enthusiast that is tired, unter pressure and most of the time a one-man show that would prefer doint thechnical stuff
+* Maintainer;: A enthusiast that is tired, under pressure and most of the time a one-man show that would prefer doing technical stuff
-* CXO: Focus on ressources, health, ROI
+* CXO: Focus on resources, health, ROI
-* Product manager: Get the best project, user friendly
+* Product manager: Get the best project, user-friendly
-* Leads: Employees should meet KPIs, with slightly better techn understanding
+* Leads: Employees should meet KPIs, with slightly better tech understanding
 * End user: How can tools/features help me
 
 ### Growth limits
 
 * Main questions:
-  * What is theis project/feature
+  * What is this project/feature
   * Where is the roadmap
   * What parts of the project are at risk?
 * Problem: Wording
 
-### Ways of surfcing information
+### Ways of surfacing information
 
 * Regular project reports/blog posts
 * Roadmap on website
@@ -76,8 +76,8 @@ The value should be rated even higher than the pure business value.
 
 * What are we getting out? (How fast are bugs getting fixed)
 * What is the criticality of the project?
-* How much time is spent on maintainance?
+* How much time is spent on maintenance?
 
 ## Conclusion
 
-* Ther is significant unrealized valze in open source
+* There is significant unrealized value in open source

content/day3/04_towards_great_docs.md

@@ -10,7 +10,7 @@ A talk about the backstage documentation audit and what makes a good documentati
 
 ## Opening
 
-* 2012 the year of the mayan calendar and the mainstream success of memes
+* 2012 the year of the Maya calendar and the mainstream success of memes
 * The classic meme RTFM -> Classic manuals were pretty long
 * 2024: Manuals have become documentation (hopefully with better contents)
 
@@ -18,9 +18,9 @@ A talk about the backstage documentation audit and what makes a good documentati
 
 ### What is documentation
 
-* Docs (the raw descriptions, qucikstart and how-to)
+* Docs (the raw descriptions, quick-start and how-to)
-* Website (the first impression - what does this do, why would i need it)
+* Website (the first impression - what does this do, why would I need it)
-* REAMDE (the github way of website + docs)
+* README (the GitHub way of website + docs)
 * CONTRIBUTING (Is this a one-man show)
 * Issues
 * Meta docs (how do we orchestrate things)
@@ -30,10 +30,10 @@ A talk about the backstage documentation audit and what makes a good documentati
 * Who needs this documentation?
   * New users -> Optimize for minimum context
   * Experienced users
-  * User roles (Admins, end users, ...) -> Seperate into different pages (Get started based in your role)
+  * User roles (Admins, end users, ...) -> Separate into different pages (Get started based in your role)
 * What do we need to enable with this documentation?
   * Prove value fast -> Why this project?
-  * Educate on fundemental aspects
+  * Educate on fundamental aspects
   * Showcase features/uses cases
   * Hands-on enablement -> Tutorials, guides, step-by-step
 
@@ -43,24 +43,24 @@ A talk about the backstage documentation audit and what makes a good documentati
 * Documented scheduled contributor meetings
 * Getting started guides for new contributors
 * Project governance
-  * Who is gonna own it?
+  * Who is going to own it?
   * What will happen to my PR?
   * Who maintains features?
 
 ### Website
 
-* Single source for all pages (one repo that includes landing, docs, api and so on) -> Easier to contribute
+* Single source for all pages (one repo that includes landing, docs, API and so on) -> Easier to contribute
 * Usability (especially on mobile)
 * Social proof and case studies -> Develop trust
 * SEO (actually get found) and analytics (detect how documentation is used and where people leave)
 * Plan website maintenance
 
-### What is great documetnation
+### What is great documentation
 
-* Project docs helps users according to their needs -> Low question to answer latency
+* Project docs help users according to their needs -> Low question to answer latency
-* Contributor docs enables contributions in a predictable manner -> Don't leave "when will this be reviewed/mered" questions open
+* Contributor docs enables contributions predictably -> Don't leave "when will this be reviewed/merged" questions open
-* Website proves why anyone should invest time in this projects?
+* Website proves why anyone should invest time in these projects?
-* All documetnation is connected and up to date
+* All documentation is connected and up to date
 
 ## General best practices
 
@@ -72,11 +72,11 @@ A talk about the backstage documentation audit and what makes a good documentati
 
 ## Examples
 
-* Opentelemetry: Split by role (dev, ops)
+* OpenTelemetry: Split by role (dev, ops)
 * Prometheus:
-  * New user conent in intro (concept) and getting started (practice)
+  * New user content in intro (concept) and getting started (practice)
-  * Hierarchie includes concepts, key features and guides/tutorials
+  * Hierarchies includes concepts, key features and guides/tutorials
 
 ## Q&A
 
-* Every last wednesday in the month is a cncf echnical writers meetin (cncf slack -> techdocs)
+* Every last Wednesday in the month is a CNCF technical writers meeting (CNCF slack -> `#techdocs`)

content/day3/05_buildpacks.md

@@ -9,11 +9,11 @@ tags:
 A talk by Broadcom and Bloomberg (both related to buildpacks.io).
 And a very full talk at that.
 
-## Baselinbe
+## Baseline
 
 * CN Buildpack provides the spec for buildpacks with a couple of different implementations
-* Pack CLI with builder (collection of buildopacks - for example ppaketo or heroku)
+* Pack CLI with builder (collection of Buildpacks - for example Paketo or Heroku)
-* Output images follow oci -> Just run them on docker/podman/kubernetes
+* Output images follow OCI -> Just run them on docker/Podman/Kubernetes
 * Built images are `production application images` (small attack surface, SBOM, non-root, reproducible)
 
 ## Scaling
@@ -47,7 +47,7 @@ flowchart LR
 
 * Goal: Just a simple docker full that auto-detects the right architecture
 * Needed: Pack, Lifecycle, Buildpacks, Build images, builders, registry
-* Current state: There is an RFC to handle image index creation with changes to buildpack creation
+* Current state: There is an RFC to handle image index creation with changes to Buildpack creation
   * New folder structure for binaries
   * Update config files to include targets
 * The user impact is minimal, because the builder abstracts everything away
@@ -56,5 +56,5 @@ flowchart LR
 
 * kpack is slsa.dev v3 compliant (party hard)
 * 5 years of production
-* scaling up to tanzu/heroku/gcp levels
+* scaling up to Tanzu/Heroku/GCP levels
 * Multiarch is being worked on

content/day3/_index.md

@@ -4,4 +4,4 @@ title: Day 3
 weight: 3
 ---
 
-Spent most of the early day with headache therefor talk notes only start at noon.
+Spent most of the early day with headache therefore talk notes only start at noon.