Incidents that disrupt the service are not simply anomalies....disruptive events are weaknesses in your system being revealed because of a specific configuration of events. We then need to look at our incident management as a method for us to foremost reduce weakness and improve. How might we do that, and what do we need?

Slides for a talk on shell-scripting I gave to the awesome group Women in Linux on June 15, 2016.

I went over the basics of going from shell usage to encapsulating it into a script, then expanding it with variables to make a one-off script generally useful. Finally, I show how adding control structures and conditionals can add further sanity checking and usability to the scripts, because one day you will forget why you did that thing in that way.

Along the way we chatted about unix toolbox philosophy and how shell scripting extends that.

Makes the most sense if you are look at the corresponding Github files.

Here's a quick "trailer" slide deck for my OSCON 2016 talk. I'll be talking about contributing to Open Source from the viewpoint of the distractions and problems you'll face. There are many reasons to contribute to OSS, but so many ways and reasons to avoid it!

How do you circumvent these problems? Why is motivation is better than time management? What is YSAAS?

This talk answers these questions and many more, with humor and empathy and respect for contributors past , present, and those yet to contribute.

I hope I see you in Austin.

I spoke about contributing to Open Source from the viewpoint of the distractions and problems you'll face. There are many reasons to contribute to OSS, but so many ways and reasons (mostly internal) to avoid it!

How do you circumvent these problems? Why is motivation is better than time management? What is YSAAS?

This talk sought to answer these questions and many more, with humor and empathy and respect for contributors past , present, and those yet to contribute.

Here is a video of me presenting the talk.