User:Edʹrashtekaresket/Bugs Notes

General Information  Duration: 150 to 180 minutes with a 5 minute catch up period for latecomers after the introduction and a 10 minute break after the first speaker  Location: Docked up safely in a station. We have a few ground rules for this class:  Feel free to type any questions in the Class.E-UNI chat channel as we proceed, but do not send them until I ask for questions - Once the floor is turned over to guest speakers they will have discretion as to whether to continue on their topic or stop to answer questions.  We're hosting this event because people often confuse features with bugs, or don't know how to properly report and work around them.  CCP is helping out by giving a behind the scenes look and giving information to make sure the entire process goes more smoothly  First let's get a few concepts out of the way, including what is a bug and how they're reported and dealt with.

What is a Bug?  Normal software behavior is essentially what you expect out of anything you do on your computer every day. It should just work. When it doesn't, that's considered buggy or anomalous behavior.  The term bug in software is popularly considered to be derived from an incident where a moth actually made its way into a computer, causing incorrect output.  Bugs are generally when any of the following are problematic  Logic is faulty (semantic error)  Something is "spelled wrong" (syntactic error)  Code or programs that the program depends on to run don't behave as expected, or inputs are outside expected ranges (operating in unknown space)  The computer does the wrong thing physically (hardware fault)  Something else fails because of one of the above errors, causing a ripple effect (External factors/dependency factors)  Bug Hunting vs QA  If something works properly, but is wrong, either because it doesn't meet specification or because the specification is wrong, that's a design issue.  If something doesn't work properly, it's bugged.  Both fall under the purview of Quality Assurance

Handling Bugs  Patching (Or: Killing bugs dead)  When bugs are discovered and deemed fixable with the resources allocated to the problem, the code is reworked, submitted for testing and then deployed to the production environment via a "patch". The concept itself is similar to patching a physical thing; a piece of something (code) intended to keep things working smoothly, perhaps until a more permanent fix can be affected. This patch can be applied to the server, the client or both, depending on what needs to be fixed.  How to deal bugs  Because patching takes time, there is inevitably some period of time where bugs discovered in a production environment are present.  Once you've reported a bug you'd probably like to keep playing  The best way to do this is to find a "workaround" or a way of bypassing the problem such that the bug has little to no impact on your experience, or failing that a way to at least continue what you're attempting to do as best you can (mine, pvp, lead a fleet, etc)  If you're unable to compose Eve Mail effectively in the client try using Notepad (for Windows) or TextEdit (for Mac) to compose your mail, then copy and paste it from the text editor to your EVE client when you're finished.  If other people have experienced this bug, particularly if it's widespread or affects everyone, someone else has probably discovered a workaround. Ask around, use the social nature of Eve to your advantage.  Less Obvious Bugs  Sometimes bugs are what are called 'corner cases' or are otherwise hard to find/replicate and/or may not have an impact on your day to day gameplay. These should always be reported, as they may be on paths not commonly tread and could otherwise go un-noticed for a long while.  If your uncommon graphics card renders Amarr stargates as white blobs of light, try playing with the settings.  For Example (story) If you can't see how long until your next neural remap after seeing what you've previously trained, don't the first after the second.  When you encounter a less obvious bug, it may be possible to just ignore it, after you've bug reported it. Less obvious bugs, by their very nature, won't crop up very often and/or may not be very visible when they do.

Guest Speakers  Tentative order: Konflikt, talking about BH filtering and first tier response, Oneiromancer talking about writing bug reports and QA, Sisyphus ???

Final Wrapup  Feedback and questions always appreciated