You may not be aware of it, but Plone has a QA Team. We’ve gone in fits and starts over the last several years, but have never really gained traction. I’m pleased to announce that Elizabeth Leddy has been suckered into agreed to lead the effort! We’ve been in some rather lengthy discussions about what my hopes for the team are and are starting to come to the point of making things happen.
Task 1: Test! Test! Test!
As release manager, I’ve been approaching the position with the basic motto of “Don’t ship crap”. It’s simple, but effective. That basically translates to two things:
- Make sure that new bugs get fixed.
- Make sure we aren’t reintroducing old bugs into new releases.
That soft-release phase is one of the areas I really want the QA Team getting involved. Having a team I can trust to put each release – be it alpha, beta, or final – through its paces, is absolutely key to my maintaining my sanity and to you not winding up with a broken Plone install. With active testing, we can reduce the time it takes to make releases, which reduces the time it takes to get bug fixes to you. As things stand now, much of the time involved in making minor releases (4.1, 4.2, etc) is my waiting around until I feel confident that it’s been used by enough people to be considered stable.
But, as Liz and I have talked, I’ve realized that this is actually the lesser of the two main tasks…
Task 2: Tickets, please!
Plone has a ticket tracker and as of this post, it has 1,177 open tickets. Many are either outdated, nonsensical or impossible to fix. Far worse, many are just plain forgotten.When it comes to an open source project, with its inherent limitations to both resources and attention, tickets follow two basic rules:
- If there’s no ticket, it’s effectively not a bug.
- If the developers don’t see it, it’s not going to get fixed.
So we want to do two things here. First, we’ll be making it much easier for everyone to add tickets. If you take a look at Plone’s new ticket form, you’ll notice it’s dramatically simpler. No login required, no choosing which component is the culprit, just tell us what went wrong and how we can contact you to follow up.
Secondly, we want to make it easier for the developers to find what’s broken, and here’s where the QA team comes in again. Now, when that new ticket comes in, it will be the QA Team’s duty to confirm the bug and properly categorize it. It feels completely underwhelming to boil it down to those two little tasks, but aggregated across the whole of our bug tracker, it leads to an enormous change in our ability to fix bugs in Plone. As a developer, knowing that a bug is both real and valid is a big first step in making a fix. As release manager, being able to point the developers at a set of important bugs each week is an organizational zealot’s dream come true.
Plone’s regular Tune-Up events are a great way to get involved with Plone development. With a steady influx of quality bug reports they become excellent opportunity for anyone to take on tasks that match their skill level, a mechanism for mentorship, oh, and a chance to fix your Plone too.
And so, getting started…
Tomorrow’s (March 16, 2012) Plone Tune-Up will focus on weeding out Plone’s bug tracker. All experience and skill levels are welcomed. We’re looking to close outdated tickets, confirm reported bugs, and generally make it easier for everyone to make Plone awesome. I hope you can join us.