User:Edʹrashtekaresket/Bugs 101 Syllabus: Difference between revisions

← Older edit

VisualWikitext

@@ Line 17: / Line 17: @@
 '''Student requirements:'''
-* TeamSpeak registration and access - make sure you have TeamSpeak sorted out and operational well before the class begins. Use this guide for set-up: http://wiki.eveuniversity.org/TeamSpeak
+* TeamSpeak registration and access - make sure you have TeamSpeak sorted out and operational well before the class begins. Use this guide for set-up: [http://wiki.eveuniversity.org/TeamSpeak]
 * Access to the Class.E-UNI in-game chat channel
 * If you intend to take part in [[Bugs_103_Syllabus|Bugs 103]] you '''MUST''' have attempted an install of Singularity ([http://www.eveonline.com/ingameboard.asp?a=topic&threadID=1377944]).
 ** If you have not yet attempted this, it is '''HIGHLY''' recommended you start '''now'''
 '''Additional information:'''
-This class is primarily lecture delivered in the Class.E-UNI channel in TeamSpeak, followed by Q&A.  [An optional practical exercise follows.]
+This class is primarily lecture delivered in the Class.E-UNI channel in TeamSpeak, followed by Q&A.
+This course is prerequsite for [Bugs_102_Syllabus|Bugs 102], including any guest speakers that may be scheduled.
 === Notes for the Teacher ===
 Required materials:
 * Class.E-UNI chat channel, to receive questions and post relevant links
-* List any relevant links to teacher's references on the wiki or other resources, if needed
+* [http://wiki.eveonline.com/en/wiki/Bug_reporting|EveWiki on Bug Reporting]
+* [http://wiki.eveonline.com/en/wiki/Mac_bug_reporting|Mac Bug Reporting]
+* [http://bugs.eveonline.com|bugs.eveonline.com]
 * Describe any ships, fittings, modules, or tools required to have on hand, if needed
-Any particular notes or tips about how to deliver the class go here.
+* If there are guest speakers sure you take roll relatively early in the class, while allowing some time for stragglers.
 == Class Contents ==
@@ Line 39: / Line 42: @@
-This course is designed primarily for....
+This course is designed primarily for people who have no formal experience with bugs, bug reporting or quality assurance.
+Over the 90 minutes or so, we shall cover......
-Over the xxxx minutes or so, we shall cover......
 ''(Instructor should then introduce himself or herself - covering relevant experience level and background.)''
@@ Line 48: / Line 50: @@
 * Please put your TeamSpeak settings on "Push to Talk" if you have not already done so.
 * Feel free to type any questions in the Class.E-UNI chat channel as we proceed - I will try to answer your questions as they come during the class. [At the end of my lecture, we'll open TeamSpeak for any further questions or general discussion.]
-* You should be [docked up safely in a station [in Aldrat if you intend to participate in the practical exercise], or located....]
+* You should be docked up safely in a station, this will be a lot of talking and not much practical.
+* Roll call
 Everyone ready?  OK, then - let's begin....
-=== Main Topic #1 ===
+=== What is a Bug? ===
-* Outline of key points to cover
+* Normal software behavior
-* Key point
+** For instance in Eve...
-** Detail point
+*** Text editing in Eve Mails (Unfixed)
-** Another detail
+*** Neural Remap Available (Fixed)
-* Final key point
+*** Aggression Timers (QA Defect)
+* Interactions between code fragments
+** For instance...
+*** Pressing z 18 times in an Eve Mail crashes the client
+*** Having the history tab open and switching to attributes hides text
+*** Shooting cans extends 15 min time up to 2 hours
+* Bugs are when any of the following are problematic
+** Logic is faulty (semantic error)
+** Syntactic error
+** External factors (something else fails because of one of the above)
+* 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
-=== Main Topic #2 ===
+=== Handling Bugs ===
 * Outline of key points to cover
-* Key point
+* Patching
-** Detail point
+** The process of fixing bugs via changes to a piece of code somewhere
-** Another detail
+* Common/Obvious Bugs
-* Final key point
+** Once you've reported a bug (or, in some cases, determined a bug report isn't necessary) you have to keep playing
+** When a bug affects your gameplay, there is usually a workaround to it.
+*** If you can't fire missiles, switch to lasers/autocannons/hybrids/whatever. (Big issue, but not breaking, see also [[Rockets]])
+*** If you can't log in, try taking a brisk walk outside.
+* 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. (Teachers, your mundane or non-critical activity may be someone else's only draw to Eve)
+*** If you can't compose Eve Mail effectively, write it in another text editor.
+*** If you can't stack more than 1 billion capital ship components, use multiple stacks.
+*** If you can't see how long until your next 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.
 === Main Topic #3 ===