Open source code traditionally finds quality through the initial code review process prior to to a commit, and also the "release often" policy of getting lots of hands on the code early.
But sometimes it can be beneficial to do some more structured QA (quality assurance work) even if it's done in a nontraditional manner.
I hope that through this session wo can talk about some current and possibile initiatives to improve the quality of Drupal's code. The metric that I use to define "quality code" in this area is the number of unknown critical bugs that are shipped with a product.
Drupal QA Team Vision
I think the following goals start a team vision:
- Every bug a known bug
- Every open bug a unique bug
- Every open bug either has a "simplified test case" or "needs more info"
These are all things that a QA team can help to do without doing any code. One of the meta-goals of the team is to provide a way for people who want to contribute, but lack coding skills, to find a valuable way to spend their time.
To support these efforts, I'd also like to create a tool that would support automated and manual testing of our software so that module developers can have a good idea of whether or not potential changes to their modules will break anything.
I believe that if we can get a testing system (see litmus) like into place, and organize a group of people for "Focused Drupal QA Days" to review pieces (string freeze, drupal core, popular modules, etc.) then we will greatly improve the quality of Drupal core and contrib.
So, the conversation will likely wander into testing systems and recommendations.
If you are interested in joining the team, learning what benefits such a team could provide, or just want to learn more about QA in general then this session is right for you.