Bug Squash Day

[enderandrew]

KDE has organized bug squash days.  They open an IRC channel, though the game as a chat system internally so that isn't necessary.  Then volunteers enter the channel and ask for directions.  People direct them to try to duplicate bug behavior so we can verify or close bugs.  Devs hang out, and when bugs are verified, they can work quickly and closely with testers by giving them patches to try.  That isn't as easy to do with an MMO where you'd have to reboot a server, push out patched clients, etc.  But everyone gets together and spends a day trying to close as many bugs as possible.

Maybe as a reward, the people who contribute can be given a small honorific in-game item, such as a certificate.

[Caarrie]

people can fix bugs any day they want, and are NEVER given anything for fixing a bug. it is very hard to organize days to fix bugs due to issues with how complex the code is. also planeshift does not accept patches from just anyone, the patch has to be tested and confirmed to fix the issue before it fixes it, by picking a day to fix bugs it would not help with this, it would slow it down if we got 100+ patches in one day that may not correctly fix any bug. If you wish to fix a bug put a patch on the bug tracker and a testing team will make sure it gets to the devs.

[enderandrew]

The majority of users for most projects aren't developers.  An organized bug squash day (many open-source projects use them, but KDE is very high visibility) is more to help with cleaning up your bug tracking system to verify and replicate bugs.  You'll find many bugs that have been overlooked for some time can either be closed, or updated with more pertinent information that helps move them towards resolution.  I know that you have a test team who is supposed to do that precisely, but it allows non-devs to contribute.  If there wasn't an organized event, many never would contribute.

Cleaning up your bug tracking system and closing bugs is a good thing.  Even if you are unsure if the idea has merit, it really doesn't hurt.  If your theoretical worst case scenario is that a bunch of people submit patches, how is that really bad to get new code contributions?  And while KDE users are probably more likely to be devs who will contribute actual code, and many can just turn around and recompile and test a patch on the spot, I don't expect you will get overloaded from patches from your users.

Bug squash days have been invaluable for other projects.  I think you should be open minded and try one and see how it goes.

[Caarrie]

the main issue is only devs can commit the fixes and each and EVERY dev is very busy otherwise the bugs would be fixed already, it would take double the time for someone to fix them and then a tester to confirm the fix and then a dev to confirm it was fixed correctly and commit it. Trust me on this project a bug fix day would not help us it would just give our devs even more work to do. Just ask the devs how much time they would have. Also please dont compare ps to other projects we dont do things the same way that other projects do things. Also as a staff member/tester I have spoken to the devs about this and the idea was not liked due to the amount of extra work it would add to the whole team.

also for most bugs confirmation by the testing team is the only way we can confirm bugs, please dont make suggestions about how to run things for this game unless you want to join the team. it is rude imo to say that the testing team is not doing a good enough job due to the number of bugs on the tracker, we do more work then you can even see.

[Mordraugion]

Calm down please no one has said anything about the Testing team not doing a good enough job and everyone is entitled to their opinions even if you dont agree.

I for one think its not a bad idea to have a bug squashing day, I know the devs are busy people but if it just cleared up some outdated unverified or no longer valid stuff it would help.

[Caarrie]

well considering that a dev has already told me they dont have time for this [the team as a whole] i dont see how doing it would help the game get more bugs fixed. also it takes a while to learn the code base to correctly fix any bug, if you want to fix bugs go ahead and apply for the team. The testing team also does review bugs as needed to see if they need to be closed, but having people comment they cant duplicate or it might be fixed in a bug does not help us much, as then we have to go test it again when we might already know it is not fixed due to changes in trunk.

[Dajoji]

I'm pretty sure there is a list of unverified bugs in the BT. Having a group of volunteers test to see if they can reproduce them is not a bad thing imo. Even if you don't end up fixing them after this bug day, at least you'll have more info to categorize them or close them so when a dev gets to it, they won't have to start from scratch.

It's the bugs we want to squash, not the initiatives (even if they need to be worked on).

[Caarrie]

lets try this, who in this community that has not already joined the staff, wants to help with confirming bugs or fixing them? If you wanted to do this day you would imo need atleast 20 people that know the code base to work with you not counting devs that would be needed to help. I dont see there being that many people interested in code that have not joined the team already that has time to spend a full day or longer trying to fix bugs.

[Rennaj]

 Me thinks this is a good Idea, no need to get your feathers ruffled, it was not a dig at you or anyone, just a genuine way of helping out. Mord and Dajoji Have the right outlook encourage not squish.

[Caarrie]

my point is if the devs have stated that they dont have time why push the issue? it can take hours of a devs time to test a patch and confirm it has no other issues then what it should fix. But sure it could be tested out, but i dont think it will get very far without backing of the whole dev team.

[Dajoji]

Say you got 5 unconfirmed bugs. Say you think those are related to linux users only. Then, get 5 linux users to see if they can reproduce it with the information available in the bug report. If they can, add whatever they discover to it, if anything to change its status to 'new'. If they can't reproduce it, close the bug and move the info to the bug related board until it can be confirmed (if that is the process).

After this day, you'll have more info on each bug and hopefully a cleaner database of bugs. Fixing them is another thing but if someone wants to help gather info, let them.

[Xillix Queen of Fools]

I think we'd need bug squashing month, and maybe we'll do that!

[enderandrew]

my point is if the devs have stated that they dont have time why push the issue? it can take hours of a devs time to test a patch and confirm it has no other issues then what it should fix. But sure it could be tested out, but i dont think it will get very far without backing of the whole dev team.

I think there is some miscommunication between us.

The way a typical bug squash goes, someone is in an IRC room directing end-users (and this can be someone from the Testing Team directing people) to try and replicate bugs.  They either verify the bug exists, and do there best to get more information on the bug to update the "task", or they find they can't verify the bug, and mark it closed.  All this is, is what the testing team already does, but you organize a community event to knock out a bunch of work quickly.  Having more information about a task/bug helps busy devs.  Closing erroneous bugs helps devs focus on real issues.

I can't imagine any scenario where this makes life more difficult for a team of developers.  Projects that use squash days credit them for helping with work load.

If the dev team is really that swamped at the moment, perhaps there should be a bit of a recruitment drive.

Then again you said perhaps I shouldn't make suggestions if I'm not on the team.  Are you saying community members shouldn't offer suggestions?  If that is really the case, then close down the forums and the feature request portion of your BugTracker, because it seems like you are providing avenues to solicit input.  To be perfectly honest, I am interested in joining the team and helping out in any capacity I can be it writing, rules design, bug testing, etc.  I could spend time trying to help recruit team members if you don't have time to recruit.  But I figure I should take some time playing the game and learning more before I attempt to contribute directly.

[Caarrie]

I think there is some miscommunication between us.

The way a typical bug squash goes, someone is in an IRC room directing end-users (and this can be someone from the Testing Team directing people) to try and replicate bugs.  They either verify the bug exists, and do there best to get more information on the bug to update the "task", or they find they can't verify the bug, and mark it closed.  All this is, is what the testing team already does, but you organize a community event to knock out a bunch of work quickly.  Having more information about a task/bug helps busy devs.  Closing erroneous bugs helps devs focus on real issues.

I can't imagine any scenario where this makes life more difficult for a team of developers.  Projects that use squash days credit them for helping with work load.

If the dev team is really that swamped at the moment, perhaps there should be a bit of a recruitment drive.

the development team is always looking for people, that does not mean they need a drive, the app is always open, but not everyone that starts in the process makes it to be on the staff. Also not everyone that applies has the skills or is in other departments.

when it comes to your drive for fixing bugs or even confirming, all bugs are confirmed on latest code so that would mean all that help you in your drive would need to build a client and server for us in testing, this is why we have a testing team that works very hard to do all these things.

Then again you said perhaps I shouldn't make suggestions if I'm not on the team.  Are you saying community members shouldn't offer suggestions?  If that is really the case, then close down the forums and the feature request portion of your BugTracker, because it seems like you are providing avenues to solicit input.  To be perfectly honest, I am interested in joining the team and helping out in any capacity I can be it writing, rules design, bug testing, etc.  I could spend time trying to help recruit team members if you don't have time to recruit.  But I figure I should take some time playing the game and learning more before I attempt to contribute directly.

no my point is you dont have a right to tell the devs/testers/staff where to put their time, we have ways to make suggestions but not to outright almost demand us to take time to do what you want, as in this project, the devs are too busy with rl to do it. We also have the option to accept or deny any request that players make, even requests that staff make are not always accepted. We also have no plans on closing the forum or the feature request portion of the tracker.

What i want you to consider is not asking others in the staff to change what they do to suit you, or what you want to do.

[enderandrew]

When I use phrases like "perhaps you should", I don't see how I'm making demands.

There are currently 532 incidents in the bug tracker marked as New or Unconfirmed.  I thought that might be an opportunity to help the team out by cleaning some of those up.

I spent a few hours reading through many of the incidents so that I wouldn't open duplicates, and to get an idea of known issues being worked on.  Even with the "Assigned" category, many seem to be simply sitting open with little information.  If people can get more information on those tasks, it might make it easier to eventually move those tasks to resolution.

I'm still not understanding your objection here.  In one moment it seems you are objecting to me even making a suggestion, and the next it seems you feel this will make the work load worse for the devs (which I disagree on).