Community Relations Archive
Thread: It was raised before Publish 20 went live, yet another major bug goes live.
It is a shame you have such poor communication. One of the programers that never hear about a bug may have some great insight on how to fix that bug. I personally would have a master list and pass it around to every programer giving them the ability to comment on any bugs they may have insight on, then assign out bug fixes to specific people with the insights attatched. Such a ridged system you have opperating never works as well as a more open freer system. I am sure many bugs can be fixed much quicker or never get pushed out to live if there was more freedom of the programs to just do their job without all the micromanaging.
Tiggs wrote:
Ekymer wrote:
appently no one ever reads the bug threads, not on TC nor on Live. Fanfest has shown several times that no bugs get forwarded to the DEVs.
Every day the Live, TC and Correspondent bug threads are entered into a excel spreadsheet. They are then sent on to QA to be reproduced and assigned a bug number. From there they are then prioritized and filtered out to the Leads. Members of the Dev team will not know all bugs that are happening. They are assigned bugs from their Lead and those are what they work on. So your statement is semi true, Devs are not shown all the bugs that are entered however, they are told about bugs that impact them.
Meplorium wrote:
It is a shame you have such poor communication. One of the programers that never hear about a bug may have some great insight on how to fix that bug. I personally would have a master list and pass it around to every programer giving them the ability to comment on any bugs they may have insight on, then assign out bug fixes to specific people with the insights attatched. Such a ridged system you have opperating never works as well as a more open freer system. I am sure many bugs can be fixed much quicker or never get pushed out to live if there was more freedom of the programs to just do their job without all the micromanaging.
Tiggs wrote:
Ekymer wrote:
appently no one ever reads the bug threads, not on TC nor on Live. Fanfest has shown several times that no bugs get forwarded to the DEVs.
Every day the Live, TC and Correspondent bug threads are entered into a excel spreadsheet. They are then sent on to QA to be reproduced and assigned a bug number. From there they are then prioritized and filtered out to the Leads. Members of the Dev team will not know all bugs that are happening. They are assigned bugs from their Lead and those are what they work on. So your statement is semi true, Devs are not shown all the bugs that are entered however, they are told about bugs that impact them.
Well.. finaly i can say....
QFE
Shame all the categories for /bug are horribly out of date and inefficient (at least appearing to be on the user end)
Tiggs wrote:
/bug reports done in game go directly to the QA department and are looked over daily.
SirSpamalot wrote:
why o why put a /bug command in the game if no-one looks at them!?
Tiggs wrote:
We agree with your wants. We are going to be focusing on smaller/cleaner publishes because quality means much more then quantity.
Ecnirp wrote:
The Experimentation bug (experimentations not updating until the item is crafted) was raised days ago, bugged on the TC and posted on the TC bug threads - yet its gone live, and to all crafters it seems.Why did another majorly bugged publish go live?It seems each major bug\bugs brought by each new publish is raised before it goes live and yet it still gets pushed out.This is not what the player base wants.Please....1) Focus on fixing all the existing major bugs before any more publishes go out.2) Please please, don't push out publishes you know have major bugs - do you think we really mind waiting a few days for a bug to get fixed before a publish goes live?/sign
That's the thing about this game...
it has SO MUCH quantity (And has had so much for a long time)... the quality needs to catch up.
There is just so much to this game, if everything worked right there'd be a lot more fun to have and I think the Devs could better focus on making the game even more fun on top of that.
I think that, second to the needed bug-smashing, the priority should be to make what does exist, a little bit more balanced on the fun side of the gaming equation.
This player-base is too focused on accomplishments and the rewards of conquest...
I'd like to see the rewards more often be the experience of playing, rather than the expensive prize or quest reward item.
Loot and PvP play havoc on overall game-balance... I sometimes think that the original line-of-thought that SWG had was sacrificed to attempt to appease too many people... too wide of a target.
SWG has so much in it, but you cannot please everybody... and when you try to please everybody, you generally end up pleasing no one.
A smoothly running game, with the focus on Crafters and role-playing was my dream of this game... and I am a combat player.
I just enjoyed the idea of playing in combat in a non-combat run world... if anyone understands my meaning.
Anyhoo... I've been here since launch and I've wanted them to focus only on bug-fixes and Profession balancing for quite a long while.
And of course we have to understand.... bugs are there for a reason...
They're there because there's a mistake that hasn't been found/solved.
So, some bugs will happen and won't be solved until it is finally figured out.
I try and remember how many "bugs" exist in Real Life to help me tolerate a game's regular bugs.
I hate that bug where the person I talked to on the phone gets everything wrong and doesn't do the job they said they would do... don't you?
And when are they gonna fix that common cold bug?
May the force be with you.
- Omadda Szool
Kauri
Message Edited by omadnay on 07-26-2005 06:04 PM
I agree that these new publishes should not be going live with such crazy bugs.
New bugs being introduced is becoming way too common... something is not working right with the way SOE is going about pushing out publishes.
As a paying customer, I am certainly not happy with the way these recent publishes have been effecting the game.
- Omadda Szool
Kauri
Tiggs wrote:
Every day the Live, TC and Correspondent bug threads are entered into a excel spreadsheet. They are then sent on to QA to be reproduced and assigned a bug number. From there they are then prioritized and filtered out to the Leads. Members of the Dev team will not know all bugs that are happening. They are assigned bugs from their Lead and those are what they work on. So your statement is semi true, Devs are not shown all the bugs that are entered however, they are told about bugs that impact them.
Tiggs, that's the fullest description I've heard yet of the process the development team uses to work issues. Thanks for trusting us with this information.
Naturally it raises a couple of questions. 
1. An Excel spreadsheet? I'm pretty surprised to hear that. I'm glad there's a tracking system, but I wonder why you folks aren't using some tool that's more specific to tracking issues through a development cycle.
It took a fight, but I managed to get budget to develop and continuously improve an in-house system for making changes (both bugfixes and enhancements). This thing has saved my bacon as a project manager more times than I can count -- it not only controls the process of making changes from requirements to analysis to coding to testing, as well as insuring source code version control, it also exposes this information to those who need it to help manage the whole process.
We've dramatically reduced the number and severity of bugs that make it into production code by using this tool that's keyed specifically to our development process.
2. One of the other aspects of this tool that makes my life less painful is its role in clarifying expectations. Because everyone can see who's assigned which tasks, everyone knows what's expected of them -- we don't get unhappy surprises.
I actually wrote some C and JavaScript code that pulls information from the tracking database and displays it in a nice format. Anyone can run it to see which issues are assigned to them (so every developer know what he or she is expected to be doing at any moment in time), and the status of each issue (so that I and my leads can see where bottlenecks are occurring to direct development resources there).
The bottom line here is that because we make task assignment information visible to every team member, nobody gets surprised by somebody's else work affecting them. That helps us identify and address integration-level bugs before they even go into testing (not to mention before they go live!).
I don't mention this stuff to wag a finger and say your system is "wrong." These are just steps I've taken that I can demonstrate have paid off financially by reducing our error rate, and that might work for you, too, which would benefit all of us.
Thanks again for the insight into your process!
--Flatfingers
Tiggs wrote:
Every day the Live, TC and Correspondent bug threads are entered into a excel spreadsheet. They are then sent on to QA to be reproduced and assigned a bug number. From there they are then prioritized and filtered out to the Leads. Members of the Dev team will not know all bugs that are happening. They are assigned bugs from their Lead and those are what they work on. So your statement is semi true, Devs are not shown all the bugs that are entered however, they are told about bugs that impact them.
So.... Please, can you tell us if, after all that proceeding, someone has shown to the Devs the annoying chat windows bug? 
Tiggs wrote:
Every day the Live, TC and Correspondent bug threads are entered into a excel spreadsheet. They are then sent on to QA to be reproduced and assigned a bug number. From there they are then prioritized and filtered out to the Leads. Members of the Dev team will not know all bugs that are happening. They are assigned bugs from their Lead and those are what they work on. So your statement is semi true, Devs are not shown all the bugs that are entered however, they are told about bugs that impact them.
Is it just me or do I spot a HUGE flaw in this method?
By not relaying all the bugs known to the dev team you deny them a view at the bigger picture. One bug might seem unrelated to another in eyes of the "Spreadsheet maker" or the lead, while if a "normal" dev would see the entirelist, they might spot a connection or pattern in a certain problem. All too often are some seamingly simple and often used bits of codeused by loads of different subsystems. It might not affect one system, but it might affect the other.
Ask yourself this question: How many times have things been broken after a publish, when the patch notes dont seem to mention any relation to the created problem, or the newly broken system hasnt even been touched and still went borked? That might indicate the above mentioned condition has occured, but due to the partial information the devs get access too, they might actually break more than they fix when put on bug squashing duty.
I think any software designer would wholeheartedly agree with me, as I am a small one myself, and wouldnt dream of keeping information from my coworkers. Everyone needs to see the overall picture. Its a teameffort.
Tiggs wrote:
We agree with your wants. We are going to be focusing on smaller/cleaner publishes because quality means much more then quantity.
How can the Leads possibly know which bugs to assign to which Dev when the /bug categories are horribly out of date?
Tiggs wrote:
Ekymer wrote:
appently no one ever reads the bug threads, not on TC nor on Live. Fanfest has shown several times that no bugs get forwarded to the DEVs.
Every day the Live, TC and Correspondent bug threads are entered into a excel spreadsheet. They are then sent on to QA to be reproduced and assigned a bug number. From there they are then prioritized and filtered out to the Leads. Members of the Dev team will not know all bugs that are happening. They are assigned bugs from their Lead and those are what they work on. So your statement is semi true, Devs are not shown all the bugs that are entered however, they are told about bugs that impact them.
Tiggs wrote:
Ekymer wrote:
appently no one ever reads the bug threads, not on TC nor on Live. Fanfest has shown several times that no bugs get forwarded to the DEVs.
Every day the Live, TC and Correspondent bug threads are entered into a excel spreadsheet. They are then sent on to QA to be reproduced and assigned a bug number. From there they are then prioritized and filtered out to the Leads. Members of the Dev team will not know all bugs that are happening. They are assigned bugs from their Lead and those are what they work on. So your statement is semi true, Devs are not shown all the bugs that are entered however, they are told about bugs that impact them.
Perhaps there are either too many hands in the process, or too many areas for translations to go bad.
I'm not saying that every programmer on the team needs to read every bug daily... or that every programmer on staff should be able to spend their time on anyhting they choose either or spend time on nothing but "today".. from being in large development teams in the past I know that's never going to happen and if it did it be a recipe for bigger disasters.
There just seems to be a disconnect somewhere in the process, my guess between the people in game and the folks either prioritizing the work or those evaluating / giving the green light for patches... but something in there just has been more wrong then right lately and its more then just changing the size of patches or balance between new and fix. Theres something in the process that is causing things to repeatedly get misprioritized when it comes to a particular issue's impact on everyday play and keeping at a minimum the status quo going.
Tiggs wrote:
Ekymer wrote:
appently no one ever reads the bug threads, not on TC nor on Live. Fanfest has shown several times that no bugs get forwarded to the DEVs.
Every day the Live, TC and Correspondent bug threads are entered into a excel spreadsheet. They are then sent on to QA to be reproduced and assigned a bug number. From there they are then prioritized and filtered out to the Leads. Members of the Dev team will not know all bugs that are happening. They are assigned bugs from their Lead and those are what they work on. So your statement is semi true, Devs are not shown all the bugs that are entered however, they are told about bugs that impact them.
Tiggs, please dont take this the wrong way, but the system you guys have in place sucks. Your development focus isalmost completely off the mark. You guys want to give us so much content in so little time, but we end up with that content being almost unplayable. You guys need to slow down fast. Seriously, slow down.Remember, its quality we really want, not quantity. I have stopped playing my BH and my Tailor over the issues that are currentlyon live servers.. What does that tell you?
Message Edited by Sytem on 03-09-2005 04:13 AM
Tiggs wrote:
We agree with your wants. We are going to be focusing on smaller/cleaner publishes because quality means much more then quantity.
Ecnirp wrote:
The Experimentationbug (experimentations not updating until the item is crafted)was raised days ago, bugged on the TC and posted on the TC bug threads - yet its gone live, and to all crafters it seems.
Why did another majorly bugged publish go live?
It seems each major bug\bugs brought by each new publishis raised before it goes live and yet it still gets pushed out.
This is not what the player base wants.
Please....
1) Focus on fixing all the existing major bugs before any more publishes go out.
2) Please please, don't push out publishes you know have major bugs - do you think we really mind waiting a few days for a bug to get fixed before a publish goes live?
/sign
we have heard the same cra...story for two years ever few months...