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.
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.