The rant posts seem to get the attention of the staff. This is not intended to imply that you are ranting, quite the opposite in fact: your questions and suggestions are valid, relevant, and necessary to be resolved.
Since this is where the attention is, I’ll just quote myself here.
Suggested Changes:
Create a robust Bug Tracker system that implements the following process (or something substantially similar) as follows:
Forum User (or Funcom Personnel) creates a Bug Report thread and system automatically assigns a Bug Report Ticket Number.
A designated Funcom Team member is assigned the Bug Report Ticket by Number.
The designated Funcom Team member validates the Bug Report and posts accordingly to the thread as “Open Bug” or “Not a Bug”.
If it is Not a Bug, then the thread is closed.
If it is a valid Bug, then the Bug is assigned to the proper Funcom developer(s) to resolve.
When the Bug is resolved, then the Bug Report thread is closed, with a note that it is resolved via patch and the Bug Report Ticket Number is referenced in Patch Notes for the correction.
If the bug cannot be resolved due to limitations, then the Bug Report thread is closed and documented accordingly.
Note that for this to function properly, the thread must remain open until formally closed by the above closure methods; “automatic expiration” due to lack of replies should not close this type of thread.
Create a robust QA system for content patches as follows:
Use a File Comparator tool (i.e. KDiff3) to exhaustively track all changes between current Live version and current TestLive version for both databases being imported/migrated and source code being changed.
Verify that all intended changes (from design document or patch goals) are properly implemented.
Verify that no unintended changes (from database imports, merges, or software code changes) are accidentally introduced.4. Exhaustively document all changes in Patch Notes such that nothing is omitted.
Emphasis added to point 4.
3 Likes