This is a DRAFT, it is only a draft.
The Quality Engineering Team intake process gave me some heartburn. What makes this maddening is that the QE team members and leadership are all top-notch! As I figure things out it's a great group to work with.
Another issue I'm still working through is the use of Bodhi, Koji, and a slew of other items. I think these are great tools but either I missed the memo on how to use them and what to use them for, or maybe there's no memo yet?
What I'd like to do is develop a skills and talents matrix, or DNA of the parts of QE so that an potential volunteer could get a clear and educational grasp of what each part does, what skills they need to have to start, and what the growth path is. There is no requirement to be a super-duper kernel programmer to start! You do need to get an introduction to the tools and have an honest understanding of the time requirements though.
In the end our intro pages should help the potential volunteer through a self-examination process. If they know what they know and see where they want to go, we can provide them tools to follow their own path.
How do you see your self?
- Desktop User wanting to really grow your Linux skills
- Operating Systems Student
- RHC[T|E|A] Aspirant
- Someone who develops applications on Linux/Unix
- Developer for Fedora
- Software Tester
- INCOSE Systems Engineer (CSEP) developing real world skills
Our Quality Assurance (QA) teams let you contribute with your current skills and learn more as you work with us. Do a quick self-assessment and think about what skills you want to develop. That will help you find the right entry point and ensure you're getting the right amount of challenge and development. Once you're comitted to a team one of the members will help guide you through the initial learning curve. They will also seek your feedback on how the team's communications are and what sorts of improvments you might suggest.
When you consider the Quality Engineer path, here are some things to be aware that you're committing to:
- Current languages tools are in Python and C.
- Fedora/Linux technologies like Kickstart, RPM, Yum, and Git are key.
- 1 Hour IRC meeting Wednesdays at 11:00 EST, useful to attend.
- Documentation and Communications skills are important but can be in your personal learning plan.
What would the path look like?
Your personal entry point onto the QA team really depends on what skills you want to use and what you want to learn. Let's look at a volunteer who wants to work on her Developer skills with the BugZappers. After listening on #fedora-bugzappers for a bit our awesome volunteer wants to get started and asks for suggestions. She's not used Bugzilla before so an experienced team member suggests a quick read of their Getting Started page would help and then she can jump into the Triage effort.
For a while this is great fun. Then the intrepid BugZapper moves up the skill ladder to actually fixing bugs! Not only has the bug count gone down because duplicates are eliminated and developers get to focus on actual issues, but our volunteer learns how the system really works and starts helping make improvements.
Armed with some field experience and ready to push the problem further up the stream the volunteer starts writing test cases and floating them over to the Installation and Feature Testing squads. Nothing like stopping bugs before they actually bite users! In addition to bringing a little sanity to the most recent release our rockstar volunteer has started building friendships within the community. Her /nick is recognized and her advice is listened to.
One fine day our wizend volunteer realizes her '66 Mustang could really use that 5.8L small block racing performance engine but volunteering just doesn't pay the shipping fees like it used to. Being particularly bright she checks out a Software Testing Certification, easily meets the requirements, studies for a test and passes. Anyone could do that, but now our volunteer knocks on some job doors with a certification, lots of real-world experience, and the personal recommendations from people who actually know her work! Having her name splashed all over the internet as a Quality Engineer probably helps, too.
And soon our now well paid Quality Engineer spends a latte and some chat time on #fedora-bugzappers when some newbie pipes up and says "I'd like to help, how do I get started?"
Fedora BugZappers can start with Triage skills and assume greater responsibility as C and Python skills grow. Minimal knowledge of Bugzilla is required for initial work, as well as the ability to communicate via e-mail lists and IRC. This would be a great place to develop your understanding of the Linux kernel and application development.
Our tool sets are primarily written in Python 2.5. Besides work on Anaconda, Snake, various Kickstart tests, Cobbler, and whatever else we can think up to make life easier for users, we'll push your Python and Linux automation skills up a notch.
Care to take on a sub-set of the distrobution and make sure it's component parts work well? Find the right scope for your time and interests and then invest in working with the related teams to make sure things still work after each upgrade. Another option is to join in the Test Days with other Fedora QA team members. For example: QA/Test_Days/2009-02-05
When the bleeding edge gets a bit staid for you, help the Rawhide spin maintainers check the frequent builds. There is no promise anything will work, but your trouble-shooting and pre-boot environment expertise will be put to the test. When you're ready to be the bleeding edge, contact Will Woods User:wwoods for information on accessing the Release Candidates.
Once Rawhide has gotten something close to stable it's time to make sure the installation process works on all current architectures. For this you need to have a build box that can be worked on and rebuilt without impacting your business or personal computing needs. QA:Fedora_11_Install_Results_Template
Fedora provides for a wide variety of users who have an even wider variety of tool needs. As a Stream Liasion you'll keep yourself aware of what your user community needs and wants while staying abreast of changes in upcoming releases. For example, if the Ham Radio community uses Tools X and Y on Desktop Z 90% of the time you know what needs to be tested first.