Notes from Devops Discussion with Michael
===

## Meeting notes: Sam & Michael, Aug 6, 2019

> What do we want?

DevOps!

> When do we want it?

Now!

> where is HoloCentral now in terms of DevOps?

- whole team responsible, able to work together but also split off
- yegor able to jump right in
- Scrum, DoD, etc. worked really well
- Story-based standups, not person-based
- a lot of devops work has been centered around nix
- also testing

proposing nix based solutions as much as possible
nixify things "from the outside", looking at the insides you wouldn't need to know about nix

>

- - -

want to avoid overly prescriptive, rigid compliance-based Ops people, they need to listen to Devs
Devs need to be able to listen to customers, Ops needs to listen to Devs, empower Devs
Ops need to give enough options to Devs so they are not restricted, based on Devs' needs
hearing what they need right now, but also what they need down the road
clear paths, get out of the way

primary engineers for building traceable pipelines

a dev can't just do *whatever* they want, somebody has to account for arbitrary decisions that might be made.

don't just tell people "use nix". offer tools, environments, solutions. empower.
devops devs would be getting feedback from devs

- - -

take a step back, look at the operations side, ask ppl like yegor, duffy, maintainers of centralized services:
*what* are our operations requirements as a business?

e.g. we determined resources needed by Cloudflare, put into a spreadsheet

>

purpose, process, requirements
we know the purpose, could know more about process, need to understand requirements

devops person needs to know requirements, sits between ops and dev

spend more time inquiring into ops requirements, now and into the future

over time, are we planning for the separation of holochain and holo? should each have their own ops?

we could define operational requirements separately for each, but we can still share resources between each in the short term, i.e. Holo can sponsor Holochain

let devs propose things
let ops counterpropose
let iCongress review what is proposed

1. know ops reqs
2. know business reqs
3. know what customer needs
4. devs know what customer needs

^ whoever keeps all this in mind should be part of iCongress reviewal process

anyone can propose, but must pass review. iCongress should make the questions, criteria publicly known so people can make good proposals

Decision making process and the people involved