This proposal got a basic agreement and is being implemented at
https://www.mediawiki.org/wiki/QA/Weekly_goals
A rough start is expected in the first iteration of the four areas but we hope to have improvements every week.
Get involved!
Development teams: your proposals for testing & bug management weekly goals are welcome.
On 01/16/2013 02:25 PM, Quim Gil wrote:
There are ongoing separate discussions about the best way to organize testing sprints and bug days. The more we talk and the more we delay the beginning of continuous activities the more I believe the solution is common for both:
Smaller activities and more frequent. Each one of them less ambitious but more precise. Not requiring by default the involvement of developer teams. Especially not requiring the involvement of WMF dev teams.
Of course we want to work together with development teams! But just not wait for them. They tend to be busy, willing and at the same time unwilling (a problem we need to solve but not necessarily before starting a routine of testing and bug management activities. If a dev team (WMF or not) wants to have dedicated testing and bug management activities we will give them the top priority.
Imagine this wheel:
Week 1: manual testing (Chris)
Week 2: fresh bugs (Andre)
Week 3: browser testing (Ċ½eljko)
Week 4: rotten bugs (Valerie)
All the better if there is certain correlation between testing and bugs activities, but no problem if there is none.
From the point of view of the week coordinators this is how a cycle would look like:
Week 1: decide the goal of the next activity.
Weeks 2-3: preparing documentation, recruiting participants.
Week 4: DIY activities start. Support via IRC & mailing list. Group sprint on Wed/Thu DIY activities continue.
Week 4+1: Evaluation of results. Goal of the next activity....
During the group sprints there would be secondary DIY tasks for those happy to participate but not fond of the main goal of the week.
If one group needs more than one activity per month they can start overflowing the following week, resulting in simultaneous testing & bugs activities.
Compared to the current situation, this wheel looks powerful and at the same time relatively easy to set up. There will plenty of things to improve and fine tune, but probably none of them will require to stop the wheel.
What do you think?