Funcom Team,
I want to be constructive, and maintain a positive focus on Conan Exiles software development. This post contains the following sections: Background, Open Issues, Suggested Changes, Benefits to the Community, and Conclusion.
Background:
Thank you for acknowledging that some of the recent changes in TestLive update 2-2 were unintended and will be resolved in a hotfix. I noticed that your Community Support personnel directed users to report bugs in the relevant bug report forum.
Open Issues
1. There appears to be a lack of a robust “Bug Tracking” system as follows:
I found that in both TestLive and in Live Bug Report forums that many reported bugs were either not acknowledged by Funcom, where the thread then “expired” or where someone at Funcom did indeed acknowledge that it appeared to be a bug, but never provided a closure of the bug. For example, a response as “Not a Bug, and Not Corrected”, “Confirmed Bug and Corrected”, or “Confirmed Bug and Uncorrected (for a reason)” was not entered, leaving the impression that the bug was an open issue that became orphaned. In many of these cases, the acknowledged bug never had a resolution posted in patch notes, suggesting that the bug still exists and the report is expired.
2. There appears to be a lack of a robust QA process as follows:
In a recent response to TestLive update 2-2 in that a possibly “not intended issue” with a “size and scope suggesting an issue related to importing datatables” was acknowledged and promised to be corrected in a hotfix on TestLive.
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.
- Exhaustively document all changes in Patch Notes such that nothing is omitted.
Benefits to the Community:
- No Bugs Left Behind - All bugs, no matter how “stale” are fully addressed as either intended, a corrected bug, or an uncorrectable bug. This provides all users with the confidence that all reported bugs are addressed by Funcom without exception.
- Full Transparency - No “Stealth Nerfs” (as users see them), whether intended or accidental, make it into TestLive or Live servers. This provides all users with the assurance that Funcom includes no factual inaccuracies, even by accident or omission, in the patch notes, and mitigates negative User responses.
- Robust Quality Assurance - File Comparison automation with a QA review prevents errors in database imports, database merges, and source-code from accidentally causing drastic changes to TestLive or Live. We’re all human and we all make mistakes; doing this mitigates negative attention in the forums by Users (and in other media by Content Creators) who in some cases appear to find these errors before Funcom developers do.
Conclusion:
Thank you for reading this post in its entirety. I saw opportunities for improvement that may be present in the entire Funcom suite of games and I believe that implementing improvements as above will improve the relationship between Funcom, Users, and Content Creators as well as the quality of Funcom patches across all games and platforms. I look forward to seeing these changes implemented in a manner that fits within the Funcom organizational structure.