I was introduced to open source by my husband, a long-term Unix/Linux user. When he encouraged me to attend the Triangle Linux Users Group (TriLUG), a local meetup in the Raleigh, NC, area, I was quite intimidated, as I was one of a handful of women in attendance. But the more I learned about open source, the more intrigued I became.
As a quality engineer (QE), it was challenging to comprehend what impact I could have in open source. I had to expand my own understanding to realize that contributing to open source does not only mean code contributions and that QE brings a lot of value by providing feedback, testing, reporting, and verifying fixes. Any way someone can contribute to a project makes the project that much better.
As a beginner Fedora user, I went from being nervous about breaking it, to trying new features, to realizing that if I can break it, I can fix it, too. Writing a bug report for a project felt like I was part of a huge movement.
Becoming an open source contributor
Spacewalk was the first project that I was part of from its creation. Spacewalk was Red Hat Satellite's upstream community project, and I was one of the first to ensure quality. Later, my focus shifted to the Pulp project (Pulp is a platform for managing content repositories), where I initially was the only QE working on the project. As the project took off, user adoption increased, and quality became of utmost importance.
The Pulp team practices the agile methodology for development and depends on continuous integration and delivery to do time-based releases. We integrated QE into the project, and test automation, implementing CI/CD systems, running tests, and reporting issues became the QE team's responsibility. We provide information about the existing test suites, which contain the automated tests, test cases that are to be automated, and documentation on how to contribute to the test suites.
Encouraging users to contribute to the testing efforts ensures that, as the software evolves, it doesn't break the functionalities users rely on. Understanding the open source onion model reinforced the significance of a healthy and sustainable community that includes users, bug reporters, QE, and developers.
Migrating to management
As an open source enthusiast, it was easy for me to transition my management style to the open management philosophy, which fosters transparency, inclusivity, adaptability, and collaboration. As an open manager, one of my primary goals is to engage and empower associates to be their best. It is easy to adopt this philosophy when you understand the open source values.
- By being transparent, I help create the context for the team and the "why." This is a building block in creating trust.
- Being consciously inclusive is another value that I regard highly. Making sure everyone in the team is included and everyone's voice is heard is extremely important for individual and organizational growth.
- In an environment that is constantly evolving and where innovation is key, being nimble and adaptable is of utmost importance. Encouraging associates' growth mindset and continuous learning helps foster these traits.
- For effective collaboration, I believe we need an environment where there is trust, open communication, and respect.
By paying attention to these values, an open manager can create an environment that is inclusive, treats others with respect, and encourages everyone to support each other. These open management practices give me the framework and guidance to increase employee engagement.
Comments are closed.