[Podman] Re: Help Wanted: Podman Documentation contributors, suggestions, and more....

Hi Tom, this request really speaks to me. Sadly, I'm super busy these days with different kinds of training. But I found a way to connect the homework in my Coursera Product Management certification course [1] with your interest for more tasks. I'm curious if you or others think this might be helpful. For instance, maybe someone already feels that is a good representation of their situation, or they know someone like that, or some of my assumptions are totally wrong because... etc. Context: I believe that all activities in regards to documentation, training and customer acquisition should have a primary focus on the users and their actual stories. So before writing suggestions for how to improve the documentation, I would first like to know some Podman power users (or Docker power users, or virsh power users), what they do with the provided tooling, how their activities connect to each other, why they are doing things one way or another, and which problems they are facing while doing so. At the same time my product management training also discusses how product managers should understand and approach users. The main work item for product managers is the User Story. That is an Issue, Bugzilla, or Jira ticket where the description is formatted in a certain way [2]: ``` As a <role> I can <capability>, so that <receive benefit> ``` To be able to write stories, first I have to understand about whom I write them. The <role> part is called <persona> in our training. That means, a representative example of a certain group of users. And we learn to understand them by making assumptions about what they Think, Feel, See and Do, and then we go out and test these assumptions by actually talking to people who fit this profile. As one homework we should brainstorm, how users for a scenario of our choice would look like, and I chose "distributed container workloads too small for Openshift". The following is my homework response: ``` Brainstorming Personas for distributed container workloads too small for Openshift installations: - Jon the smarthome maker. He likes to tinker around in his house. He also likes to use open source. It's a tat more work to set up. But he doesn't mind. He likes that he can understand some of the parts that go into his system, though. And he likes that usually these components come with a community of dedicated hobbyists and professionals, just like himself. - Sven the racing simulator builder. Sven loves cars. Sven loves racing. But not in the real world, where gas is expensive and you could actually get hurt. He prefers simulators. And he knows there are a lot of simulator fans out there, willing to spend a premium for a real-world feeling. So he buys car parts from his trusted scrapyard connections, cuts off the parts that won't fit into a living room, then replaces the dashboard components with raspberry pis, puts movable arms with motors around the driver's seat, and then connects everything to gaming PCs. As a last step he takes his library of actuator controllers and sensor analysing software and rolls them out to the seat controller, dashboard components, and connects them to the gaming PC/hub. Once he's done and played around with it for some time he gets bored. So he sells it in the racing simulator community and starts his next simulator. - Tom, the factory maintenance team lead. He found through coincidence on Youtube one day that most of the machines in his factory actually are able to be configured and analysed via normal ethernet ports, USB, and CAN bus (the last one is probably technically wrong, but there will be something similar). So he got this idea that instead of having one of his guys walking through the whole hall once every hour and still missing the red, blinking light on Machine3 before it crashes, he puts Raspberry Pis next to all his machines, figures out how to connect them to the machines, how to read out the data streams, and send them to his office desk PC in the supervisor office from 2005. There he uses Prometheus to analyse when certain limits in the machine's data are reached, and then he can send someone to a machine that specifically needs maintenance. Persona of Jon the Smarthome Maker: Jon thinks: - Using technology to solve his daily problems is good. - Having insight into how this software is used and build is good. - Building software from independent components is good. - Interacting with a healthy community around these components is good. Jon sees: - Many companies in the hardware store advertise their product's smart capabilities. - Many companies offer iphone and windows apps to manage their devices. - Almost no company offers to manage other company's devices as well. - Almost no company can explain how the data is exchanged, stored, and kept safe from external influences through the management apps. - Many products offer some form of open standard to connect to. Jon feels: - He shouldn't buy an iPhone to change is bathroom light from green to pink. - He feels overwhelmed with the amount of individual, proprietary solutions to part of his smart home dream. - He feels disappointed that many smart devices only add features to traditional parts of his house which he doesn't really need. - He feels disappointed that many smart devices don't consider how he wants to use them together (e.g. light, heating, A/C and roller blinds). - He feels sad that he can't share this hobby with his brother, who's a lawyer with no technical background, due to lack of standardization and automation Jon Does: - Buys smart devices that have open standards and can be connected to open source hubs. - builds small hubs with raspberry pis that collect all the data from one part of the home. - builds a central hub in the garage, at first with a raspi, and thinks about upgrading it to a NUC later. - manually rolls out the software stacks on linux with docker, because that is what the youtube videos recommended him to do - configures the network connections manually - has no plan for upgrades - ignores firewall and security upgrade related planning - if a sensor, actuator, room-hub or the central hub die, he will manually rebuild a new one and just accept the outage in usability and data collection - ignores backup considerations - when running into an issue during deployment he reaches out to the component's community via mailing list or slack channel - in one python component a configuration value was not accepted in the form described in the documentation, therefore he sent a patch - in another project the usb driver was not able to read the sensor data from the cable; after trying to get an *alternative* project to work he gave up without reporting the problem to anybody - in the community where he provided a patch the other members got really excited and asked him to present his setup in their monthly call; he really wants to, but can't find the time prepare some powerpoint slides ``` Best, Erik [1] My training path: https://www.coursera.org/specializations/uva-darden-digital-product-manag... [2] https://en.wikipedia.org/wiki/User_story On Fri, 14 May 2021 at 02:15, Tom Sweeney <tom.sweeney(a)redhat.com&gt; wrote: