Jump to content
TrinityCore

Leaderboard

Popular Content

Showing content with the highest reputation on 11/25/17 in all areas

  1. Tickets reporting incidents in a granular manner are being closed in favor of keeping tickets that describe large, vague, and obscure issues. For instance, I reported that Skittering Spiderlings in The Hinterlands are attackable rather than lootable only to get that ticket closed in favor of keeping a ticket titled Cataclysm Zones - Quests + Phasing. So now, rather than tackling the spiderling issue, which is an easy fix, we can't apply the solution until the Cataclysm ticket is solved entirely. That is bad policy. The process of Incident Management has been developed, polished, and heavily tested for more than thirty years and separates incidents from problems. The way that @DoctorKraft managed this ticket is the right way to do so: a User-Acceptance Tester (UAT) reported an issue and @DoctorKraft then created a separate ticket that explains the technical problems causing that incident for developers to solve. It allows specialization by having testers reporting issues while developers focus on building code that testers can then test. Furthermore, putting everything into a single huge ticket describing large, vague, and obscure issues goes against the paradigm of divide-and-conquer in software development. That paradigm establishes that the best way to solve a big issue (such as 'Westfall is not scripted') is by breaking the problem into many small problems (such as Quests 'Hot On the Trail: The Riverpaw Clan' and 'Hot On the Trail: Murlocs' are available before completing quest 'Murder Was They Case That They Gave Me' and Two-Shoed Lou is not phased in after getting quest Meet Two-Shoed Lou). That paradigm allows developers and scripters to fix tiny problems that incrementally solve the big issue, rather than having to wait for the entire big issue to be solved in order to apply the fix. Moreover, this policy discourages UAT testers from testing the core. For example, if I wouldn't have tested the Hero's Call Board in Ironforge (which is considered a Cataclysm zone) we wouldn't have discovered that there is a feature missing in the core. Same thing when I tested Rune of Fire in Dun Morough (which is also considered a Cataclysm zone) which allowed us to find that the spell Burn Constriction Totem does not support the `conditions`.`SourceTypeOrReferenceId` for CONDITION_SOURCE_TYPE_SPELL which is also a core issue. But what incentives do I have now to continue to do UAT if the time and effort I spend in such testing is worthless since my reports will get closed on behalf of tickets that describe large, vague, and obscure issues? I suspect this is one of the factors why Ohloh reports a -31% decline in contributors to this project in the last twelve months. If you discourage contributors like UAT testers to participate, what do you expect? I don't think that's what we want as a community. Fortunately, the incident management process in software development has been well documented and developed in the past thirty years. There's no need to reinvent the wheel. But if we want to make this project flourish and more successful that what it already is, we should start adopting best practices and encouraging people--particularly UAT testers--to contribute rather than disincentivize them.
    1 point
×
×
  • Create New...