I started life as a historian with some disdain for technology. While studying Jewish communal structures in medieval Europe at the University of Chicago, I took a student job in a computer lab. This was an early machine learning endeavor, training the computer to analyze Pap smears. My job was to spend evenings in the computer lab, running backups, mounting disks and tapes, and changing the printer paper so the data scientists could work from home. We had no written procedures, so I started writing up instructions for the tasks I was performing. Our senior engineer pulled me aside and said that I was pretty good at that, and recommended I explore technical writing, and I was hooked.

I eventually landed at Bell Laboratories when they were attempting to make viable computer systems that ran the UNIX operating system. While working on standard system guides, I discovered the joy of writing about highly technical topics for a very technical audience. So, I led an effort to document the kernel interfaces and practices required to write device driver software. Later, I left Bell Labs to document a POSIX-compliant, real-time UNIX system at MODCOMP. After that, I joined SCO where I mostly developed content for the device driver development kit.

Once SCO faded, I spent several years at Trend Micro, researching and developing curriculum to train our support staff about the inner workings of their security software. I then moved on to other companies, documenting developer tools, platforms, and machine learning technologies. During those years, I became hooked on open source and the evolving documentation-as-code discipline. I was convinced that these philosophies are foundational to where the industry and the world at large need to go. From my historical studies, I admire the power of communities and know that innovation thrives when information flows freely.

CloudBees hired me in 2017 to work on training and documentation for Jenkins and CloudBees products. I was immediately impressed by the Jenkins community that welcomes everyone and works together tirelessly to improve both the software and the community.

Jenkins was an established project with a significant body of documentation when I started. Independent training organizations were offering classes that helped users navigate the information. I worked with these trainers, software engineers, and others to put together standard classes that everyone could share and enhance. As these efforts highlighted shortcomings in the documentation, we enhanced the documentation. One particularly interesting project was putting together a little seminar about how to secure Jenkins; the existing documentation covered the various available security features, but we did not have cohesive information about how to secure one’s Jenkins installation. The webinar was a success and then we used that information to enhance the security documentation.

The Jenkins community is a paradigm of what an open source community should be! It is an assembly of extraordinarily bright people who frequently discuss activities that grow and strengthen the community, in addition to improving the software and documentation. Even when the pressure is on and the hours are long it is always fun! When I first started with Jenkins, CloudBees staff was responsible for about 80% of the Jenkins contributions, and yet they rigorously ensured that decisions about Jenkins were discussed and implemented with the entire open-source community rather than just inside CloudBees.

Everything matters! It is wonderful when a community member creates a new plugin or implements some major feature for the product, but the amalgamation of smaller contributions is at least as important. People who realize that some documentation needs more information and add it, or correct a syntactical error in the prose. People testing a new build and notifying the community that everything worked well, or that they had problems. People who ask questions, people who answer questions, and people who discuss an underlying issue for the question are key components of the continuous improvement of the Jenkins ecosystem. The richness of Jenkins is the large community that cares about the project and does whatever it can to contribute to making Jenkins successful and impactful.

Get involved! Join community meetings, look for opportunities to contribute, and meet the people who are supporting Jenkins. If you follow a procedure in a document and see ways that the information could be more helpful, file a PR with the proposed change or file an issue that details the necessary changes. If you like to play around with new software, try to install and test a new build and report on your results.